[OT] tilix packaging

[drug via Digitalmars-d]

Gerald, I'd like to learn how to make deb packages, could you share your 
scripts etc you use to build packages for tilix?

Thank in advance)

Re: We're looking for a Software Developer! (D language)

[Ola Fosheim Grostad via Digitalmars-d-announce]

On Wednesday, 29 November 2017 at 15:11:17 UTC, Paulo Pinto wrote:
Wirth puts it nicely, it is all about algorithms, data 
structures and

learning how to apply them to any language.


Yes, they also mention machine learning, which borrows from many 
fields close to applied mathematics. Linear algebra, statistical 
signal processing, statistical modelling, etc... I took a course 
on statistical signal processing this year (using Hayes book + 
extras) and experience without theoretical training would be 
inefficient. You have to tailor the algorithms to the 
characteristics in the signal...

Re: Private imports and Objects

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, November 30, 2017 06:29:43 helxi via Digitalmars-d-learn wrote:
> 1. Why are imports visible from outside the package when you do
> selective imports?
>
> //mod.d
> module mod;
>
> import std.stdio : writeln;
>
> public void greet()
> {
>  writeln("Hello");
> }
>
>
> //app.d
> import mod;
>
> void main()
> {
>   mod.greet();
>   writeln("You should not be seeing this.");
>
> }
>
> Compiles just fine and prints "You should not be seeing this."
> just fine with `$dub build`. Even if I use package imports the
> result stays the same.

If you use a version of dmd that's at least semi-recent, you should see a
deprecation message. It works due to a long standing bug that has been
fixed, but when it was fixed, a number of aspects of imports were
overhauled, and it was decided to phase in the new behavior to minimize code
breakage, and as such, it should be printing a deprecation message at the
moment, whereas in the future, it will become an error like it should be.

> 2. Classes that do not inherit (base classes) actually inherit
> from 'Object`. For which, often times one converts the Object to
> its subclasses. What's the rationale behind this?
> Isn't this going to add overhead?

I don't understand the question. You're asking whether casting from a base
class to a derived class creates overhead? Or are you asking whether having
a base class for all classes creates overhead? Or something else?

Object exists primarily because D didn't originally have templates, and when
you don't have templates, having a single base class is the only way to have
a function accept any class, and for something like a container, you'd
pretty much be forced to use void* without Object if you don't have
templates. However, once templates were added to D, the benefits of Object
were significantly reduced, and it's arguably not a particularly good idea
to be writing code that operates on Object. However, it's far too late in
the game to get rid of Object.

At one point, it was decided to remove Object's member functions, because
having them on Object needlessly locks in a particular set of attributes for
those functions, and if we did that, then there really wouldn't be much
reason to use Object directly, but that change has never happened, and it's
not clear that it's going to happen, since there are a number of technical
issues that make it a bit of a pain to do (particularly if we don't want to
break a lot of code). One of the bigger issues is that the AA implementation
in druntime needs to be templated so that it doesn't need to operate on
Object, and that's proven to be a bit of a challenge.

https://issues.dlang.org/show_bug.cgi?id=9769
https://issues.dlang.org/show_bug.cgi?id=9770
https://issues.dlang.org/show_bug.cgi?id=9771
https://issues.dlang.org/show_bug.cgi?id=9772

- Jonathan M Davis

Re: Thoughts about D

[Ola Fosheim Grostad via Digitalmars-d]

On Thursday, 30 November 2017 at 03:29:56 UTC, Walter Bright 
wrote:
The code *size* causes problems because it pushes the executing 
code out of the cache.


Not if you do a branch to a cold cacheline on assert failure.

Re: std.range.interfaces : InputRange moveFront

[Ali Çehreli via Digitalmars-d-learn]

On 11/29/2017 08:31 PM, Tony wrote:

What does the moveFront() method do in the InputRange interface?

std.range.interfaces : InputRange.moveFront()


move is an operation that transfers the state of the source to the 
destination. The front element becomes its .init value and its previous 
values is returned by moveFront().


The important bit is that, the element is *not* copied:

import std.range;

struct S {
int i;
bool is_a_copy = false;
this(this) {
is_a_copy = true;
}
}

void main() {
auto r =  [S(1)];

auto a = r.front;
assert(a.is_a_copy);   // yes, a is a copy
assert(a.i == 1);  // as expected, 1
assert(r.front.i == 1);// front is still 1

auto b = r.moveFront();
assert(!b.is_a_copy);  // no, b is not a copy
assert(b.i == 1);  // state is transferred
assert(r.front.i == 0);// front is int.init
}

Ali

Private imports and Objects

[helxi via Digitalmars-d-learn]

1. Why are imports visible from outside the package when you do 
selective imports?


//mod.d
module mod;

import std.stdio : writeln;

public void greet()
{
writeln("Hello");
}


//app.d
import mod;

void main()
{
mod.greet();
writeln("You should not be seeing this.");

}

Compiles just fine and prints "You should not be seeing this." 
just fine with `$dub build`. Even if I use package imports the 
result stays the same.


2. Classes that do not inherit (base classes) actually inherit 
from 'Object`. For which, often times one converts the Object to 
its subclasses. What's the rationale behind this?

Isn't this going to add overhead?

Re: Thoughts about D

[Walter Bright via Digitalmars-d]

On 11/29/2017 8:49 PM, Jonathan M Davis wrote:

Well, we could always have an alternate implementation of assertions for
release builds that acted closer to C's assert.


My plan for release builds is to have an option to make them just execute a HALT 
instruction. Short, sweet, un-ignorable and too the point!

Re: Thoughts about D

[Nicholas Wilson via Digitalmars-d]

On Thursday, 30 November 2017 at 04:21:20 UTC, Steven 
Schveighoffer wrote:

On 11/29/17 10:29 PM, Walter Bright wrote:
Another issue (I should check this again) was doing null 
checks on member function calls, which is not necessary since 
if they're null it'll seg fault.


Just happened last release.

https://dlang.org/changelog/2.077.0.html#removePreludeAssert

-Steve


That was specifically for constructors and destructors (i.e. 
(cast(Foo)null).__ctor() was the only way to trigger that assert) 
not member functions (of classes), which I believe is still part 
of the compiler.

Re: Thoughts about D

[Jonathan M Davis via Digitalmars-d]

On Wednesday, November 29, 2017 20:08:53 Walter Bright via Digitalmars-d 
wrote:
> On 11/29/2017 8:02 PM, Jonathan M Davis wrote:
> > Well, given that assertions would normally be used in a debug build
> > where
> > you generally don't optimize, and the debug symbols are compiled in, I
> > wouldn't think that that would matter much in most cases.
>
> I want them in the release build, which means they should be at minimal
> cost.

Well, we could always have an alternate implementation of assertions for
release builds that acted closer to C's assert. We already transform
assert(0) into something else with -release. In general, for debugging, I'd
much prefer to have D's assert as it is now, but I don't see any reason why
we couldn't do something differently with a flag like -release but which
specifically made assertions more primitive and lightweight for a release
build rather than removing them for those folks that want to leave
assertions enabled in a release build. Personally, I wouldn't want to enable
assertions in the release build of most stuff, but some folks definitely
have expressed the sentiment that they don't like the -release flag being
named what it is, because they don't think that assertions should be
disabled for release builds.

- Jonathan M Davis

std.range.interfaces : InputRange moveFront

[Tony via Digitalmars-d-learn]

What does the moveFront() method do in the InputRange interface?

std.range.interfaces : InputRange.moveFront()

Re: Thoughts about D

[Steven Schveighoffer via Digitalmars-d]

On 11/29/17 10:29 PM, Walter Bright wrote:
Another issue (I should check this again) was doing null 
checks on member function calls, which is not necessary since if they're 
null it'll seg fault.


Just happened last release.

https://dlang.org/changelog/2.077.0.html#removePreludeAssert

-Steve

Re: Changing the class data underneath some reference

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/29/17 10:22 PM, Jonathan M Davis wrote:

With classes, you could also assign the entire state of the object similar
to what you'd get with structs and opAssign, but you'd have to write a
member function to do it. There's no reason that you couldn't do the
equivalent of opAssign. It's just that there's no built-in operator for it.
So, whatever member function you wrote for it would be non-standard.
It's mostly a bad idea. The whole point of disallowing assignment is to 
prevent the slicing problem. It's also why opAssign isn't overloadable 
for classes assigning to classes in the same hierarchy.


-Steve

Re: Thoughts about D

[Steven Schveighoffer via Digitalmars-d]

On 11/29/17 10:23 PM, Walter Bright wrote:

On 11/29/2017 6:54 PM, Steven Schveighoffer wrote:
But even though it doesn't come with Windows, it can be installed 
once, and shared between all applications that use it.


That's the theory. Unfortunately, that relies on the library not 
changing. Microsoft changes it all the time, hence "dll hell".


My understanding is that if you use the Microsoft supplied MSI package 
as a dependency, there is only one installation of the libraries 
necessary. Granted, the last time I built MSI packages was about 10 
years ago...


But I don't remember having issues with DLL hell with that, even across 
compiler releases.


Yes, they changed the library on some revisions, but your MSVCRT dll 
would also be installed in the right places (and the right version 
loaded at runtime).


But we don't have to look at Microsoft as the gurus of library 
deployment, there are many good solutions already out there for other OSes.




A second problem is that due to the way D works most of the time (with 
templates just about everywhere), each new release is likely to be 
binary-incompatible. So you will essentially need many copies of 
druntime, probably one per release that was used to compile any D 
programs on your system.


At this point, relying on druntime not changing is just not realistic. 
libc is different, having been cast in stone for nearly 30 years now.


Baby steps, let's deploy it as a shared object first :) Until we do 
that, there is no point to worry about binary compatibility.


-Steve

Re: Thoughts about D

[Walter Bright via Digitalmars-d]

On 11/29/2017 8:02 PM, Jonathan M Davis wrote:

Well, given that assertions would normally be used in a debug build where
you generally don't optimize, and the debug symbols are compiled in, I
wouldn't think that that would matter much in most cases.


I want them in the release build, which means they should be at minimal cost.

Re: Thoughts about D

[Jonathan M Davis via Digitalmars-d]

On Wednesday, November 29, 2017 19:29:56 Walter Bright via Digitalmars-d 
wrote:
> On 11/29/2017 7:15 PM, Jonathan M Davis wrote:
> > I wouldn't have expected assertions to cost much more than however much
> > it costs to evaluate the expression being asserted unless the assertion
> > fails. Now, even that can slow down a program a fair bit, depending on
> > what's being asserted and how many assertions there are, but it's not
> > something that I would have expected to vary particular between C and
> > D. It doesn't surprise me that the generated code would be larger than
> > you'd get for the same assertions in C because how assertions are
> > handled when they fail is quite different, but I would expect the
> > assertions themselves to cost about the same in terms of performance as
> > long as they don't fail. What's going on that's making them so much
> > worse?
>
> The code *size* causes problems because it pushes the executing code out
> of the cache.

Well, given that assertions would normally be used in a debug build where
you generally don't optimize, and the debug symbols are compiled in, I
wouldn't think that that would matter much in most cases.

> Another issue (I should check this again) was doing null
> checks on member function calls, which is not necessary since if they're
> null it'll seg fault.

I didn't think that we _ever_ checked for null on accessing members (though
as I understand it, we actually do need to if the type is large enough that
segfaults don't actually happen when dereferencing null - at least, we need
to check for null in those cases in @safe code, or the code isn't really
@safe).

- Jonathan M Davis

[Issue 18020] [Reg 2.078] no property opCmp for anon class

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #1 from Mike  ---
Attempted fix submitted here: https://github.com/dlang/dmd/pull/7378

--

Re: Thoughts about D

[Walter Bright via Digitalmars-d]

On 11/29/2017 7:15 PM, Jonathan M Davis wrote:

I wouldn't have expected assertions to cost much more than however much it
costs to evaluate the expression being asserted unless the assertion fails.
Now, even that can slow down a program a fair bit, depending on what's being
asserted and how many assertions there are, but it's not something that I
would have expected to vary particular between C and D. It doesn't surprise
me that the generated code would be larger than you'd get for the same
assertions in C because how assertions are handled when they fail is quite
different, but I would expect the assertions themselves to cost about the
same in terms of performance as long as they don't fail. What's going on
that's making them so much worse?


The code *size* causes problems because it pushes the executing code out of the 
cache. Another issue (I should check this again) was doing null checks on member 
function calls, which is not necessary since if they're null it'll seg fault.

Re: Andrei's "The D Programming Language" book. Up to date?

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, November 29, 2017 17:26:11 Nick Treleaven via Digitalmars-d-
learn wrote:
> On Wednesday, 4 October 2017 at 20:49:26 UTC, John Gabriele wrote:
> > What's changed in the language, library, and community since
> > then that I should be aware of if following along with and
> > learning from that book?
>
> Here's a list of significant things - maybe incomplete:
> https://wiki.dlang.org/Differences_With_TDPL

I didn't even realize that that page existed. I just made some tweaks to it,
though it's still probably far from complete as far as stuff not mentioned
in TDPL goes. As for unimplemented stuff, it made it sound like shared isn't
implemented (which isn't true at all; it just doesn't have memory barriers
like TDPL talks about; the big thing missing for shared is arguably that the
memory model for D needs to be properly defined like C++ finally did, but
TDPL doesn't talk about that at all), and the wiki page didn't list
synchronized classes, which is the other big one that isn't implemented
(though putting synchronized on classes actually has _some_ effect now,
which it didn't until fairly recently).

- Jonathan M Davis

Re: Thoughts about D

[Walter Bright via Digitalmars-d]

On 11/29/2017 6:54 PM, Steven Schveighoffer wrote:
But even though it doesn't come with Windows, it can be installed once, and 
shared between all applications that use it.


That's the theory. Unfortunately, that relies on the library not changing. 
Microsoft changes it all the time, hence "dll hell".



The issue with druntime isn't that it's not installed, it's the static linking.


If the user still has to download the dll, he hasn't gained anything by dynamic 
linking.


A second problem is that due to the way D works most of the time (with templates 
just about everywhere), each new release is likely to be binary-incompatible. So 
you will essentially need many copies of druntime, probably one per release that 
was used to compile any D programs on your system.


At this point, relying on druntime not changing is just not realistic. libc is 
different, having been cast in stone for nearly 30 years now.



> But this is much less of an issue, especially if there are many programs that 
build using the same release.


It didn't work for Microsoft shipping a different, incompatible C runtime DLL 
with each compiler.

Re: Changing the class data underneath some reference

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, November 29, 2017 21:12:58 Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 11/29/17 7:40 PM, David Colson wrote:
> > Hello all!
> >
> > I'm getting settled into D and I came into a problem. A code sample
> > shows it best:
> >
> > class SomeType
> > {
> >
> >  string text;
> >  this(string input) {text = input;}
> >
> > }
> >
> >
> > void main()
> > {
> >
> >  SomeType foo = new SomeType("Hello");
> >
> >  SomeType bar = foo;
> >
> >  foo = new SomeType("World");
> >
> >  writeln(bar.text); // Prints hello
> >  // I'd like it to print World
> >
> > }
> >
> > In the C++ world I could do this using pointers and changing the data
> > underneath a given pointer, but I can't use pointers in D, so I'm not
> > sure how I can get this behaviour?
> >
> > I'd be open to other ways of achieving the same affect in D, using more
> > D like methods.
>
> D does not support reassigning class data using assignment operator,
> only the class reference. You can change the fields individually if you
> need to.
>
> e.g.:
>
> foo.text = "World";
>
> structs are value types in D and will behave similar to C++
> classes/structs.

With classes, you could also assign the entire state of the object similar
to what you'd get with structs and opAssign, but you'd have to write a
member function to do it. There's no reason that you couldn't do the
equivalent of opAssign. It's just that there's no built-in operator for it.
So, whatever member function you wrote for it would be non-standard. Heck,
technically, we don't even have a standard way to clone a class object like
C# or Java do. Some folks write a clone function and others write a dup
function; either way, there's nothing built-in or standard for it.

- Jonathan M Davis

Re: Thoughts about D

[Jonathan M Davis via Digitalmars-d]

On Tuesday, November 28, 2017 18:18:20 Walter Bright via Digitalmars-d 
wrote:
> On 11/28/2017 9:27 AM, Jacob Carlborg wrote:
> > Why would druntime be a barrier for you for those projects?
>
> When the C version is 90K and the translated D version is 1200K, it is a
> barrier. It's a barrier for others, as well.
>
> Another barrier for me has turned out to be the way assert() works in D.
> It just is not lightweight, and it visibly slows down dmd to have
> assert's turned on internally. The amount of machinery involved with it
> in druntime is way overblown. Hence, asserts in dmd are turned off, and
> that wound up causing me a lot of problems recently. There are even
> initiatives to add writefln like formatting to asserts. With betterC,
> asserts became lightweight and simple again.

I wouldn't have expected assertions to cost much more than however much it
costs to evaluate the expression being asserted unless the assertion fails.
Now, even that can slow down a program a fair bit, depending on what's being
asserted and how many assertions there are, but it's not something that I
would have expected to vary particular between C and D. It doesn't surprise
me that the generated code would be larger than you'd get for the same
assertions in C because how assertions are handled when they fail is quite
different, but I would expect the assertions themselves to cost about the
same in terms of performance as long as they don't fail. What's going on
that's making them so much worse?

- Jonathan M Davis

[Issue 12625] [scope] [DIP1000] implicit slicing of RValue static array should be illegal

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #22 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/b8cb63a01cc20051f0f057a1556bcec1533443fa
fix Issue 12625 - [scope] [DIP1000] implicit slicing of RValue static array
should be illegal

https://github.com/dlang/dmd/commit/b1209169eeac242f879cc7c9a3a0f928c1be3c02
Merge pull request #7110 from WalterBright/fix12625

fix Issue 12625 - [scope] [DIP1000] implicit slicing of RValue static…
merged-on-behalf-of: Andrei Alexandrescu 

--

[Issue 12625] [scope] [DIP1000] implicit slicing of RValue static array should be illegal

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Thoughts about D

[Steven Schveighoffer via Digitalmars-d]

On 11/29/17 9:16 PM, Walter Bright wrote:

On 11/29/2017 3:36 PM, Jon Degenhardt wrote:

On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh wrote:
While generally I would still use fullblown D rather than BetterC for 
my projects, the bloat from druntime/phobos does still bother me at 
the back of my mind.  IIRC, the Phobos docs used to state that the 
philosophy for Phobos is pay-as-you-go. As in, if you don't use 
feature X, the code and associated data that implements feature X 
shouldn't even appear in the executable. It seems that we have fallen 
away from that for a while now.  Perhaps it's time to move D back in 
that direction.


If there specific apps where druntime and/or phobos bloat is thought 
to be too high, it might be worth trying the new LDC support for 
building a binary with druntime and phobos compiled with LTO (Link 
Time Optimization). I saw reduced binary sizes on my apps, it'd be 
interesting to hear other experiences.


Ideally, the druntime library should be come with the operating system 
so every user has a copy of it. Practically, I can't see that happening 
for the foreseeable future. It doesn't even happen for Windows with 
Microsoft's own compiler.


But even though it doesn't come with Windows, it can be installed once, 
and shared between all applications that use it.


The issue with druntime isn't that it's not installed, it's the static 
linking.


A second problem is that due to the way D works most of the time (with 
templates just about everywhere), each new release is likely to be 
binary-incompatible. So you will essentially need many copies of 
druntime, probably one per release that was used to compile any D 
programs on your system. But this is much less of an issue, especially 
if there are many programs that build using the same release.


-Steve

Re: Changing the class data underneath some reference

[A Guy With a Question via Digitalmars-d-learn]

On Thursday, 30 November 2017 at 00:40:51 UTC, David Colson wrote:

Hello all!

I'm getting settled into D and I came into a problem. A code 
sample shows it best:


class SomeType
{
string text;
this(string input) {text = input;}
}


void main()
{
SomeType foo = new SomeType("Hello");

SomeType bar = foo;

foo = new SomeType("World");

writeln(bar.text); // Prints hello
// I'd like it to print World
}

In the C++ world I could do this using pointers and changing 
the data underneath a given pointer, but I can't use pointers 
in D, so I'm not sure how I can get this behaviour?


I'd be open to other ways of achieving the same affect in D, 
using more D like methods.


You are dealing with a reference type. Reference types can be 
though of as a value type of an address. The new operator can be 
though of as giving the variable a new address. This means the 
foo and bar variables are not bound to the same value because 
their referencing different address. You need a struct. Which 
isn't a reference.

Re: Thoughts about D

[Walter Bright via Digitalmars-d]

On 11/29/2017 3:36 PM, Jon Degenhardt wrote:

On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh wrote:
While generally I would still use fullblown D rather than BetterC for my 
projects, the bloat from druntime/phobos does still bother me at the back of 
my mind.  IIRC, the Phobos docs used to state that the philosophy for Phobos 
is pay-as-you-go. As in, if you don't use feature X, the code and associated 
data that implements feature X shouldn't even appear in the executable. It 
seems that we have fallen away from that for a while now.  Perhaps it's time 
to move D back in that direction.


If there specific apps where druntime and/or phobos bloat is thought to be too 
high, it might be worth trying the new LDC support for building a binary with 
druntime and phobos compiled with LTO (Link Time Optimization). I saw reduced 
binary sizes on my apps, it'd be interesting to hear other experiences.


Ideally, the druntime library should be come with the operating system so every 
user has a copy of it. Practically, I can't see that happening for the 
foreseeable future. It doesn't even happen for Windows with Microsoft's own 
compiler.

Re: Thoughts about D

[Walter Bright via Digitalmars-d]

On 11/29/2017 8:57 AM, H. S. Teoh wrote:

BetterC is a door-opener for an awful lot of areas D has been excluded
from, and requiring druntime is a barrier for that.

Doesn't this mean that we should rather focus our efforts on improving
druntime instead of throwing out the baby with the bathwater with
BetterC?


What BetterC does is shine a spotlight on these issues. They've also come up 
with Ilya Yaroshenko's work.




For example, the way assert() works, if indeed it's overblown, then
shouldn't we rather fix/improve it?


I've tried, and met a lot of resistance.

Re: Changing the class data underneath some reference

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/29/17 7:40 PM, David Colson wrote:

Hello all!

I'm getting settled into D and I came into a problem. A code sample 
shows it best:


class SomeType
{
     string text;
     this(string input) {text = input;}
}


void main()
{
     SomeType foo = new SomeType("Hello");

     SomeType bar = foo;

     foo = new SomeType("World");

     writeln(bar.text); // Prints hello
     // I'd like it to print World
}

In the C++ world I could do this using pointers and changing the data 
underneath a given pointer, but I can't use pointers in D, so I'm not 
sure how I can get this behaviour?


I'd be open to other ways of achieving the same affect in D, using more 
D like methods.


D does not support reassigning class data using assignment operator, 
only the class reference. You can change the fields individually if you 
need to.


e.g.:

foo.text = "World";

structs are value types in D and will behave similar to C++ classes/structs.

-Steve

Re: Thoughts about D

[A Guy With a Question via Digitalmars-d]

On Thursday, 30 November 2017 at 00:23:10 UTC, codephantom wrote:
On Thursday, 30 November 2017 at 00:05:10 UTC, Michael V. 
Franklin wrote:
On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh 
wrote:


Doesn't this mean that we should rather focus our efforts on 
improving druntime instead of throwing out the baby with the 
bathwater with BetterC?


Exactly!  We should be making a better D, not a better C.

Mike


There is no better C, than C, full stop.

-betterC  should become ..   -slimD

But we really do need a focus on both -slimD and -bloatyD

For D to be successful, it needs to be a flexible language that 
enables programmer choice. We don't all have the same problems 
to solve.


C is not successful because of how much it constrains you.


I'm personally a big believer that the thing that will replace C 
is going to be something that is flexible, but more than anything 
prevents the security bugs that plague the web right now. Things 
like heartbleed are preventable with safety guarantees that don't 
prevent fast code. Rust has some good ideas, but so does D.

Re: We're looking for a Software Developer! (D language)

[Joakim via Digitalmars-d-announce]

On Wednesday, 29 November 2017 at 10:47:31 UTC, aberba wrote:
On Thursday, 8 January 2015 at 11:10:09 UTC, Johanna Burgos 
wrote:

Your Mission




Your Track Record

Degree in Computer Science, or closely-related



It baffles me that recruitment still works using this as a 
requirement. A CS graduate will never know any of these besides 
basic intro to C, C++, html, css,  databases,  and basic 
hardware-software theory... without self learning and practice.


I've never sat in a cs class for a second and I will be bored 
to death learning these stuff in lectures. I learnt them beyond 
the syllables years back on my own at a much quicker pase.


You become experienced and skilled when you're passionate about 
it.  Its how I started from being curious about how software is 
made to a full stack generalist... knowing more stack than the 
above requirements.


You want skills not pedigree.


Incompetence in hiring and HR is par for the course pretty much 
everywhere, lots of threads about it on proggit/HN/blogs these 
days.  Take for example the recent sexual harassment scandals in 
the US, where HR depts did nothing for decades.  People rightly 
complain about much smaller stuff than that not getting done well 
by HR, so of course they don't handle real malfeasance properly.


The biggest joke is that these companies all claim they want the 
best talent, when they have no idea what the best is in the first 
place:


https://danluu.com/programmer-moneyball/

It is one of the main reasons for the rise of open source, 
because you can't stop anyone from contributing or forking, 
assuming they have the extra time/money to do so.

Re: Floating point types default to NaN?

[codephantom via Digitalmars-d-learn]

On Friday, 24 November 2017 at 14:30:44 UTC, A Guy With a 
Question wrote:
I would have expected 0 to be the default value. What's the 
logic behind having them being NaN by default?


https://dlang.org/spec/type.html



http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723

Re: Changing the class data underneath some reference

[codephantom via Digitalmars-d-learn]

On Thursday, 30 November 2017 at 00:52:25 UTC, codephantom wrote:

...


sorry, don't know how the int * got in there ;-)

Anyway..who said you can't use pointers in D?

Just change:


//SomeType bar = foo;
SomeType * bar = 

Re: Localization (i18n) Options

[Gerald via Digitalmars-d]

On Tuesday, 28 November 2017 at 07:39:19 UTC, Ivan Trombley wrote:

On Sunday, 24 January 2016 at 19:18:28 UTC, Gerald wrote:

On Monday, 18 January 2016 at 09:04:48 UTC, Luis wrote:
Please, write a HowTo some where. GtkD lack of documentation 
it's very anoying.


I've gotten this going with Terminix and posted some 
information what it took to get it going here:


http://gexperts.com/wp/gtkd-and-localization/


I tried this out but I get this compile error:
  "Error: static variable c_g_dgettext cannot be read at 
compile time"


Did you have any issues like this?


Nope, you can see how Tilix is doing localization in it's repo 
below. I haven't looked at the localization code in awhile so I 
can't remember how well it still aligns with that blog post.


https://gitHub.com/gnunn1/tilux

Re: Changing the class data underneath some reference

[codephantom via Digitalmars-d-learn]

On Thursday, 30 November 2017 at 00:40:51 UTC, David Colson wrote:

Hello all!

I'm getting settled into D and I came into a problem. A code 
sample shows it best:


class SomeType
{
string text;
this(string input) {text = input;}
}


void main()
{
SomeType foo = new SomeType("Hello");

SomeType bar = foo;

foo = new SomeType("World");

writeln(bar.text); // Prints hello
// I'd like it to print World
}

In the C++ world I could do this using pointers and changing 
the data underneath a given pointer, but I can't use pointers 
in D, so I'm not sure how I can get this behaviour?


I'd be open to other ways of achieving the same affect in D, 
using more D like methods.



void main()
{
SomeType foo = new SomeType("Hello");

int * ptr;
SomeType * bar;
bar = 

foo = new SomeType("World");

writeln(bar.text); // Prints World

}

Re: Changing the class data underneath some reference

[David Colson via Digitalmars-d-learn]

On Thursday, 30 November 2017 at 00:40:51 UTC, David Colson wrote:

Hello all!

I'm getting settled into D and I came into a problem. A code 
sample shows it best:


class SomeType
{
string text;
this(string input) {text = input;}
}


void main()
{
SomeType foo = new SomeType("Hello");

SomeType bar = foo;

foo = new SomeType("World");

writeln(bar.text); // Prints hello
// I'd like it to print World
}

In the C++ world I could do this using pointers and changing 
the data underneath a given pointer, but I can't use pointers 
in D, so I'm not sure how I can get this behaviour?


I'd be open to other ways of achieving the same affect in D, 
using more D like methods.


I made an example demonstrating what I'd do in C++:

class SomeType
{
public:
std::string text;
SomeType(std::string input) {text = input;}
};


int main()
{
SomeType foo = SomeType("Hello");

SomeType* bar = 

foo = SomeType("World");

std::cout << bar->text << "\n"; // Prints World
}

Changing the class data underneath some reference

[David Colson via Digitalmars-d-learn]

Hello all!

I'm getting settled into D and I came into a problem. A code 
sample shows it best:


class SomeType
{
string text;
this(string input) {text = input;}
}


void main()
{
SomeType foo = new SomeType("Hello");

SomeType bar = foo;

foo = new SomeType("World");

writeln(bar.text); // Prints hello
// I'd like it to print World
}

In the C++ world I could do this using pointers and changing the 
data underneath a given pointer, but I can't use pointers in D, 
so I'm not sure how I can get this behaviour?


I'd be open to other ways of achieving the same affect in D, 
using more D like methods.

Re: Thoughts about D

[codephantom via Digitalmars-d]

On Thursday, 30 November 2017 at 00:05:10 UTC, Michael V. 
Franklin wrote:
On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh 
wrote:


Doesn't this mean that we should rather focus our efforts on 
improving druntime instead of throwing out the baby with the 
bathwater with BetterC?


Exactly!  We should be making a better D, not a better C.

Mike


There is no better C, than C, full stop.

-betterC  should become ..   -slimD

But we really do need a focus on both -slimD and -bloatyD

For D to be successful, it needs to be a flexible language that 
enables programmer choice. We don't all have the same problems to 
solve.


C is not successful because of how much it constrains you.

Re: Thoughts about D

[Michael V. Franklin via Digitalmars-d]

On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh wrote:

Doesn't this mean that we should rather focus our efforts on 
improving druntime instead of throwing out the baby with the 
bathwater with BetterC?


Exactly!  We should be making a better D, not a better C.

Mike

Re: Thoughts about D

[Jon Degenhardt via Digitalmars-d]

On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh wrote:
While generally I would still use fullblown D rather than 
BetterC for my projects, the bloat from druntime/phobos does 
still bother me at the back of my mind.  IIRC, the Phobos docs 
used to state that the philosophy for Phobos is pay-as-you-go. 
As in, if you don't use feature X, the code and associated data 
that implements feature X shouldn't even appear in the 
executable. It seems that we have fallen away from that for a 
while now.  Perhaps it's time to move D back in that direction.


If there specific apps where druntime and/or phobos bloat is 
thought to be too high, it might be worth trying the new LDC 
support for building a binary with druntime and phobos compiled 
with LTO (Link Time Optimization). I saw reduced binary sizes on 
my apps, it'd be interesting to hear other experiences.

Re: Attributes on Enum Members: Call for use cases.

[Steven Schveighoffer via Digitalmars-d]

On 11/29/17 4:46 PM, Timon Gehr wrote:

On 29.11.2017 20:49, Steven Schveighoffer wrote:

On 11/29/17 2:01 PM, Timon Gehr wrote:

OK, now I get what you are saying. In the same vein, I tested applying 
attributes to functions themselves:


@("a") int fun() { return 0; }
pragma(msg, typeof()); // int function()

@("b") int gun() { return 1; }
pragma(msg, typeof()); // int function()

void main()
{
   auto f = 
   f =  // works
}

Given that, it seems attributes play no part in the type itself, they 
are just metadata in the compiler.


Well, I think the case of UDAs on parameters is closer to:

struct S{
     @("a") int x1;
     @("b") int x2;
}

The attributes on x1 and x2 are indeed part of the type S, even if the 
attributes on S itself are not.


Right, but unlike functions, you can't make another "overload" of a struct.



If we go with "UDAs on parameters are not part of the function type", 
how to you get the UDAs of the parameters of some function?


Looking at std.traits, it looks like we use this mechanism to get 
everything:


int func(int param1)

static if(is(typeof(func) F == __parameters))
{
static assert(is(typeof(F[0]) == int));
static assert(__traits(identifier, F[0]) == "param1");
}

This is how vibe.d associates the function-level attributes with the 
name of the parameter.


It wouldn't be a giant leap to make this work with attributes as well.

-Steve

Re: Attributes on Enum Members: Call for use cases.

[John via Digitalmars-d]

On Wednesday, 29 November 2017 at 21:46:51 UTC, Timon Gehr wrote:

On 29.11.2017 20:49, Steven Schveighoffer wrote:

On 11/29/17 2:01 PM, Timon Gehr wrote:

OK, now I get what you are saying. In the same vein, I tested 
applying attributes to functions themselves:


@("a") int fun() { return 0; }
pragma(msg, typeof()); // int function()

@("b") int gun() { return 1; }
pragma(msg, typeof()); // int function()

void main()
{
   auto f = 
   f =  // works
}

Given that, it seems attributes play no part in the type 
itself, they are just metadata in the compiler.


Well, I think the case of UDAs on parameters is closer to:

struct S{
@("a") int x1;
@("b") int x2;
}

The attributes on x1 and x2 are indeed part of the type S, even 
if the attributes on S itself are not.


If we go with "UDAs on parameters are not part of the function 
type", how to you get the UDAs of the parameters of some 
function?


The function would have to be passed directly to __traits() to 
get the UDA. If passed to a function, it would have to be via 
alias:


void func(@attr int param) { }

void test(alias f)()
{
writeln(getParameterAttr!(f, 0)); // or however to implement 
getting the attribute

}

test!func(); // prints @attr

Re: Attributes on Enum Members: Call for use cases.

[Timon Gehr via Digitalmars-d]

On 29.11.2017 20:49, Steven Schveighoffer wrote:

On 11/29/17 2:01 PM, Timon Gehr wrote:

OK, now I get what you are saying. In the same vein, I tested applying 
attributes to functions themselves:


@("a") int fun() { return 0; }
pragma(msg, typeof()); // int function()

@("b") int gun() { return 1; }
pragma(msg, typeof()); // int function()

void main()
{
   auto f = 
   f =  // works
}

Given that, it seems attributes play no part in the type itself, they 
are just metadata in the compiler.


Well, I think the case of UDAs on parameters is closer to:

struct S{
@("a") int x1;
@("b") int x2;
}

The attributes on x1 and x2 are indeed part of the type S, even if the 
attributes on S itself are not.


If we go with "UDAs on parameters are not part of the function type", 
how to you get the UDAs of the parameters of some function?

Re: Note from a donor

[Joakim via Digitalmars-d]

On Friday, 17 November 2017 at 23:35:49 UTC, MrSmith wrote:
On Friday, 17 November 2017 at 23:31:07 UTC, David Nadlinger 
wrote:
The more promising avenue would probably be to distribute LLD 
with DMD. This still leaves the system library licensing to 
deal with, but if I remember correctly, one of the usual 
suspects (Rainer? Vladimir?) was working on generating them 
from MinGW headers.


 — David


Btw, what about LIBC from DMC, is it open source now too? Can 
we use it with DMD?


No, but there is some talk of doing something about it in a more 
recent thread:


http://forum.dlang.org/post/ovj98g$26r9$1...@digitalmars.com

Re: Time to move logger from experimental to std ?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, November 29, 2017 14:32:54 Basile B. via Digitalmars-d wrote:
> Hello, most of the changes made during the current year to the
> std.experimental.logger package are related to the cosmetic
> style. Isn't this a sign showing that the experimentation is
> achieved ?
>
>
> Facts:
> - There only 4 issues for logger -
> https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW
> _status=ASSIGNED_status=REOPENED=phobos=OP=OP=p
> roduct=component=alias=short_desc=content=CP=CP=OR
> st_id=218035=substring=substring=substring=substring=substr
> ing=matches_format=advanced_desc=logger_desc_type=all
> wordssubstr=logger=logger=logger=logger=logger=%22logger
> %22 - The history, mostly style things:
> https://github.com/dlang/phobos/commits/master/std/experimental/logger

It was my understanding that there were still problems with its design that
Robert wanted to fix, but I don't know where any of that stands. But
certainly, I don't think that it makes sense to push forward with trying to
get the logger out of experimental without his feedback.

Personally, I would _really_ like to see
https://issues.dlang.org/show_bug.cgi?id=8687 dealt with so that file and
line number can be runtime arguments rather than compile time arguments so
that you don't end up with a new template instantiation every time you log
something.

- Jonathan M Davis

Re: Chocolatey Packages for DMD, LDC, and GDC

[Manuel Maier via Digitalmars-d]

On Wednesday, 29 November 2017 at 16:04:04 UTC, Jacob Carlborg 
wrote:

On 2017-11-28 20:04, Manuel Maier wrote:
Another thing I don't think it does is patching the sc.ini 
with Visual Studio environment variables, like the dmd 
installer does.


No, it basically only extracts the downloaded archive.


That's the one nice thing about the dmd installer, it takes care 
of setting up the default environment for you if it detects 
Visual Studio to be installed. I think this is most useful for 
Windows people coming from Visual Studio who are used to having 
the environment being set up for them.


I myself am one of these people, but I don't entirely endorse the 
way Visual Studio solves this problem. I need to decide to either 
use the Visual Studio GUI, or use one of the "x86 Native Tools 
Command Prompt" links, or seek out the batch file that sets up 
the environment for me. So it basically forces you to choose 
between devenv (which takes a million years to boot) and cmd 
(which is not what I'd call a inconvenient terminal). The only 
other option is to basically emulate the VsDevCmd.bat script and 
manually gather all the necessary info (the very thing the dmd 
installer does if I'm not mistaken).


If you're not using the digital mars linker, you still have those 
age old workflow problems, regardless of whether it's C++ or D. 
And that bugs me quite a bit. I'd love to see a clean solution 
where the developer has the choice of which environment to use, 
can quickly switch between these environments, and is able to put 
them in some kind of manifest to be checked into a git repo or 
something alike to be shared with fellow developers and CI 
systems.


P.S.: Sorry for the ranting...

Re: Time to move logger from experimental to std ?

[Claude via Digitalmars-d]

On Wednesday, 29 November 2017 at 14:32:54 UTC, Basile B. wrote:
Hello, most of the changes made during the current year to the 
std.experimental.logger package are related to the cosmetic 
style. Isn't this a sign showing that the experimentation is 
achieved ?


I tried deriving FileLogger class to implement my own log 
fomatting. I overrided beginLogMsg, logMsgPart or finishLogMsg, 
but I could not do anything with it because the handle "file_" is 
private (so I cannot access it within the derived class).


So I ended up rewriting my own FileLogger deriving directly from 
Logger and copying most of the Phobos version code, but that's 
not convenient.


Did I miss anything?

Re: First Impressions!

[A Guy With a Question via Digitalmars-d]

On Tuesday, 28 November 2017 at 22:08:48 UTC, Mike Parker wrote:
On Tuesday, 28 November 2017 at 19:39:19 UTC, Michael V. 
Franklin wrote:


This DIP is related 
(https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md) 
but I don't know what's happening with it.




It's awaiting formal review. I'll move it forward when the 
formal review queue clears out a bit.


How well does phobos play with it? I'm finding, for instance, 
it's not playing too well with nothrow. Things throw that I don't 
understand why.

Re: Chocolatey Packages for DMD, LDC, and GDC

[Manuel Maier via Digitalmars-d]

On Wednesday, 29 November 2017 at 01:49:00 UTC, rjframe wrote:

dvm works well with cmd; not so much with Powershell.


Indeed, I was using powershell! Using cmd now and suddenly it all 
works.


In Powershell, the current directory and working directory are 
separate; `cd` outside your home folder and execute 
`Get-Location` and '[environment]::CurrentDirectory` to see 
them both. Powershell lets you do things like set a registry 
key (and other non-filesystem objects) as your working 
directory (`cd HKLM:\SOFTWARE; ls`)


I've actually come across this myself a couple times already, 
though I didn't really investigate what the cause of it was. Well 
now I know.


Thanks for pointing this out! Maybe it would be worthwhile to add 
some kind of "FAQ" or "Troubleshooting" section to the GitHub 
README of dvm.

Re: Basic questions about D lang?

[Jesse Phillips via Digitalmars-d-learn]

On Tuesday, 28 November 2017 at 13:39:11 UTC, Jayam wrote:

Can we compile our program to multi program ?


Based on your C# reference you must be referring to the "Mixed 
Platform" build option. No, that is a .NET thing and D is not on 
.NET (that project has died).


D requires a more traditional approach to multiple platforms, 
you'll need to write your code with the needs of your supported 
platforms in mind. Luckily in pure D this is like no work, but 
when you interface to C/C++ libraries you'll hit sizes of types 
and structures changing almost randomly (ok it isn't that bad).

Re: Attributes on Enum Members: Call for use cases.

[Steven Schveighoffer via Digitalmars-d]

On 11/29/17 2:01 PM, Timon Gehr wrote:

OK, now I get what you are saying. In the same vein, I tested applying 
attributes to functions themselves:


@("a") int fun() { return 0; }
pragma(msg, typeof()); // int function()

@("b") int gun() { return 1; }
pragma(msg, typeof()); // int function()

void main()
{
  auto f = 
  f =  // works
}

Given that, it seems attributes play no part in the type itself, they 
are just metadata in the compiler.


I would say:



struct attribute1{}
struct attribute2{}

int foo(@attribute1 int x){ return x; }
int bar(@attribute2 int y){ return y; }

pragma(msg, typeof()); // int function(@attribute1 int x)?


int function(int)


pragam(msg, typeof()); // int function(@attribute2 int x)?


same



auto apply(F,A)(F fun,A arg){
     pragma(msg, F); // ? (instantiations below)


same


     return fun(arg);
}

void main(){
     apply(,1); // one instantiation
     apply(,1); // second instantiation, or same instance?


same instance


}

auto weird(){
     int x;
     void foo(@x int y){}
     return 
}

pragma(msg, typeof(weird())); // ?


void delegate(int)

-Steve

Re: Time to move logger from experimental to std ?

[Nathan S. via Digitalmars-d]

On Wednesday, 29 November 2017 at 14:32:54 UTC, Basile B. wrote:

- There only 4 issues for logger


Considering that one of those issues is that the logger outputs 
garbage when given a wstring or a dstring, I would not take this 
as an indication that it's time to "graduate" the logger from 
experimental.

Re: Time to move logger from experimental to std ?

[notna via Digitalmars-d]

On Wednesday, 29 November 2017 at 14:32:54 UTC, Basile B. wrote:
Hello, most of the changes made during the current year to the 
std.experimental.logger package are related to the cosmetic 
style. Isn't this a sign showing that the experimentation is 
achieved ?


[...]


+1

Re: Attributes on Enum Members: Call for use cases.

[Timon Gehr via Digitalmars-d]

On 29.11.2017 19:18, Steven Schveighoffer wrote:

On 11/29/17 12:20 PM, Timon Gehr wrote:


I don't understand what you mean. Function types _contain_ parameter 
declarations. (Including attributes and default initializers.)


I too, am confused. I thought you meant that the types of the parameters 
would have attributes that might conflict/merge with the attributes 
declared on the parameters.


So maybe a snippet of code to further explain your concern?

-Steve


struct attribute1{}
struct attribute2{}

int foo(@attribute1 int x){ return x; }
int bar(@attribute2 int y){ return y; }

pragma(msg, typeof()); // int function(@attribute1 int x)?
pragam(msg, typeof()); // int function(@attribute2 int x)?

auto apply(F,A)(F fun,A arg){
pragma(msg, F); // ? (instantiations below)
return fun(arg);
}

void main(){
apply(,1); // one instantiation
apply(,1); // second instantiation, or same instance?
}

auto weird(){
int x;
void foo(@x int y){}
return 
}

pragma(msg, typeof(weird())); // ?

Re: Andrei's "The D Programming Language" book. Up to date?

[John Gabriele via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 17:26:11 UTC, Nick Treleaven 
wrote:
On Wednesday, 4 October 2017 at 20:49:26 UTC, John Gabriele 
wrote:
What's changed in the language, library, and community since 
then that I should be aware of if following along with and 
learning from that book?


Here's a list of significant things - maybe incomplete:
https://wiki.dlang.org/Differences_With_TDPL


Nice! Thanks, Nick!

Re: Thoughts about D

[bpr via Digitalmars-d]

On Wednesday, 29 November 2017 at 16:57:36 UTC, H. S. Teoh wrote:
On Tue, Nov 28, 2017 at 06:18:20PM -0800, Walter Bright via 
Digitalmars-d wrote: [...]
BetterC is a door-opener for an awful lot of areas D has been 
excluded from, and requiring druntime is a barrier for that.


Doesn't this mean that we should rather focus our efforts on 
improving druntime instead of throwing out the baby with the 
bathwater with BetterC?


Isn't it possible to do both? For example, make D's GC a precise 
one (thus improving the runtime) and making the experience of 
using D sans GC and runtime a simple one?


In answer to your question, if D is excluded from a lot of areas 
on account of requiring druntime, then it may be that no version 
of what you expect from druntime (I'll use GC as an obvious 
example) will remove that barrier.

Re: Attributes on Enum Members: Call for use cases.

[Steven Schveighoffer via Digitalmars-d]

On 11/29/17 12:20 PM, Timon Gehr wrote:


I don't understand what you mean. Function types _contain_ parameter 
declarations. (Including attributes and default initializers.)


I too, am confused. I thought you meant that the types of the parameters 
would have attributes that might conflict/merge with the attributes 
declared on the parameters.


So maybe a snippet of code to further explain your concern?

-Steve

Re: Andrei's "The D Programming Language" book. Up to date?

[Nick Treleaven via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 17:50:59 UTC, Arun 
Chandrasekaran wrote:

Multiple alias this
You can only have one subtyping member currently.



Shared
Not all of shared's guarantees are implemented yet.



SafeD
@safe (and therefore SafeD) isn't fully implemented. So, it 
doesn't necessarily work quite like it's supposed to yet.


How much of these are relevant today with 2.077.0?


The first two are true AIUI. @safe is mostly implemented, there's 
been a lot of progress on that since TDPL.

Re: Andrei's "The D Programming Language" book. Up to date?

[Arun Chandrasekaran via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 17:26:11 UTC, Nick Treleaven 
wrote:

Here's a list of significant things - maybe incomplete:
https://wiki.dlang.org/Differences_With_TDPL



Multiple alias this
You can only have one subtyping member currently.



Shared
Not all of shared's guarantees are implemented yet.



SafeD
@safe (and therefore SafeD) isn't fully implemented. So, it 
doesn't necessarily work quite like it's supposed to yet.


How much of these are relevant today with 2.077.0?

Re: Introducing Nullable Reference Types in C#. Is there hope for D, too?

[Nick Treleaven via Digitalmars-d]

On Sunday, 19 November 2017 at 22:54:38 UTC, Walter Bright wrote:
I can't see the problem. You go from nullable to non-nullable 
by checking for null, and the other direction happens 
implicitly.


Implicit conversions have their problems with overloading,


The C# implementation doesn't affect overloading:

"There is no semantic impact of the nullability annotations, 
other than the warnings. They don’t affect overload resolution or 
runtime behavior, and generate the same IL output code. They only 
affect type inference insofar as it passes them through and keeps 
track of them in order for the right warnings to occur on the 
other end."


interactions with const, template argument deduction, 
surprising edge cases, probably breaking a lot of Phobos, etc. 
It's best not to layer on more of this stuff. Explicit casting 
is a problem, too.


Maybe this can be mitigated by having the compiler just do the 
job of tracking null tests and making this information available 
to a NotNull user defined type.

[Issue 18020] New: [Reg 2.078] no property opCmp for anon class

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18020
   Summary: [Reg 2.078] no property opCmp for anon class
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: rejects-valid
  Severity: regression
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
void bug(T)(T t)
{
t.opCmp(t);
}

alias bugi = bug!(typeof(new class{}));
CODE
dmd -c -o- bug.d

bug.d(3): Error: no property 'opCmp' for type 'bug.__anonclass1'
bug.d(6): Error: template instance bug.bug!(__anonclass1) error instantiating


Introduced by https://github.com/dlang/dmd/pull/7315.

--

Re: Andrei's "The D Programming Language" book. Up to date?

[Nick Treleaven via Digitalmars-d-learn]

On Wednesday, 4 October 2017 at 20:49:26 UTC, John Gabriele wrote:
What's changed in the language, library, and community since 
then that I should be aware of if following along with and 
learning from that book?


Here's a list of significant things - maybe incomplete:
https://wiki.dlang.org/Differences_With_TDPL

Re: Attributes on Enum Members: Call for use cases.

[Timon Gehr via Digitalmars-d]

On 29.11.2017 17:58, Steven Schveighoffer wrote:

On 11/29/17 11:45 AM, Timon Gehr wrote:

On 29.11.2017 17:21, Andrei Alexandrescu wrote:

On 11/29/2017 07:53 AM, Seb wrote:

UDAs for function arguments would be really awesome to have.


They should be part of the same DIP. -- Andrei


More generally, any declaration should ideally support UDAs.

One issue with UDAs on function arguments is that function types will 
then have embedded UDAs, so the DIP should specify how that works.


Wouldn't it work the same as this?

@("foo")
struct S
{

}

void main()
{
     import std.stdio;
     @("bar") S s1;
     S s2;
     writeln(__traits(getAttributes, s1)); // bar
     writeln(__traits(getAttributes, typeof(s1))); // foo
     writeln(__traits(getAttributes, s2)); // (nothing)
     writeln(__traits(getAttributes, typeof(s2))); // foo
}

-Steve


I don't understand what you mean. Function types _contain_ parameter 
declarations. (Including attributes and default initializers.)

Re: Shared and race conditions

[Michael via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 17:03:42 UTC, Steven 
Schveighoffer wrote:

On 11/29/17 11:13 AM, Wanderer wrote:
I'm trying to simulate a race condition in D with the 
following code:


(https://run.dlang.io/is/RfOX0I)


One word of caution, I think the running of your code on 
run.dlang.io is cached. Refreshing doesn't make it re-run.


https://run.dlang.io/is/k0LhQA

-Steve


Ah good catch.

Re: Attributes on Enum Members: Call for use cases.

[Meta via Digitalmars-d]

On Wednesday, 29 November 2017 at 16:45:04 UTC, Timon Gehr wrote:

On 29.11.2017 17:21, Andrei Alexandrescu wrote:

On 11/29/2017 07:53 AM, Seb wrote:

UDAs for function arguments would be really awesome to have.


They should be part of the same DIP. -- Andrei


More generally, any declaration should ideally support UDAs.

One issue with UDAs on function arguments is that function 
types will then have embedded UDAs, so the DIP should specify 
how that works.


You have much more experience in how compilers work on the 
implementation level than me. What semantics are possible?


It makes sense to me that UDAs on function arguments should only 
be for documentation/reflection purposes. Therefore:


int fun(@Nonnull Object o);

Is considered to be equivalent to:

int fun(Object o);

And similarly:

import std.traits;
Parameters!fun -> (Object), not (@Nonnull Object)

However:

int fun(@Nonnull Object o)
{
static if (is(typeof(fun) Params == __parameters))
{
static foreach (p; Params)
{
pragma(msg, __traits(getUDAs, p)); //Should print 
Nonnull

}
}
}

Unfortunately I don't think we can have both as that would mean 
that UDAs would have to be part of the function signature. Is 
there a way around this?

Re: Shared and race conditions

[Wanderer via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 17:03:42 UTC, Steven 
Schveighoffer wrote:

On 11/29/17 11:13 AM, Wanderer wrote:
I'm trying to simulate a race condition in D with the 
following code:


(https://run.dlang.io/is/RfOX0I)


One word of caution, I think the running of your code on 
run.dlang.io is cached. Refreshing doesn't make it re-run.


https://run.dlang.io/is/k0LhQA

-Steve


I was using this just for the reference, as I've noticed caching 
as well.

Thanks Steve, for spending time and actually hitting a race!

Re: Thoughts about D

[H. S. Teoh via Digitalmars-d]

On Tue, Nov 28, 2017 at 06:18:20PM -0800, Walter Bright via Digitalmars-d wrote:
[...]
> When the C version is 90K and the translated D version is 1200K, it is
> a barrier. It's a barrier for others, as well.
> 
> Another barrier for me has turned out to be the way assert() works in
> D. It just is not lightweight, and it visibly slows down dmd to have
> assert's turned on internally. The amount of machinery involved with
> it in druntime is way overblown. Hence, asserts in dmd are turned off,
> and that wound up causing me a lot of problems recently. There are
> even initiatives to add writefln like formatting to asserts. With
> betterC, asserts became lightweight and simple again.
> 
> Andrei's been directing some work on using templates more in druntime
> to reduce this, such as Lucia's work. Martin has done some work with
> array ops, too.
> 
> Exception handling support has been a bloat problem, too. DMC++ is
> built with all exceptions turned off. I've been writing PRs for dmd to
> greatly improve things so that it can generate similar code for RAII.
> (Exceptions require druntime.)
> 
> BetterC is a door-opener for an awful lot of areas D has been excluded
> from, and requiring druntime is a barrier for that.

Doesn't this mean that we should rather focus our efforts on improving
druntime instead of throwing out the baby with the bathwater with
BetterC?

For example, the way assert() works, if indeed it's overblown, then
shouldn't we rather fix/improve it?

While generally I would still use fullblown D rather than BetterC for my
projects, the bloat from druntime/phobos does still bother me at the
back of my mind.  IIRC, the Phobos docs used to state that the
philosophy for Phobos is pay-as-you-go. As in, if you don't use feature
X, the code and associated data that implements feature X shouldn't even
appear in the executable. It seems that we have fallen away from that
for a while now.  Perhaps it's time to move D back in that direction.


T

-- 
I've been around long enough to have seen an endless parade of magic new 
techniques du jour, most of which purport to remove the necessity of thought 
about your programming problem.  In the end they wind up contributing one or 
two pieces to the collective wisdom, and fade away in the rearview mirror. -- 
Walter Bright

Re: Shared and race conditions

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/29/17 11:13 AM, Wanderer wrote:

I'm trying to simulate a race condition in D with the following code:

(https://run.dlang.io/is/RfOX0I)


One word of caution, I think the running of your code on run.dlang.io is 
cached. Refreshing doesn't make it re-run.


https://run.dlang.io/is/k0LhQA

-Steve

Re: Shared and race conditions

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/29/17 11:51 AM, Michael wrote:

On Wednesday, 29 November 2017 at 16:33:50 UTC, Steven Schveighoffer wrote:

On 11/29/17 11:13 AM, Wanderer wrote:

[...]


[snip]


[...]


Using the compiler switch -vcg-ast, I see no synchronization of these 
methods.


[...]


Any idea what has changed in DMD-nightly to retain the correct ordering 
of IDs?


No idea. Perhaps it was another factor, as machine busyness could affect 
the ordering.


The ordering of when the ids are fetched is pretty much the same (as 
long as no race has happened). It's really the printing of the ids that 
might be affected.


-Steve

Re: Attributes on Enum Members: Call for use cases.

[Steven Schveighoffer via Digitalmars-d]

On 11/29/17 11:45 AM, Timon Gehr wrote:

On 29.11.2017 17:21, Andrei Alexandrescu wrote:

On 11/29/2017 07:53 AM, Seb wrote:

UDAs for function arguments would be really awesome to have.


They should be part of the same DIP. -- Andrei


More generally, any declaration should ideally support UDAs.

One issue with UDAs on function arguments is that function types will 
then have embedded UDAs, so the DIP should specify how that works.


Wouldn't it work the same as this?

@("foo")
struct S
{

}

void main()
{
import std.stdio;
@("bar") S s1;
S s2;
writeln(__traits(getAttributes, s1)); // bar
writeln(__traits(getAttributes, typeof(s1))); // foo
writeln(__traits(getAttributes, s2)); // (nothing)
writeln(__traits(getAttributes, typeof(s2))); // foo
}

-Steve

Re: Shared and race conditions

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/29/17 11:46 AM, Wanderer wrote:

On Wednesday, 29 November 2017 at 16:33:50 UTC, Steven Schveighoffer wrote:

On 11/29/17 11:13 AM, Wanderer wrote:

[...]


[snip]


[...]


Using the compiler switch -vcg-ast, I see no synchronization of these 
methods.


[...]


That's what I assume, I was just lucky not to see a race.
Thanks for `-vcg-ast` switch! Really helpful, and it answered my 
questions as no syncronization code was added.


FYI, I ran this about 15 times, finally got one:

Stevens-MacBook-Pro:testd steves$ ./testshared
next: MyId(1)
next: MyId(2)
next: MyId(3)
next: MyId(4)
next: MyId(5)
next: MyId(6)
next: MyId(7)
next: MyId(8)
next: MyId(9)
next: MyId(10)
next: MyId(11)
next: MyId(12)
next: MyId(12) <=== race
next: MyId(13)
next: MyId(14)
next: MyId(15)
next: MyId(16)
next: MyId(17)
next: MyId(18)
next: MyId(19)
next: MyId(20)
next: MyId(21)
next: MyId(22)
next: MyId(23)
Done

-Steve

Re: Shared and race conditions

[Michael via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 16:33:50 UTC, Steven 
Schveighoffer wrote:

On 11/29/17 11:13 AM, Wanderer wrote:

[...]


[snip]


[...]


Using the compiler switch -vcg-ast, I see no synchronization of 
these methods.


[...]


Any idea what has changed in DMD-nightly to retain the correct 
ordering of IDs?

Re: Time to move logger from experimental to std ?

[Jack Stouffer via Digitalmars-d]

On Wednesday, 29 November 2017 at 14:32:54 UTC, Basile B. wrote:
Hello, most of the changes made during the current year to the 
std.experimental.logger package are related to the cosmetic 
style. Isn't this a sign showing that the experimentation is 
achieved ?



Facts:
- There only 4 issues for logger - 
https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED=phobos=OP=OP=product=component=alias=short_desc=content=CP=CP=OR_id=218035=substring=substring=substring=substring=substring=matches_format=advanced_desc=logger_desc_type=allwordssubstr=logger=logger=logger=logger=logger=%22logger%22
- The history, mostly style things: 
https://github.com/dlang/phobos/commits/master/std/experimental/logger


In the past Andrei remarked that he didn't want to move it from 
stdx until RCStr was in Phobos. That was a couple of years ago, 
so his opinion might have change by seeing the slow progress on 
the DIP1000 front.

Re: Shared and race conditions

[Wanderer via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 16:33:50 UTC, Steven 
Schveighoffer wrote:

On 11/29/17 11:13 AM, Wanderer wrote:

[...]


[snip]


[...]


Using the compiler switch -vcg-ast, I see no synchronization of 
these methods.


[...]


That's what I assume, I was just lucky not to see a race.
Thanks for `-vcg-ast` switch! Really helpful, and it answered my 
questions as no syncronization code was added.

Re: Attributes on Enum Members: Call for use cases.

[Timon Gehr via Digitalmars-d]

On 29.11.2017 17:21, Andrei Alexandrescu wrote:

On 11/29/2017 07:53 AM, Seb wrote:

UDAs for function arguments would be really awesome to have.


They should be part of the same DIP. -- Andrei


More generally, any declaration should ideally support UDAs.

One issue with UDAs on function arguments is that function types will 
then have embedded UDAs, so the DIP should specify how that works.

Re: Shared and race conditions

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/29/17 11:13 AM, Wanderer wrote:

I'm trying to simulate a race condition in D with the following code:


[snip]

But all I get is correct IDs without any sign of a race (i.e. duplicate 
ids).

Does compiler add synchronization for `shared` data?


Using the compiler switch -vcg-ast, I see no synchronization of these 
methods.


Races are by definition unpredictable. What has to happen in your case 
is one of 2 things:


1. The thread context switches out after the next() call, but before the 
assignment. This is very very unlikely given the small number of 
instructions the thread executes (the OS isn't about to context switch 
out a thread it just switched into execution mode).
2. Two threads running on separate cores both assign at the exact same 
time, and they race on the data, one overwriting the other in memory.


Note that executing 12 threads in concurrency isn't going to be a very 
stressful case for this race. Yes, it's probably more than the cores on 
your machine, but it's also a very small number of threads.


Note also that even when there is a possibility of a race, it may be a 
long time before you see any errant behavior. I'd try more threads, and 
run the whole test in a loop. At the end of each loop iteration (after 
all the threads are completed), verify that the number has incremented 
by the correct amount. Stop only after it sees a race has happened.


You may run for minutes until you see a race. You may never see one. 
That's the nature of the thing :)


-Steve

Re: Shared and race conditions

[Wanderer via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 16:19:05 UTC, Michael wrote:

On Wednesday, 29 November 2017 at 16:13:13 UTC, Wanderer wrote:

[...]


I unfortunately cannot answer your question but I am noticing 
that running the code with DMD gives you an unordered sequence 
of IDs, but running with DMD-nightly gives you a sequence in 
the correct order. I wonder what has changed to do with threads 
that causes this difference between compiler versions.


The "unordered" output is completely fine, as I assume runtime 
does not guarantee the order of execution of logical threads 
(order is different between ldc and dmd as well).

Re: Shared and race conditions

[Michael via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 16:19:05 UTC, Michael wrote:

On Wednesday, 29 November 2017 at 16:13:13 UTC, Wanderer wrote:

[...]


I unfortunately cannot answer your question but I am noticing 
that running the code with DMD gives you an unordered sequence 
of IDs, but running with DMD-nightly gives you a sequence in 
the correct order. I wonder what has changed to do with threads 
that causes this difference between compiler versions.


Just to add to this, the page here:
https://tour.dlang.org/tour/en/multithreading/synchronization-sharing
does suggest that the compiler will automatically create critical 
sections when it can i.e. wrapping a section in


synchronized {
importStuff();
}

Re: Attributes on Enum Members: Call for use cases.

[Andrei Alexandrescu via Digitalmars-d]

On 11/29/2017 07:53 AM, Seb wrote:

UDAs for function arguments would be really awesome to have.


They should be part of the same DIP. -- Andrei

Re: Attributes on Enum Members: Call for use cases.

[Jacob Carlborg via Digitalmars-d]

On 2017-11-29 13:53, Seb wrote:

UDAs for function arguments would be really awesome to have. Just 
imagine how nice the Vibe.d web routes would look like:


auto postUser(@body User user, @errors Errors errors)

Instead of:
@body("user")
@errorDisplay
auto postUsers(User _user, string  _error)



Or:

@path("/users/:id")
auto getUser(@urlParam string id, @queryParam int page, @auth User user)

Instead of:

@path("/users/:id")
@queryParam("page")
@before!authenticate("user")
auto getUsers(string _id, int page, User user)


(This is pseudo-syntax as I write this from my phone).


Yeah, that would be nice. I had another use case in mind as well, for 
DStep. Clang supports nullability attributes [1] which could be 
translated to UDAs. They would do anything but would be more for 
documentation purpose. I guess external tools could be built to actually 
do something useful with the attributes. Example:


In C:

int fetch(int * _Nonnull ptr);

In D:

int fetch(@Nonnull int* ptr);


[1] 
https://clang.llvm.org/docs/AttributeReference.html#nullability-attributes


--
/Jacob Carlborg

Re: Shared and race conditions

[Michael via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 16:13:13 UTC, Wanderer wrote:
I'm trying to simulate a race condition in D with the following 
code:


(https://run.dlang.io/is/RfOX0I)

```
import std.stdio;
import core.thread;
import std.concurrency;

shared struct IdGen(T)
{
T id;

this(T start)
{
id = start;
}

T next()
{
id = id.next();
return id;
}
}

struct MyId
{
uint num;

shared MyId next()
{
return MyId(num + 1);
}
}

static void getId(shared IdGen!(MyId)* g)
{
writeln("next: ", g.next());
writeln("next: ", g.next());
}

void main()
{
MyId start = {0};
auto g = IdGen!(MyId)(start);

auto num = 12;
for (auto i = 0; i < num; i++)
{
spawn(, );
}

thread_joinAll();
writeln("Done");
}
```

But all I get is correct IDs without any sign of a race (i.e. 
duplicate ids).

Does compiler add synchronization for `shared` data?


I unfortunately cannot answer your question but I am noticing 
that running the code with DMD gives you an unordered sequence of 
IDs, but running with DMD-nightly gives you a sequence in the 
correct order. I wonder what has changed to do with threads that 
causes this difference between compiler versions.

Shared and race conditions

[Wanderer via Digitalmars-d-learn]

I'm trying to simulate a race condition in D with the following 
code:


(https://run.dlang.io/is/RfOX0I)

```
import std.stdio;
import core.thread;
import std.concurrency;

shared struct IdGen(T)
{
T id;

this(T start)
{
id = start;
}

T next()
{
id = id.next();
return id;
}
}

struct MyId
{
uint num;

shared MyId next()
{
return MyId(num + 1);
}
}

static void getId(shared IdGen!(MyId)* g)
{
writeln("next: ", g.next());
writeln("next: ", g.next());
}

void main()
{
MyId start = {0};
auto g = IdGen!(MyId)(start);

auto num = 12;
for (auto i = 0; i < num; i++)
{
spawn(, );
}

thread_joinAll();
writeln("Done");
}
```

But all I get is correct IDs without any sign of a race (i.e. 
duplicate ids).

Does compiler add synchronization for `shared` data?

Re: Chocolatey Packages for DMD, LDC, and GDC

[Jacob Carlborg via Digitalmars-d]

On 2017-11-28 20:04, Manuel Maier wrote:

I didn't know about that tool yet, but I like the idea! However, when I 
played around with it just now, I ran into the "Cannot find 
dmd-2.0.x.x.bat file" issue [1]. And yes, I misread the installation 
instructions (thought it said "run  install dmd"). Then, once dvm 
was properly installed, I didn't get that message anymore. I tried 
installing dmd 2.076.0 and it apparently succeeded in that, but `dvm use 
2.076.0` didn't appear to do anything... So all in all the application 
seems quite rough around the edges and doensn't _feel_ very reliable.


Please try using cmd instead of PowerShell. BTW, setting a default 
compiler in cmd using "dmd use  -d" will also set it as default 
for PowerShell. But the standard "use" command doesn't seem to work.


Another thing I don't think it does is patching the sc.ini with Visual 
Studio environment variables, like the dmd installer does.


No, it basically only extracts the downloaded archive.

--
/Jacob Carlborg

Re: We're looking for a Software Developer! (D language)

[Paulo Pinto via Digitalmars-d-announce]

On Wednesday, 29 November 2017 at 12:05:06 UTC, Ola Fosheim 
Grostad wrote:

On Wednesday, 29 November 2017 at 10:47:31 UTC, aberba wrote:
to death learning these stuff in lectures. I learnt them 
beyond the syllables years back on my own at a much quicker 
pase.


CS isnt about the languages themselves, that is trivial. 
Basically covered in the first or second semester.


You become experienced and skilled when you're passionate 
about it.


Sure, imperative languages are all mostly the same, and easy to 
learn once you know the basics (C++ being an exception).  
Learning frameworks takes time, but there are too many 
frameworks for anyone to master, and they are quickly outdated.


So the only knowledgebase that isnt getting outdated are the 
models from CS.


Wirth puts it nicely, it is all about algorithms, data structures 
and

learning how to apply them to any language.

[Issue 17955] compiler segfault in DsymbolSemanticVisitor::visit(UnittestDeclaration*)

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/a41e3d26d62d498551abeb0da10c7356731b0fe7
Merge pull request #7277 from WalterBright/fix17955

fix Issue 17955 - compiler segfault in DsymbolSemanticVisitor::visit(…
merged-on-behalf-of: Iain Buclaw 

--

Time to move logger from experimental to std ?

[Basile B. via Digitalmars-d]

Hello, most of the changes made during the current year to the 
std.experimental.logger package are related to the cosmetic 
style. Isn't this a sign showing that the experimentation is 
achieved ?



Facts:
- There only 4 issues for logger - 
https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED=phobos=OP=OP=product=component=alias=short_desc=content=CP=CP=OR_id=218035=substring=substring=substring=substring=substring=matches_format=advanced_desc=logger_desc_type=allwordssubstr=logger=logger=logger=logger=logger=%22logger%22
- The history, mostly style things: 
https://github.com/dlang/phobos/commits/master/std/experimental/logger

[Issue 18019] getopt worng behaviour (ConvException instead of GetOptException)

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Dmitry  ---
Thank you for the explanation. Now I found it in the documentation:

> If the option has a parameter, that must be "stuck" to the option
> without any intervening space or "="

But it is not the reason why the issue was created. Main reason is that
behavoiur is different for "-help" (built-in option) and "-replace" (custom
option).

--

Re: Attributes on Enum Members: Call for use cases.

[Michael V. Franklin via Digitalmars-d]

On Tuesday, 28 November 2017 at 19:38:44 UTC, Meta wrote:

I'd be interested in working on a DIP like this Michael, but I 
also want to expand the scope to allowing UDAs on function 
arguments as well. We should have some solid use cases in mind; 
let's take this to private email.


I'm on IRC almost daily under the alias JinShil.

Feel free to take this DIP and run with it.  I don't know if I 
would be much help anyway as I personally don't have a use case 
for this feature; it just seems like an implementation oversight 
to me.  That's why I asked for others to submit use cases.


That being said, having just finished a recent MVC ASP.Net Core 
project, I realize Seb's web-routes would be an outstanding use 
case; I don't know why it didn't occur to me.  Just further 
evidence I may not be the right person to advocate for this 
feature.


ORM also occurred to me as a potential use case.

Mike

Re: DUB: "Invalid source/import path"

[JamesD via Digitalmars-d-dwt]

On Monday, 27 November 2017 at 07:53:21 UTC, Manuel Maier wrote:

On Monday, 15 May 2017 at 06:24:12 UTC, Ivan Trombley wrote:

Never mind. Figured it out.


It would be nice to know what it was that you figured out. I 
just ran into the same issue building gdub 
(https://github.com/jasc2v8/gdub).


Invalid source/import path: 
C:\Users\mjmai\AppData\Roaming\dub\packages\dwtlib-3.1.1\dwtlib\dwt\src
Invalid source/import path: 
C:\Users\mjmai\AppData\Roaming\dub\packages\dwtlib-3.1.1\dwtlib\dwt\views


Indeed, these paths do not exist. The question is why?


Thank you for your feedback, I updated the readme instructions 
for gdub to help avoid this issue for others.


The pre-requistite is to dub fetch dwtlib and build the static 
libraries first, then run the gdub build.bat.  See the dwtlib 
readme instructions at https://github.com/jasc2v8/dwtlib


The errors above are resolved after building the dwtlib static 
libraries, then cloning gdub and running gdub build.bat.


Note: If you don't delete gdub and start with a fresh clone, then 
be sure to delete the src and src_bak folders before running gdub 
build.bat again.

[Issue 18019] getopt worng behaviour (ConvException instead of GetOptException)

[d-bugmail--- via Digitalmars-d-bugs]

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

Basile B.  changed:

   What|Removed |Added

 CC||b2.t...@gmx.com
   Hardware|x86_64  |All
 OS|Windows |All

--- Comment #1 from Basile B.  ---
(In reply to Dmitry from comment #0)
> [...]
> 1) Why "-help" and "-replace" was recognized as options? They contains more
> than one letter and bundling is disabled (as default).
> 2) At least, the behaviour should be same - "-replace" should throw
> GetOptException.
> 
> If I don't understand something obvious, correct me, please.

with "-replace"  It tries to detect "-rtrue" or "-rfalse", which is the short
option + the boolean value for it. The ConvError is then caused by
"to!bool("eplace")".

I'm not sure if this report is valid but it's still possible to throw a better
exception with "expected true or false following simple option" or something
like that.

Maybe you can change the report title. "Better error message for short option
followed by wrong bool string" + set it as enhancement, assuming you'd
agree that the real problem is that of course.

--

[Issue 18012] [reg 2.077.0] segfault in dmd

[d-bugmail--- via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||c...@dawg.eu
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Nowak  ---


*** This issue has been marked as a duplicate of issue 17955 ***

--

[Issue 17955] compiler segfault in DsymbolSemanticVisitor::visit(UnittestDeclaration*)

[d-bugmail--- via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||paolo.inverni...@gmail.com

--- Comment #3 from Martin Nowak  ---
*** Issue 18012 has been marked as a duplicate of this issue. ***

--

Re: Attributes on Enum Members: Call for use cases.

[Seb via Digitalmars-d]

On Tuesday, 28 November 2017 at 19:38:44 UTC, Meta wrote:
On Tuesday, 28 November 2017 at 02:20:15 UTC, Michael V. 
Franklin wrote:
On Sunday, 19 November 2017 at 13:35:13 UTC, Michael V. 
Franklin wrote:



What's the official word?  Does it require a DIP?


For those who might want to know, Walter has informed me that 
this change will require a DIP.  I already  have two DIPs in 
the queue right now, so I wouldn't mind if someone else wrote 
it.


But, absent any volunteers, I would welcome all of you to 
reply to this thread with some use cases where you might find 
UDAs or other attributes useful on enum members.  Deprecation 
and serialization have already been mentioned, but it'd be 
impossible for me to imagine all the different ways users 
might find this feature useful.


Thanks,
Mike


I'd be interested in working on a DIP like this Michael, but I 
also want to expand the scope to allowing UDAs on function 
arguments as well. We should have some solid use cases in mind; 
let's take this to private email.


UDAs for function arguments would be really awesome to have. Just 
imagine how nice the Vibe.d web routes would look like:


auto postUser(@body User user, @errors Errors errors)

Instead of:
@body("user")
@errorDisplay
auto postUsers(User _user, string  _error)



Or:

@path("/users/:id")
auto getUser(@urlParam string id, @queryParam int page, @auth 
User user)


Instead of:

@path("/users/:id")
@queryParam("page")
@before!authenticate("user")
auto getUsers(string _id, int page, User user)


(This is pseudo-syntax as I write this from my phone).

Re: We're looking for a Software Developer! (D language)

[Ola Fosheim Grostad via Digitalmars-d-announce]

On Wednesday, 29 November 2017 at 10:47:31 UTC, aberba wrote:
to death learning these stuff in lectures. I learnt them beyond 
the syllables years back on my own at a much quicker pase.


CS isnt about the languages themselves, that is trivial. 
Basically covered in the first or second semester.


You become experienced and skilled when you're passionate about 
it.


Sure, imperative languages are all mostly the same, and easy to 
learn once you know the basics (C++ being an exception).  
Learning frameworks takes time, but there are too many frameworks 
for anyone to master, and they are quickly outdated.


So the only knowledgebase that isnt getting outdated are the 
models from CS.

Re: Basic questions about D lang?

[user1234 via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 11:32:51 UTC, Jayam wrote:

In D lang,
[...]
3. Can we make library file and use that in any project like 
'Util class' ?


Of course ! Plenty of them can be found here: 
https://code.dlang.org/?sort=updated=library

Re: Basic questions about D lang?

[crimaniak via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 11:32:51 UTC, Jayam wrote:

In D lang,
1. Is there any feature async/ await like "c#" ? I can't find 
feature like async.
As for me, async/await feature is a half-baked solution. With 
vibe-d you can write asynchronous code without thinking about it 
at all. Details: http://vibed.org/features


2. Is Garbage Collector work default without any code to force 
like in c# or do we need to manually trigger it ?
It starts automatically when you try to allocate memory and there 
is no space in heap. In fact, it leads to architecture 
restriction: destructors must be @nogc. Also, you can run it with 
GC.collect()
3. Can we make library file and use that in any project like 
'Util class' ?

Yes.

Re: We're looking for a Software Developer! (D language)

[Paulo Pinto via Digitalmars-d-announce]

On Wednesday, 29 November 2017 at 10:47:31 UTC, aberba wrote:
On Thursday, 8 January 2015 at 11:10:09 UTC, Johanna Burgos 
wrote:

Your Mission




Your Track Record

Degree in Computer Science, or closely-related



It baffles me that recruitment still works using this as a 
requirement. A CS graduate will never know any of these besides 
basic intro to C, C++, html, css,  databases,  and basic 
hardware-software theory... without self learning and practice.


...


Sure it will, it is a matter of university quality.

During my 5 year degree, we got to learn about C++, Prolog, Caml 
Light and SML, x86 and MIPS Assembly, Pascal, PL/SQL, Java, 
Smalltalk.


Those that took compiler design, also had a look into Algol, 
Concurrent C, Oberon, Modula-3, Eiffel, Lisp.


We had access to DG/UX, Aix, GNU/Linux, Mac System 7 and Windows 
as OSes.


Additionally we got all the layers of OS development, from 
drivers to graphics programming, distributed computing using PWM 
and MPI, web design, architecture, algorithms and data 
structures, calculus, linear algebra among many other concepts.


Each area required projects to be delivered during each semester 
and final examination.


Sure many can self learn some of those themes, but it requires a 
big discipline to keep the rhythm.

Re: Basic questions about D lang?

[rikki cattermole via Digitalmars-d-learn]

On 29/11/2017 11:32 AM, Jayam wrote:

In D lang,
1. Is there any feature async/ await like "c#" ? I can't find feature 
like async.


No. The idea is floating around however.

2. Is Garbage Collector work default without any code to force like in 
c# or do we need to manually trigger it ?


Automatic but if you want to be in control of it you can.


3. Can we make library file and use that in any project like 'Util class' ?


Yes, but you don't need utility classes. They are a code smell 
(free-functions are the solution here).

Basic questions about D lang?

[Jayam via Digitalmars-d-learn]

In D lang,
1. Is there any feature async/ await like "c#" ? I can't find 
feature like async.
2. Is Garbage Collector work default without any code to force 
like in c# or do we need to manually trigger it ?
3. Can we make library file and use that in any project like 
'Util class' ?

Re: Strange error when compiling with dmd, not with ldc

[user1234 via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 10:55:35 UTC, user1234 wrote:

On Wednesday, 29 November 2017 at 06:18:09 UTC, Fra Mecca wrote:

[...]


You must also use a type constructor later, when a 
Configuration is declared:


```
immutable(Configuration) config;
config.toString.writeln; // okay this time
```

What happens is that all the member functions have the 
`immutable` attribute, but the instance you declared was not 
itself `immutable`.


actually this:

```
immutable struct Configuration {
@property string toString(){return "";}
}
```

is like:

```
struct Configuration {
@property string toString() immutable {return "";}
}
```

I would personally prefer the second form. Why ? Because the 
variable members will be set immutable anyway when an instance 
is declared.


And about the DMD vs LDC thing, i thing that the difference can 
be simply explained by the fact that LDC uses a slightly older 
compiler front end version, meaning that after 1 or 2 updates, 
the same error would happen.


Now i don't know which change in particular has been made 
recently in the front-end. Maybe the semantic of the leading 
qualifier when "immutable struct {}" is used but i would bet too 
much on that.

Re: Strange error when compiling with dmd, not with ldc

[user1234 via Digitalmars-d-learn]

On Wednesday, 29 November 2017 at 06:18:09 UTC, Fra Mecca wrote:

I have this struct:

immutable struct Configuration {
string title;
string baseurl;
string url;
string email;
string author;
string parser;
string target;
string urlFormat;
string urlFormatCmd;

short port;

string[] ignore;
string[] extensions;

@property string toString()
{
auto urlF = (urlFormatCmd ? "url_format_cmd: " ~ 
urlFormatCmd : "") ~ "\n";

return
"title: "~ title ~ "\n" ~
"baseurl: "  ~ baseurl ~ "\n" ~
"url: "  ~ url ~ "\n" ~
"email: "~ email ~ "\n" ~
"author: "   ~ author ~ "\n" ~
"parser: "   ~ parser ~ "\n" ~
"target: "   ~ target ~ "\n" ~
"url_format: "   ~ urlFormat ~ "\n" ~
"ignore: "   ~ to!string(ignore)[1 .. $ - 1] ~ "\n" 
~
"extensions: "   ~ to!string(extensions)[1 .. $ - 1] ~ 
"\n" ~

urlF;
}
}

and this function:

void show_config()
{
writef("%s", parse_config(
exists("config.sdl") ? "config.sdl" : 
"").toString);

}


Whenever I compile with ldc2 I get no errors, while with dmd I 
get:


source/configuration.d(105,27): Error: immutable method 
configuration.Configuration.toString is not callable using a 
mutable object



What is the problem?


You must also use a type constructor later, when a Configuration 
is declared:


```
immutable(Configuration) config;
config.toString.writeln; // okay this time
```

What happens is that all the member functions have the 
`immutable` attribute, but the instance you declared was not 
itself `immutable`.


actually this:

```
immutable struct Configuration {
@property string toString(){return "";}
}
```

is like:

```
struct Configuration {
@property string toString() immutable {return "";}
}
```

I would personally prefer the second form. Why ? Because the 
variable members will be set immutable anyway when an instance is 
declared.