date:20171122


On Thursday, 23 November 2017 at 06:32:30 UTC, codephantom wrote:


Here is another demonstation of why you can trust your compiler:



Why you "can't" ... is what i meant to say.

I love not being able to edit posts. It's so convenient.

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


On Wednesday, 22 November 2017 at 00:39:21 UTC, codephantom wrote:
On Wednesday, 22 November 2017 at 00:19:51 UTC, codephantom 
wrote:
Its seems to be, that you prefer to rely on the type system, 
during compilation, for safety. This is very unwise.




To demonstrate my point, using code from a 'safe' language (C#):
(i.e. should this compile?)

// --

using System;

public class Program
{


public static int Main()
{
Foo();
return 0;
}

static void Foo()
{
const object x = null;

//if (x != null)
//{
Console.WriteLine(x.GetHashCode());
//}
}

}

// --



Here is another demonstation of why you can trust your compiler:

using code from a 'safe' language (C#):
(i.e. should this compile?)


// -

using System;
using System.IO;

public class Program
{
public static int Main()
{
Console.WriteLine( divInt(Int32.MinValue,-1) );
return 0;
}

static int divInt (int a, int b)
{
int ret = 0;

//if ( (b != 0) && (!((a == Int32.MinValue) && (b == 
-1))) )

//{
ret = a / b;
//}
//else
//{
//   throw new InvalidOperationException("Sorry.. no can 
do!");

//}

return ret;
}

}


// ---

glfwSetDropCallback undefined symbol

2017-11-22 Thread Nicholas Wilson via Digitalmars-d-learn


DCD and DMD says that the symbol is undefined!

However, I look into derelichtGLFW3. It has this symbol defined!

It looks like a bug for me!

Re: betterC and noboundscheck


On Wednesday, 22 November 2017 at 16:57:10 UTC, Joakim wrote:

On Wednesday, 22 November 2017 at 15:10:40 UTC, Oleg B wrote:

[...]


betterC is a new feature that's still being worked on and still 
has holes in it:


https://github.com/dlang/dmd/pull/7151

I suggest you open an issue for it on bugzilla, as this sounds 
like either a hole or at least something that should be 
documented better:


https://issues.dlang.org


see also https://github.com/ldc-developers/ldc/pull/2426 (also 
WiP).

Re: Passing this to void *

2017-11-22 Thread Nicholas Wilson via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 15:07:08 UTC, Tim Hsu wrote:

I am a C++ game developer and I want to give it a try.

It seems "this" in Dlang is a reference instead of pointer.

How can I pass it as void *?

void foo(void *);

class Pizza {
public:
this() {
Pizza newone = this;
// works but newone is actually not this pizza.
foo();
// this does not work..
foo(this);
}
}

void main() {
Pizza pizza = new Pizza();
// this works...
foo();
}


Note that all the examples and advice in this thread apply to 
_classes_, not to structs.


The 'this' in a class is a pointer, since classes are reference 
types (like the 'this' pointer in C++) so you can cast it to a 
void* directly.


The 'this' in a struct is a value, since structs are value types. 
So if you want the address of the struct from within one of the 
struct's methods you need to use the & operator (then it becomes 
a pointer and you can cast it to a void* .

reduce condition nesting

2017-11-22 Thread Andrey via Digitalmars-d-learn


Hello, is there way to reduce this condition:

if (c1) {
foo();
} else {
if (c2) {
bar();
} else {
if (c3) {
...
}
}
}


for instance in kotlin it can be replace with this:

when {
c1 -> foo(),
c2 -> bar(),
c3 -> ...
else -> someDefault()
}

Re: Looking for a job in USA


On Thursday, 23 November 2017 at 04:13:33 UTC, Indigo wrote:


Wow, no need to get offended


Actually, I was not at all offended.

And we always find it kind of humorous, how people around the 
world view Australia. We don't get offended by it.


In any case, I think you underestimate the U.S.

Yes, many objectionable people are doing many objectional things.

But there are many good people doing many good things too.

I'm confident that in the U.S, as in other freedom loving 
countries, the good people will get the upper hand again soon. 
It's an unfortunate ongoing cycle - part of the evolution of 
humanity I guess.


Go seek out, and connect with good people. They are out there you 
know.


The U.S is the worlds last defense against tyranny and 
chaos..which is right on our doorstep. Don't give up on the U.S. 
Instead go out and make it better.

Re: Looking for a job in USA

2017-11-22 Thread Indigo via Digitalmars-d

On Wednesday, 22 November 2017 at 13:48:34 UTC, codephantom wrote:

On Wednesday, 22 November 2017 at 10:24:52 UTC, Indigo wrote:

I have been told by several that Australia is a good place to
go and I myself have thought about it. It seems that Australia
is probably a rather insulated society in that the rest of the
world could kill itself off and they'd be ok(probably a lot to
do with it it being so physically isolated and somewhat small.
Goods and people can't move as easily between it and the rest
so mentally the people are more independent minded and closer
knitted society). I've heard though that it is expensive to
live there and one it is difficult to stay.

Australia is not small. Who told you that?

https://www.google.com.au/maps/place/Australia

If you want to talk about small, consider the tiny land mass of
Indonesia just to our north - it has the 4th largest populated
country in the world (260+ million). That's more than 10 times
Australia's population, in such a small land mass. Needless to
say, that's something our defense forces are keanly aware of,
and constantly monitoring.

Wow, no need to get offended. I wasn't talking about land mass
but population size. It has about 25M people in a large
landmass... That means that persons/sqmi is pretty low. This
means you don't have a lot of people cooped up close to each
other that do not get along. So we pretty much agree. But you are
talking about land mass when I'm talking about people... and
without the people in the equation it is all relevant. People are
the problem, not land.

We are also close to the worlds busiest shipping lanes, and
goods travel very easily between us and the rest of the world.
We are the 23rd largest export economy in the world. In 2016,
we exported $159B and imported $181B. So we have a negative
trade balance actually, which makes us very vulnerable to
what's going on in the rest of the world. As long as China is
ok, we're ok. As long as U.S is ok, China is ok..and around
around it goes...we all rise together, and we all go down
together.

For the most part, yes, but if the shit hits the fan in the
world, you are much more insulated than most other 1st world
countries. That was my point. No need to try to defend your
position, I am not arguing against it and no need to try to
bolster Australia's image.

Australia is sort of like Texas, about the same about the same
population but 10 times larger. It is also far more insulated
than texas. One must travel by boat or plane to get to australia
but texas can be "invaded" by land in all directions reaching
almost across the planet(from the Chile to Alaska). Since it is
far cheaper and easier to go by land than sea or plane, it means
that the mobility of people flowing in to and out of texas is
much greater than Australia(it's basic vector calculus and
physics).

As far as goods and such, the same logic applies. It is much
cheaper to ship things by land than air or sea. You can't put
goods on a train and ship them to Australia... Trains are 10x
cheaper to use in America because we already have the railways
and it's just more efficient than truck or air. Since most goods
consumed in the US are produced in the US we don't have too look
externally for most common goods.

For example, most 3rd world countries have to import the goods we
take for granted(e.g., cheap electrical parts, books, computers,
luxury items, etc).

If you want a real estimation of just how isolated Australia is,
regardless of what you claim, here is a heat map of the trading
that really goes on in the world(more or less):
http://siteresources.worldbank.org/INTWDRS/Resources/477365-1327525347307/8392086-1327528510568/WDR09_12_Ch06web.pdf

or if you don't wanna believe that:
https://en.wikipedia.org/wiki/Freight_transport

Again, I'm not saying Australia is a hole in the wall.. but it is
relatively isolated from many factors. If, say, a deadly plague
started sweeping across the US and can spread very quickly,
Australia is in a good position to be one of the least effected
places, assuming they can shut down the airports quick enough. It
would be nearly impossible for the US to control. The same
applies to anything like an economic collapse. All this is
precisely because of it's isolation by water. If all continents
were connection then we wouldn't be having this conversation.

You might not think it is much of a thing but in certain
circumstances it could mean the difference between life and
death. In other cases it still is a factor but depends on the
context to know exactly how much.

Since I don't follow Australian news, politics, or culture you
know more about those specifics than I do. I do live in the US so
I know more about it than you. The US is not doing good... that
is an undeniable fact. One can pick and choose their metric to
weasel away from the truth but as a whole the US has some very
deep and serious

Re: Can I count the of enum's fields at compile time?


On Thursday, 23 November 2017 at 01:34:54 UTC, Ali Çehreli wrote:

On 11/22/2017 05:21 PM, Marc wrote:
On Thursday, 23 November 2017 at 01:04:29 UTC, Jonathan M 
Davis wrote:
On Thursday, November 23, 2017 00:58:21 Marc via 
Digitalmars-d-learn wrote:

[...]


import std.traits;

enum countOfA = EnumMembers!A.length;

- Jonathna M Davis


This sounds more readable. I was going to write a "function 
extension" to enum but I think it isn't really needed. Thank 
you too.


As an eponymous template:

enum One { a }
enum Three { a, b, c }

import std.range : EnumMembers;
enum countOf(E) = EnumMembers!E.length;

unittest {
static assert(countOf!One == 1);
static assert(countOf!Three == 3);
}

void main() {
}

Ali


whoa, this is so easy and elegant. I'm falling in love with D. 
Thank you too!

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

On Thursday, 23 November 2017 at 00:15:56 UTC, Ola Fosheim 
Grostad wrote:

By what proof? And what do you mean by mathematics?


A mathematical claim, that cannot be proven or disproven, is 
neither true or false.


What you are left with, is just a possibility.

Thus, it will always remain an open question as to whether the 
conjecture is true, or not.

Re: Can I count the of enum's fields at compile time?

2017-11-22 Thread Ali Çehreli via Digitalmars-d-learn


On 11/22/2017 05:21 PM, Marc wrote:

On Thursday, 23 November 2017 at 01:04:29 UTC, Jonathan M Davis wrote:
On Thursday, November 23, 2017 00:58:21 Marc via Digitalmars-d-learn 
wrote:

for example:

enum A { a = -10, b = -11, c = -12, d = -13, e = -34}

enum int countOfA = coutOfFields(A); // 5 fields


import std.traits;

enum countOfA = EnumMembers!A.length;

- Jonathna M Davis


This sounds more readable. I was going to write a "function extension" 
to enum but I think it isn't really needed. Thank you too.


As an eponymous template:

enum One { a }
enum Three { a, b, c }

import std.range : EnumMembers;
enum countOf(E) = EnumMembers!E.length;

unittest {
static assert(countOf!One == 1);
static assert(countOf!Three == 3);
}

void main() {
}

Ali

Re: Can I count the of enum's fields at compile time?

On Thursday, 23 November 2017 at 01:04:29 UTC, Jonathan M Davis 
wrote:
On Thursday, November 23, 2017 00:58:21 Marc via 
Digitalmars-d-learn wrote:

for example:

enum A { a = -10, b = -11, c = -12, d = -13, e = -34}

enum int countOfA = coutOfFields(A); // 5 fields


import std.traits;

enum countOfA = EnumMembers!A.length;

- Jonathna M Davis


This sounds more readable. I was going to write a "function 
extension" to enum but I think it isn't really needed. Thank you 
too.

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

On Thursday, 23 November 2017 at 00:15:56 UTC, Ola Fosheim 
Grostad wrote:
On Thursday, 23 November 2017 at 00:06:49 UTC, codephantom 
wrote:
true up to a number < n  ... does not address the conjecture 
correctly.


So what? We only need to a proof up to N for regular 
programming, if at all.




That's really the point I was making.

It's the reason you'll never be able to put your complete trust 
in a compiler.


The compiler can only ever know something, about something, up to 
a point.


That's why we have the concept of 'undefined behaviour'.

[Issue 18006] in GDB `ptype` returns `struct` for classes

2017-11-22 Thread d-bugmail--- via Digitalmars-d-bugs

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

Basile B.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Basile B.  ---
report moved to https://sourceware.org/bugzilla/show_bug.cgi?id=22480

closing.

--

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

2017-11-22 Thread Jonathan M Davis via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 18:16:16 UTC, Wyatt wrote:
"Need"?  Perhaps not.  But so far, I haven't seen any arguments 
that refute the utility of mitigating patterns of human error.




Ok. that's a good point. But there is more than one way to 
address human error without having to further regulate human 
behaviour.


How about we change the way we think...for example.

I 'expect' bad people to try to do 'bad stuff' using my code. 
It's the first thing I think about when I start typing.


This perspectives alone, really changes the way I write code. 
It's not perfect, but it's alot better than if I didn't have that 
perspective. And all it required was to think differently. No 
language change, no further regulation.


So yeah, you can change the language.. or you can change the way 
people think about their code. When they think differently, their 
code will change accordingly.


My point about sophisticated IDE's and AI like compilers, is that 
they don't seem to have addressed the real issue - that is, 
changing the way people think about their code. If anything, 
they've introduced so many distractions and so much automation, 
that people are just not thinking about their code anymore. So 
now, language designers are being forced to step in and start 
regulating programmer behaviour. I don't like that approach.


You rarely hear anything about defensive programming these days, 
but it's more important now, than it ever was. I'd make it the 
number one priority for new developers. But you won't even find 
the concept being taught at our universities. They're too busy 
teaching students to program in Python ..hahha...the future is 
looking pretty bleak ;-(


Where are the 'Secure Coding Guidelines for Programming in D' 
(I'm not saying they don't exist. I'm just not aware of them).


What if I did a security audit on DMD or PHOBOS. What would I 
discover?


What if I did a security audit on all the D code at github. What 
would I discover?


Sophisticated IDE's and AI like compilers have not rescued us 
from this inherent flaw in programming. The flaw, is a human 
flaw. A flaw in the way we think.

Re: TickDuration deprecation

2017-11-22 Thread captaindet via Digitalmars-d


On 2017-11-23 12:55, sarn wrote:

+1 to using integer arithmetic for the low-level time APIs.


and nobody is advocating to change this.

it is about being able to use such result (duration) with non-time 
focused libraries/functions (eg. general maths/stats) expecting doubles.


if this is not possible in an obvious/standard way (being to!... in D) 
this is the very moment all potential python-to-D converts will run away 
screaming. putting the solution for this common problem only in the docs 
will not appease them either but rather make them mock D.


i still don't understand how problems could arise from a supported 
one-way conversion -> double. of course, double -> time or duration is 
something different and i tend to agree that this should be left for the 
user to implement.


i for my part could live with just one supported to!double conversion 
resulting in seconds. (i guess i am biased as i prefer to use SI units 
only for all my calculations.)


/det

Re: Error: 'this' is only defined in non-static member functions

On Thursday, November 23, 2017 00:49:33 Mike Parker via Digitalmars-d-learn 
wrote:
> On Wednesday, 22 November 2017 at 22:45:53 UTC, A Guy With a
>
> Question wrote:
> > Out of curiosity, what does static mean in that context? When I
> > think of a static class I think of them in the context of Java
> > or C# where they can't be instantiated and where they are more
> > like namespaces that you can't directly import the contents of.
>
> Actually, they work exactly like Java's static nested classes in
> this context.
>
>
> class OuterClass {
>  ...
>  static class StaticNestedClass {
>  ...
>  }
> }
>
> OuterClass.StaticNestedClass nestedObject =
>   new OuterClass.StaticNestedClass();
>
> https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html

I thought that that was the case, but my Java is so rusty that I wasn't
sure.

- Jonathan M Davis

Re: Can I count the of enum's fields at compile time?

2017-11-22 Thread Jonathan M Davis via Digitalmars-d-learn

On Thursday, November 23, 2017 00:58:21 Marc via Digitalmars-d-learn wrote:
> for example:
>
> enum A { a = -10, b = -11, c = -12, d = -13, e = -34}
>
> enum int countOfA = coutOfFields(A); // 5 fields

import std.traits;

enum countOfA = EnumMembers!A.length;

- Jonathna M Davis

Re: Can I count the of enum's fields at compile time?

2017-11-22 Thread Michael V. Franklin via Digitalmars-d-learn

On Thursday, 23 November 2017 at 01:01:42 UTC, Michael V. 
Franklin wrote:

On Thursday, 23 November 2017 at 00:58:21 UTC, Marc wrote:

for example:

enum A { a = -10, b = -11, c = -12, d = -13, e = -34}

enum int countOfA = coutOfFields(A); // 5 fields


https://dlang.org/spec/traits.html#allMembers

enum A { a = -10, b = -11, c = -12, d = -13, e = -34}

enum int countOfA = __traits(allMembers, A).length; // 5 fields

static assert(countOfA == 5);

Mike


This was fast! Thanks

Re: Can I count the of enum's fields at compile time?


On Thursday, 23 November 2017 at 00:58:21 UTC, Marc wrote:

for example:

enum A { a = -10, b = -11, c = -12, d = -13, e = -34}

enum int countOfA = coutOfFields(A); // 5 fields


https://dlang.org/spec/traits.html#allMembers

enum A { a = -10, b = -11, c = -12, d = -13, e = -34}

enum int countOfA = __traits(allMembers, A).length; // 5 fields

static assert(countOfA == 5);

Mike

Can I count the of enum's fields at compile time?

2017-11-22 Thread Jonathan M Davis via Digitalmars-d-learn


for example:

enum A { a = -10, b = -11, c = -12, d = -13, e = -34}

enum int countOfA = coutOfFields(A); // 5 fields

[Issue 18006] New: in GDB `ptype` returns `struct` for classes

2017-11-22 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 18006
   Summary: in GDB `ptype` returns `struct` for classes
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com
CC: ibuc...@gdcproject.org

---
module runnable;
class A {}

void main()
{
A a;
}
---

`ptype a`


gives

---
type = struct runnable.A {

} *
---

which means that there's not the hint required if we must

`print a`

or 

`print *a`

the later required for a class.

--

Re: Error: 'this' is only defined in non-static member functions

2017-11-22 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 22 November 2017 at 22:45:53 UTC, A Guy With a 
Question wrote:


Out of curiosity, what does static mean in that context? When I 
think of a static class I think of them in the context of Java 
or C# where they can't be instantiated and where they are more 
like namespaces that you can't directly import the contents of.


Actually, they work exactly like Java's static nested classes in 
this context.



class OuterClass {
...
static class StaticNestedClass {
...
}
}

OuterClass.StaticNestedClass nestedObject =
 new OuterClass.StaticNestedClass();

https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html

Re: Error: 'this' is only defined in non-static member functions

On Thursday, November 23, 2017 00:17:46 A Guy With a Question via 
Digitalmars-d-learn wrote:
> > here as non-static, nested class is associated with a specific
> > instance of the class and has access to that class instance via
> > its outer member.
> >
> > - Jonathan M Davis
>
> Hmmm...now you have me very intrigued. What is a use-case where
> you'd want to use a non-static embedded class? Sorry if I'm
> asking too many questions. But there's a lot to dig into with
> this language.

It would make sense with something like the nodes of a linked list if they
needed access to the container for some reason. Pretty much any case where a
an instance of a nested class is going to be associated with a specific
instance of its parent class and needs access to it would be a canditate.
It's not that uncommon to see cases in C++ or Java where you'd pass a
pointer to the "parent" to an instance of a nested class when it's created,
and having outer built-in is kind of like that.

Personally, I've never had a use for it. I don't even use classes much in D,
since I rarely need inheritance. And as I understand it, most D programs
don't use classes very heavily for that very reason. So, I have no idea how
common it is to use nested classes in this manner, but I expect that someone
has found it useful at some point.

I thought that this meaning of static for nested classes came from Java, but
it's been a while since I've done much with Java, so I don't know.

- Jonathan M Davis

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

2017-11-22 Thread Ola Fosheim Grostad via Digitalmars-d


On Thursday, 23 November 2017 at 00:06:49 UTC, codephantom wrote:
true up to a number < n  ... does not address the conjecture 
correctly.


So what? We only need to a proof up to N for regular programming, 
if at all.



hint. It's not a problem that mathmatics can solve.


By what proof? And what do you mean by mathematics?

Re: Error: 'this' is only defined in non-static member functions

2017-11-22 Thread A Guy With a Question via Digitalmars-d-learn

here as non-static, nested class is associated with a specific 
instance of the class and has access to that class instance via 
its outer member.


- Jonathan M Davis


Hmmm...now you have me very intrigued. What is a use-case where 
you'd want to use a non-static embedded class? Sorry if I'm 
asking too many questions. But there's a lot to dig into with 
this language.

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

2017-11-22 Thread Jonathan M Davis via Digitalmars-d-learn

On Wednesday, 22 November 2017 at 22:02:11 UTC, Ola Fosheim 
Grøstad wrote:
On Wednesday, 22 November 2017 at 04:55:39 UTC, codephantom 
wrote:
Consider the Goldbach Conjecture, that every even positive 
integer greater than 2 is the sum of two (not necessarily 
distinct) primes. According to the principle of bivalence, 
this should be either true or false.


«The Goldbach conjecture verification project reports that it 
has computed all primes below 4×10^18»


Which is more than you'll ever need in any regular programming 
context.


Next problem?


Come on. Really?

"It's true as far as we know" != "true"

true up to a number < n  ... does not address the conjecture 
correctly.


Where it the 'proof' that the conjecture is 'true'.

hint. It's not a problem that mathmatics can solve.

Re: TickDuration deprecation

2017-11-22 Thread sarn via Digitalmars-d

On Wednesday, 22 November 2017 at 22:17:05 UTC, Walter Bright 
wrote:

On 11/22/2017 5:45 AM, Steven Schveighoffer wrote:
1. All OS calls with timing requirements use non-floating 
point to represent how long to sleep. After all a CPU uses 
discrete math, and the timing implementation is no different.


Microsoft has numerous COM APIs for time functions. One of them 
I had to deal with used doubles to represent seconds. This had 
to be interfaced with other time functions that used integers. 
The trouble came from round trips - there were cases where 
double=>integer=>double did not produce the same result. Even 
worse,


double=>integer=>double=>integer=>double ...

produced a creeping shift in the value! It took much time to 
come up with a method of preventing such drift, and even that 
was unreliable.


It's fixed point, not floating point, but this famous software 
disaster is a pretty dramatic example: 
http://www-users.math.umn.edu/~arnold/disasters/patriot.html


+1 to using integer arithmetic for the low-level time APIs.

Re: Error: 'this' is only defined in non-static member functions

On Wednesday, November 22, 2017 22:45:53 A Guy With a Question via 
Digitalmars-d-learn wrote:
> On Wednesday, 22 November 2017 at 22:37:46 UTC, Steven
>
> Schveighoffer wrote:
> > On 11/22/17 5:36 PM, Steven Schveighoffer wrote:
> >> This allows access to the outer class's members. So you need
> >> an instance to instantiate.
> >>
> >> I bet it's the same for interfaces.
> >
> > All that being said, the error message is quite lousy.
> >
> > -Steve
>
> Yup that worked. Thanks!
>
> Out of curiosity, what does static mean in that context? When I
> think of a static class I think of them in the context of Java or
> C# where they can't be instantiated and where they are more like
> namespaces that you can't directly import the contents of.

A static, nested class does not have access to the class that it's in. It's
basically a normal class that's namespaced within another class, whereas
non-static, nested class is associated with a specific instance of the class
and has access to that class instance via its outer member.

https://dlang.org/spec/class.html#nested
http://ddili.org/ders/d.en/nested.html

Similarly, if a struct, class, or function is nested within a function, and
it is not marked with static, then it has access to the function that it's
in, whereas if it's marked with static, then it acts more like a normal
struct/class/function and does not have access to the function that it's in
and is just namespaced within that function.

- Jonathan M Davis

Re: Error: 'this' is only defined in non-static member functions

2017-11-22 Thread A Guy With a Question via Digitalmars-d-learn

On Wednesday, 22 November 2017 at 22:45:53 UTC, A Guy With a 
Question wrote:
On Wednesday, 22 November 2017 at 22:37:46 UTC, Steven 
Schveighoffer wrote:

On 11/22/17 5:36 PM, Steven Schveighoffer wrote:
This allows access to the outer class's members. So you need 
an instance to instantiate.


I bet it's the same for interfaces.


All that being said, the error message is quite lousy.

-Steve


Yup that worked. Thanks!

Out of curiosity, what does static mean in that context? When I 
think of a static class I think of them in the context of Java 
or C# where they can't be instantiated and where they are more 
like namespaces that you can't directly import the contents of.


Clearly static has a slightly different meaning in D.

Re: Error: 'this' is only defined in non-static member functions

2017-11-22 Thread A Guy With a Question via Digitalmars-d-learn

On Wednesday, 22 November 2017 at 22:37:46 UTC, Steven 
Schveighoffer wrote:

On 11/22/17 5:36 PM, Steven Schveighoffer wrote:
This allows access to the outer class's members. So you need 
an instance to instantiate.


I bet it's the same for interfaces.


All that being said, the error message is quite lousy.

-Steve


Yup that worked. Thanks!

Out of curiosity, what does static mean in that context? When I 
think of a static class I think of them in the context of Java or 
C# where they can't be instantiated and where they are more like 
namespaces that you can't directly import the contents of.

Re: Error: 'this' is only defined in non-static member functions

2017-11-22 Thread Steven Schveighoffer via Digitalmars-d-learn


On 11/22/17 5:36 PM, Steven Schveighoffer wrote:
This allows access to the outer class's members. So you need an instance 
to instantiate.


I bet it's the same for interfaces.


All that being said, the error message is quite lousy.

-Steve

Re: Error: 'this' is only defined in non-static member functions

2017-11-22 Thread Steven Schveighoffer via Digitalmars-d-learn


On 11/22/17 5:19 PM, A Guy With a Question wrote:
I have an interface where I have a classes embedded in it's scope 
(trying to create something for the classes that implement the interface 
can use for unittesting).


     interface IExample
     {
     // stuff ...
     class Tester
     {

     }
     }

I'm trying to make an instance of it like:

     auto tester = new IExample.Tester();

And I get the above error.


Hm... not sure how this works for inner classes of Interfaces, but if 
it's anything like inner classes of classes, then they have a hidden 
'outer' pointer pointing at the owning instance of the class.


This allows access to the outer class's members. So you need an instance 
to instantiate.


I bet it's the same for interfaces.

What you probably want is a static class, which will remove that connection:

static class Tester
...

-Steve

Re: TickDuration deprecation

2017-11-22 Thread A Guy With a Question via Digitalmars-d-learn


On 11/22/2017 5:45 AM, Steven Schveighoffer wrote:
1. All OS calls with timing requirements use non-floating point to represent how 
long to sleep. After all a CPU uses discrete math, and the timing implementation 
is no different.


Microsoft has numerous COM APIs for time functions. One of them I had to deal 
with used doubles to represent seconds. This had to be interfaced with other 
time functions that used integers. The trouble came from round trips - there 
were cases where double=>integer=>double did not produce the same result. Even 
worse,


double=>integer=>double=>integer=>double ...

produced a creeping shift in the value! It took much time to come up with a 
method of preventing such drift, and even that was unreliable.



5. Responding to Walter's one-liner resistance, if the one liner is trivial to 
get right, then sure, don't include it. It could even be written in-line. But if 
it's easy to get WRONG, or is annoying to have to write, then I think it's worth 
having, even if it's a one-liner.


    In my opinion, type conversion is one of those things that falls into that 
second category. How can I construct the most accurate Duration with a given 
double that is in the form of seconds? You'd have to know the representation of 
Duration as hectonanoseconds in order to get this right. While trivial to write 
once you *know* that, it's not trivial to write if you *don't*. Having a library 
function (even a one-liner) that says "I'll save you from the implementation 
details" is useful.


Another solution is to put the one-liner not in Phobos, but in the documentation 
as an example of how to use it. The user will have to look up the function in 
the documentation anyway.




   Bottom line: one-liner-ness shouldn't be an automatic disqualifier.


As always, use good judgement. You and I differ on where that line is, however. 
I prefer a small interface with a minimal number of orthogonal functions, from 
which I can assemble what I need. An interface with a blizzard of functions all 
doing overlapping things with unknown tradeoffs is cognitive overload.


The documentation of such an interface should, of course, provide examples of 
how to assemble those minimal functions into commonly needed solutions.


---

As an aside, Andrei has worked very hard trying to figure out how to break down 
the memory allocator into the smallest collection of orthogonal parts that can 
then be assembled *by the user* into whatever he needs. It is not obvious, and 
amazingly nobody has done it before.


https://dlang.org/phobos/std_experimental_allocator.html

He did the same thing with the checked int package, which blows away every other 
checked integer solution I've seen. I believe it's the future of How To Do 
Interfaces Right :-)


https://dlang.org/phobos/std_experimental_checkedint.html

The documentation for both is a bit intimidating, though. There should be a more 
tutorial oriented overview.

Re: D client for ROS

2017-11-22 Thread thinwybk via Digitalmars-d


On Wednesday, 22 November 2017 at 19:02:17 UTC, thinwybk wrote:

On Saturday, 29 July 2017 at 10:21:32 UTC, Johan Engelen wrote:

Hi all,
  Are there any robot folks out here that are working with ROS 
and would be able to work on creating a D client library for 
it?


ROS is used a lot at our university and in robot research in 
general, and most people use the C++ client (the main one, 
next to Python). In arguing for teaching D at our university, 
it would help a lot if students could use D with ROS.


Cheers,
  Johan

(fyi: I'm an assistent prof Robotics and Mechatronics and LDC 
developer)


Hi Johan,

a bit late... yes, I am working in robotics and I would be 
interrested in helping out. I know that other people visit ROS 
and D meetups in munich and could be interrested as well.


Cheers,
Florian


Have you considered to post on discourse.ros.org (client 
libraries) https://discourse.ros.org/c/client-libraries as well? 
You would propably get more response there.

Re: GitBook about D on embedded ARM Linux

2017-11-22 Thread thinwybk via Digitalmars-d-announce


On Friday, 1 September 2017 at 09:14:30 UTC, aberba wrote:

On Thursday, 31 August 2017 at 14:43:22 UTC, thinwybk wrote:
There is no single point of entry to find information about 
how to use D on ARM Linux. I created a small project on GitHub 
https://github.com/fkromer/d-on-embedded-linux-arm which shall 
enable absolute beginners (of embedded Linux and D) to get 
started as fast as possible. The project is in sync with a 
GitBook page 
https://fkromer.gitbooks.io/d-on-embedded-linux-arm/content/. 
The BeagleBone Black https://beagleboard.org/black is used as 
exemplary development board (a lot of information and 
tutorials available e.g. here http://exploringbeaglebone.com/, 
board hardware is extensible easily and in a modular manner 
with "capes" https://beagleboard.org/cape 
http://elinux.org/Beagleboard:BeagleBone_Capes).


That's interesting. Might do some DIY robotics in future.


For everyone interested in robotics: 
http://forum.dlang.org/post/kaueagtpddunohmuf...@forum.dlang.org 
(request for help developing a client library in D for the Robot 
Operating System)

Error: 'this' is only defined in non-static member functions

I have an interface where I have a classes embedded in it's scope 
(trying to create something for the classes that implement the 
interface can use for unittesting).


interface IExample
{
// stuff ...
class Tester
{

}
}

I'm trying to make an instance of it like:

auto tester = new IExample.Tester();

And I get the above error.

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

2017-11-22 Thread Ola Fosheim Grøstad via Digitalmars-d


On Wednesday, 22 November 2017 at 04:55:39 UTC, codephantom wrote:
Consider the Goldbach Conjecture, that every even positive 
integer greater than 2 is the sum of two (not necessarily 
distinct) primes. According to the principle of bivalence, this 
should be either true or false.


«The Goldbach conjecture verification project reports that it has 
computed all primes below 4×10^18»


Which is more than you'll ever need in any regular programming 
context.


Next problem?

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

2017-11-22 Thread Ola Fosheim Grøstad via Digitalmars-d


On Wednesday, 22 November 2017 at 17:17:07 UTC, Mark wrote:
On Tuesday, 21 November 2017 at 09:12:25 UTC, Ola Fosheim 
Grostad wrote:

Runtime checks are part of the type system though


I wouldn't say that, particularly if we are talking about a 
statically typed language (which Java is).


Very few imperative programming languages are fully statically 
typed.

Re: TickDuration deprecation


On 11/22/2017 2:45 AM, Walter Bright wrote:

On 11/22/2017 1:41 AM, Timon Gehr wrote:

Why would the conversion function be linked in if I never use it?


Good question. It depends on how the code is written, and how the compiler 
represents it in the object file, and how the linker deals with unreferenced 
parts of object files.



For another example, unreferenced virtual functions never get elided because a 
reference to them does exist - they're in the virtual function pointer table. 
And then, of course, everything that virtual function references is never elided.


Another reason to be careful of "kitchen sink" abstractions.

Re: Precise GC state

2017-11-22 Thread Adam Wilson via Digitalmars-d


On 11/22/17 05:44, Nicholas Wilson wrote:

On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote:

On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:

Hi all !
https://github.com/dlang/druntime/pull/1603


Only the Win32 build fails as

Error: more than 32767 symbols in object file

What's wrong?


Thats a linker(?) limitation for OMF (or whatever is the win32 object
file format).


We really should be using the MSVC linker on Windows for both x86 and x64.

I propose we change the default behavior of -m32 to point to MSVC, keep 
the -m32mscoff, but mark it as deprecated, and add a -m32omf flag to 
retain the current behavior.


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: D client for ROS

2017-11-22 Thread thinwybk via Digitalmars-d


On Saturday, 29 July 2017 at 10:21:32 UTC, Johan Engelen wrote:

Hi all,
  Are there any robot folks out here that are working with ROS 
and would be able to work on creating a D client library for it?


ROS is used a lot at our university and in robot research in 
general, and most people use the C++ client (the main one, next 
to Python). In arguing for teaching D at our university, it 
would help a lot if students could use D with ROS.


Cheers,
  Johan

(fyi: I'm an assistent prof Robotics and Mechatronics and LDC 
developer)


Hi Johan,

a bit late... yes, I am working in robotics and I would be 
interrested in helping out. I know that other people visit ROS 
and D meetups in munich and could be interrested as well.


Cheers,
Florian

Re: TickDuration deprecation

2017-11-22 Thread Jonathan M Davis via Digitalmars-d

On Wednesday, November 22, 2017 12:45:01 Daniel Kozak via Digitalmars-d 
wrote:
> Ok I understand why there is no conversion from Duration to float, but
> would be possible to make Duration.total not a member function? So insted
> of:
>
> static mytotal(string unit)(Duration dur)
> {
> return dur.total!unit;
> }
>
> alias msecs = mytotal!"msecs";
>
> I could just add
> alias msecs = total!"msecs";

How would that help anything? You can clearly create an msecs alias right
now, and you could get the same effect using a free function named msecs
instead of an alias. Also, core.time.msecs is already an alias for
core.time.dur!"msecs", so creating your own symbol called msecs (be it an
alias or a free function) could muck with your use of the one from core.time
(though it's certainly possible to disambiguate between the two or to use
dur!"msecs" directly).

And regardless of this specific situation, in general, turning a member
function into a free function risks breaking code, since instead of it being
a member function that automatically wins out with UFCS, it could suddenly
be in conflict with another function of the same name, meaning that the
calling code would have to then disambiguate between them whereas it didn't
before. So, in general, turning member functions into free functions isn't a
great idea if you're not in control over all of the code involved or
otherwise aren't concerned about the potential fallout.

- Jonathan M Davis

Re: Looking for a job in USA

2017-11-22 Thread user1234 via Digitalmars-d


On Monday, 20 November 2017 at 12:48:10 UTC, Satoshi wrote:

On Monday, 20 November 2017 at 10:38:59 UTC, user1234 wrote:

On Saturday, 18 November 2017 at 08:59:53 UTC, Satoshi wrote:

On Saturday, 18 November 2017 at 01:31:09 UTC, Indigo wrote:
On Wednesday, 15 November 2017 at 17:32:50 UTC, Satoshi 
wrote:

Hi,
as the title says, I'm looking for a job opportunity in the


Salary... In US you get $100,000/year as a senior developer 
or something like that, right?
There it's only like $30,000/year. But the price of stuff 
like cars, grocery and everything what you can buy on amazon, 
e-bay, etc. is the same.


Wait wait wait...the social model is not the same, this 
explains the difference. Typically in UE you have welfare 
states, with what this implies ;)


In these welfare states you are required to pay health 
insurance, pension insurance, social insurance which is 30% of 
your salary. Then, there is a difference between your salary 
what you negotiated and the money what your employer spend on 
your salary. He must pay additional 20% to 30% of your salary. 
Example: I get about 1400e/monthly, my employer pays about 
2600e/monthly on my salary.
If you are sick, it's better to take home office than be paid 
from state.
This system, especially in Slovakia is designed for poor people 
not to fall down.



And still, it's better to have bigger salary, even if you are 
paying higher % as a taxes and stuff.


There you have small cars, small flats, smaller size of food 
for the same % of your salary as in the US. e.g. Dodge RAM cost 
the same price as big house in village 20 minutes from Brno or 
flat in the Brno.


I'm not focusing on material thing or something like that, but 
my dream is to travel through the world, sailing and work 
remotely (which is possible as a programmer) for a few years 
before I hit the age. I don't wanna be the one, who stayed at 
the same place for his entire life. Y'know, I'd like adventures.


I think I'm writing the same code as everyone else in the US, 
so why shouldn't I have the same salary?


You know i understand your POV but as we dont really know each 
other here i will tell you something: better dying than giving 
one percent of my workforce to the assholes you wanna work with.

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

2017-11-22 Thread Wyatt via Digitalmars-d


On Wednesday, 22 November 2017 at 14:51:02 UTC, codephantom wrote:


The core language of D does NOT need what C# is proposing - 
that is my view.


"Need"?  Perhaps not.  But so far, I haven't seen any arguments 
that refute the utility of mitigating patterns of human error.


If, over time, a large number of D programmers have the same 
laissez-faire approach towards checking for null, as C# 
programmers, then maybe they'll start demanding the same thing 
- but even then, I'll argue the same points I've argued thus 
far.


Null references have been a problem in every language that has 
them.  Just because D is much nicer than its predecessors (and 
contemporaries, IMO) doesn't mean the "bad old days" (still in 
progress) of C and C++ didn't happen or that we cannot or should 
not learn from the experience.  Tony Hoare doesn't call null his 
sin and "billion dollar mistake" as just a fit of pique.  In 
other words, "Well don't do that, silly human!" ends up being an 
appeal to tradition.


Perhaps that's why I've never considered nulls to be an issue. 
I take proactive steps to protect my code, before the compiler 
ever sees it. And actually, I cannot recall any null related 
error in any code I've deployed. It's just never been an issue.


Oh, that explains it.  He's a _robot_! ;)

(The IDE thing is entirely irrelevant to this discussion; why did 
you bring that up?)


And that's another reason why this topic interests me - why is 
it such an issue in the C# community? From Mads blog about it, 
it seems to be because they're just not doing null checks. And 
so the language designers are being forced to step in. If 
that's not the reason, then I've misunderstood, and await the 
correct explanation.


Again, it's never _not_ been a problem.  That C# is nearly old 
enough to vote in general elections but they're only just now 
finally doing this should be telling. (And I fully expect this 
conversation has been going for at least half of that time.)  
It's probably galvanised by the recent proliferation of languages 
that hold safety to a higher standard and the community realising 
that the language can and _should_ share the burden of mitigating 
patterns of human error.


-Wyatt

Re: ESR on post-C landscape

2017-11-22 Thread Kagamin via Digitalmars-d-learn

Also 
http://ithare.com/chapter-vb-modular-architecture-client-side-programming-languages-for-games-including-resilience-to-reverse-engineering-and-portability/ scroll to the part about language choice.

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

2017-11-22 Thread Mark via Digitalmars-d

On Tuesday, 21 November 2017 at 09:12:25 UTC, Ola Fosheim Grostad 
wrote:

Runtime checks are part of the type system though


I wouldn't say that, particularly if we are talking about a 
statically typed language (which Java is).

Re: betterC and noboundscheck

2017-11-22 Thread Joakim via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 15:10:40 UTC, Oleg B wrote:

Hello. I try compile simple example:

import core.stdc.stdio;
import std.algorithm : min;

extern (C) void main()
{
char[256] buf;
buf[] = '\0';

auto str = "hello world";
auto ln = min(buf.length, str.length);
buf[0..ln] = str[0..ln];
printf("%s\n", buf.ptr);
}

rdmd -betterC bettercarray2.d

and get error:

/tmp/.rdmd-1000/rdmd-bettercarray2.d-435C14EC3DAF09FFABF8ED6919B624C1/objs/bettercarray2.o:
 In function `main':
bettercarray2.d:(.text.main[main]+0xbc): undefined reference to 
`_d_arraycopy'

collect2: error: ld returned 1 exit status
Error: linker exited with status 1

If I understand correctly _d_arraycopy is part of druntime and 
it check bounds of array access.


If I add -noboundscheck flag all works fine.

dmd version is 2.076.1

Why -betterC flag not 'include' -noboundscheck flag?
It's bug or in some cases it's useful?


betterC is a new feature that's still being worked on and still 
has holes in it:


https://github.com/dlang/dmd/pull/7151

I suggest you open an issue for it on bugzilla, as this sounds 
like either a hole or at least something that should be 
documented better:


https://issues.dlang.org

Re: interfacing c++

2017-11-22 Thread drug via Digitalmars-d-learn


22.11.2017 19:06, Markus пишет:

another indicator (as documented) that GC destructor won't work
// extern(C++) classes don't have a classinfo pointer in their vtable so 
the GC can't finalize them
https://github.com/dlang/druntime/blob/3d8d4a45c01832fb657c16a656b6e1566d77fb21/src/rt/lifetime.d#L90 


annoying :(

Markus
I've made a guess that more c++ support were added in the last frontend 
version, well I was wrong

[Issue 18005] AA leak

2017-11-22 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #3 from Steven Schveighoffer  ---
There's nothing different on Windows vs. Linux with regards to the AA
implementation. Both are abstracted against the GC.

So if this is 64-bit windows, the only attribute I can think of to associate
with this behavior is the numbers the OS assigns to stacks/heaps happen to
coincide with the pointers that are there.

(In reply to Temtaime from comment #2)
> Also there's NO_SCAN attribute so there should not be any.

Doesn't matter. The stack is not NO_SCAN, and the AA bucket elements are not
NO_SCAN. What you are doing is making large targets (13MB targets) that these
false pointers may  hook onto.

The nature of false pointers is that in certain situations, they happen, and
changing seemingly random things can affect it. Not sure if we will get to the
bottom of this, or even solve it.

--

[Issue 18002] assert subverts the type system with the messages that it accepts

2017-11-22 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #4 from hst...@quickfur.ath.cx ---
.idup may not be usable if the assert is triggered by an out-of-memory
condition.

--

Re: interfacing c++

2017-11-22 Thread Markus via Digitalmars-d-learn


another indicator (as documented) that GC destructor won't work
// extern(C++) classes don't have a classinfo pointer in their 
vtable so the GC can't finalize them

https://github.com/dlang/druntime/blob/3d8d4a45c01832fb657c16a656b6e1566d77fb21/src/rt/lifetime.d#L90
annoying :(

Markus

[Issue 18005] AA leak

2017-11-22 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #2 from Temtaime  ---
Yes.
Also there's NO_SCAN attribute so there should not be any.

--

Re: interfacing c++

2017-11-22 Thread Markus via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 08:43:54 UTC, drug wrote:

22.11.2017 02:12, Markus пишет:
What about dtor - you allocate class using D GC but try to 
destroy it manually - namely this I guess gives you an error in 
rt_finalize2 because it tries to destroy object that has been 
destroyed.
hmm... I'm not sure. I compiled dmd and it's druntime in debug 
and I'm stepping through it. Seems there has to be a "ClassInfo" 
filled with data. In my case it's filled with garbage. So the 
call ClassInfo.destructor fails, because destructor is an invalid 
pointer. The GC.collect works, but doesn't call the destructor.

https://github.com/dlang/druntime/blob/3d8d4a45c01832fb657c16a656b6e1566d77fb21/src/rt/lifetime.d#L1391
I know constructors and destructors are not supported. And I get 
that point for move/copy... constructors. But I don't get it for 
simple construction and destruction.


Markus

Re: dmd/ldc failed with exit code -11

2017-11-22 Thread Petar via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 15:33:46 UTC, Anonymouse wrote:

On Tuesday, 21 November 2017 at 19:22:47 UTC, Anonymouse wrote:
Compiling a debug dmd and running the build command in gdb, it 
seems to be a stack overflow at ddmd/dtemplate.d:6241, 
TemplateInstance::needsCodegen().


After a lot of trial and error I managed to find /a/ line which 
lets it compile under -b plain and release.


void colour(Sink, Codes...)(auto ref Sink sink, const Codes 
codes)

{
// Sink is a LockingTextWriter or an Appender!string
// Codes is a tuple of named enum members

foreach (const code; codes)
{
import std.conv : to;

if (++numCodes > 1) sink.put(';');

sink.put((cast(size_t)code).to!string);  // <--
}

Change size_t to uint and it compiles, keep it size_t and the 
compiler segfaults. Tested on two machines, both running 
up-to-date Arch linux, both with dmd and ldc.


The bug is too ephemeral to reduce well, if a thing like order 
of arguments matters.


If this is an emergent property of the rest of the program, and 
the size_t merely fells the house of cards, is it even worth 
reporting when I can't reduce it?


You did a good investigation and I still think it's important to 
report it.


I managed to find a few other cases where people were having 
issues with needsCodegen:


https://github.com/ldc-developers/ldc/issues/2168#issuecomment-312709632
https://github.com/ldc-developers/ldc/issues/2336
https://github.com/ldc-developers/ldc/issues/2022#issuecomment-288481397
https://github.com/ldc-developers/ldc/issues/1297#issuecomment-184770787

So there's enough evidence that there's a bug somewhere around 
that part of the compiler and we should gather good test cases to 
narrow down the problem.

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:34:53 UTC, Adam D. Ruppe 
wrote:
No, in both cases, if you do as I say, you will be passing the 
same address.


I was referring to his version of the main function that used &. 
But yes, if you do a cast instead it works just as you say.

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:36:22 UTC, Adam D. Ruppe 
wrote:

On Wednesday, 22 November 2017 at 15:31:36 UTC, Tim Hsu wrote:
It seems in D, reference has its own address, am I right? 
unlike c++


The local variable does have its own address. Do not take its 
address - avoid  or 


Just cast the ref itself.


In D, a class this or Object variable is already like a C++ 
Foo*. If you & that, you get a Foo** - not what you want in 
most cases.


Thanks after doing some experiment I guess I finally understand
class App {
@property void *ptr() {
return cast(void *)(this);
}
}
void printaddr(void *ptr)
{
  writeln(ptr);
}
void main()
{
Pizza pza = new Pizza("XD");
Pizza pza2 = pza;
printaddr(pza.ptr);
printaddr(pza2.ptr);
printaddr();
printaddr();
}

Result:
A32000
A32000
19FDB0
19FDB4


Conclusion:
pza and pza2 is two different reference variable refer to same 
new-ed object.

Re: Passing this to void *


On Wednesday, 22 November 2017 at 15:31:36 UTC, Tim Hsu wrote:
It seems in D, reference has its own address, am I right? 
unlike c++


In case of classes, yes. But I think function parameter 
references do not (or rather, of course they have since they 
exist in memory but it's hidden). Not sure though.

Re: Passing this to void *

2017-11-22 Thread Adam D. Ruppe via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 15:23:58 UTC, Tim Hsu wrote:

   m_window = glfwCreateWindow();
   glfwSetWindowUserPointer(m_window, cast(void *)());


That that & out of there!

glfwSetWindowUserPointer(m_window, cast(void *)(this));

without the &, you are fine.


Then, on the other side, you cast back. Again, do NOT dereference 
it, just cast it:


App app = cast(App) user_ptr;

Re: Passing this to void *

2017-11-22 Thread Adam D. Ruppe via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 15:31:36 UTC, Tim Hsu wrote:
It seems in D, reference has its own address, am I right? 
unlike c++


The local variable does have its own address. Do not take its 
address - avoid  or 


Just cast the ref itself.


In D, a class this or Object variable is already like a C++ Foo*. 
If you & that, you get a Foo** - not what you want in most cases.

[Issue 18005] AA leak

2017-11-22 Thread d-bugmail--- via Digitalmars-d-bugs

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
Are you using -m64 on windows? 32-bit OSes are well known for having memory
leaks due to false pointers.

--

Re: Passing this to void *

2017-11-22 Thread Adam D. Ruppe via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 15:27:27 UTC, Dukc wrote:
It's worth noting that you will still be passing different 
addresses to foo(void*) because classes are reference types in 
D (structs are not). In the constructor you're passing the 
address of the class object itself, but in the main function 
you're passing the address of the reference.


No, in both cases, if you do as I say, you will be passing the 
same address.


You cast the reference itself. Do NOT use the & operator at any 
point with class objects in D (unless you legit know what you are 
doing). Just plain cast it:


`cast(void*) this` // ok. gets address of class object itself
`Object o; foo(cast(void*) o);` // also ok, does same thing

`cast(void*) ` // NOT OK! DO NOT DO THIS address of a local
`cast(void*) `// NOT OK! DO NOT DO THIS address of a local

Re: dmd/ldc failed with exit code -11

2017-11-22 Thread Anonymouse via Digitalmars-d-learn


On Tuesday, 21 November 2017 at 19:22:47 UTC, Anonymouse wrote:
Compiling a debug dmd and running the build command in gdb, it 
seems to be a stack overflow at ddmd/dtemplate.d:6241, 
TemplateInstance::needsCodegen().


After a lot of trial and error I managed to find /a/ line which 
lets it compile under -b plain and release.


void colour(Sink, Codes...)(auto ref Sink sink, const Codes codes)
{
// Sink is a LockingTextWriter or an Appender!string
// Codes is a tuple of named enum members

foreach (const code; codes)
{
import std.conv : to;

if (++numCodes > 1) sink.put(';');

sink.put((cast(size_t)code).to!string);  // <--
}

Change size_t to uint and it compiles, keep it size_t and the 
compiler segfaults. Tested on two machines, both running 
up-to-date Arch linux, both with dmd and ldc.


The bug is too ephemeral to reduce well, if a thing like order of 
arguments matters.


If this is an emergent property of the rest of the program, and 
the size_t merely fells the house of cards, is it even worth 
reporting when I can't reduce it?

Re: Passing this to void *


On Wednesday, 22 November 2017 at 15:27:27 UTC, Dukc wrote:
On Wednesday, 22 November 2017 at 15:17:33 UTC, Adam D. Ruppe 
wrote:
On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch 
wrote:

 will do.


Even if it were an lvalue, that would be the address of a 
local. You should basically NEVER do that with D classes.


Just `cast(void*) this` if you must pass it to such a function.


It's worth noting that you will still be passing different 
addresses to foo(void*) because classes are reference types in 
D (structs are not). In the constructor you're passing the 
address of the class object itself, but in the main function 
you're passing the address of the reference.


It seems in D, reference has its own address, am I right? unlike 
c++

Re: Passing this to void *

2017-11-22 Thread Stefan Koch via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 15:23:58 UTC, Tim Hsu wrote:


I am afraid what will happen when casting this reference to 
void *




a ref is a ptr.
The cast will produce a ptr which is valid as long as the ref is 
valid.

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:17:33 UTC, Adam D. Ruppe 
wrote:
On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch 
wrote:

 will do.


Even if it were an lvalue, that would be the address of a 
local. You should basically NEVER do that with D classes.


Just `cast(void*) this` if you must pass it to such a function.


It's worth noting that you will still be passing different 
addresses to foo(void*) because classes are reference types in D 
(structs are not). In the constructor you're passing the address 
of the class object itself, but in the main function you're 
passing the address of the reference.

Re: Passing this to void *

On Wednesday, 22 November 2017 at 15:17:33 UTC, Adam D. Ruppe 
wrote:
On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch 
wrote:

 will do.


Even if it were an lvalue, that would be the address of a 
local. You should basically NEVER do that with D classes.


Just `cast(void*) this` if you must pass it to such a function.


I am afraid what will happen when casting this reference to void *

glfwSetWindowUserPointer gives us a chance to provide a pointer 
to userdata. so that in callback function, we can retrieve the 
data and don't have to declare global variable.


class App {
public this() {

   m_window = glfwCreateWindow();
   glfwSetWindowUserPointer(m_window, cast(void *)());
}
}

How do I use this function in Dlang?

sorry for my bad english.

Re: betterC and noboundscheck

2017-11-22 Thread Adam D. Ruppe via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 15:10:40 UTC, Oleg B wrote:

Why -betterC flag not 'include' -noboundscheck flag?


-noboundscheck is extremely harmful. If -betterC implied that, it 
would no longer be a better C, it would just be the same buggy C.


The compiler should perhaps inline the bounds check so it doesn't 
need the druntime function, but it certainly shouldn't skip it.

Re: Passing this to void *

2017-11-22 Thread Adam D. Ruppe via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch wrote:

 will do.


Even if it were an lvalue, that would be the address of a local. 
You should basically NEVER do that with D classes.


Just `cast(void*) this` if you must pass it to such a function.

Re: Passing this to void *


On Wednesday, 22 November 2017 at 15:14:32 UTC, Stefan Koch wrote:

On Wednesday, 22 November 2017 at 15:11:08 UTC, Tim Hsu wrote:

On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch


 will do.


I've tried it in the first place.

...

Error: this is not an lvalue


In that case casting to void* should be fine.


But..The compiler still does not produce the executable...

foo();

app.d(17): Error: this is not an lvalue

Re: Passing this to void *

2017-11-22 Thread Stefan Koch via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 15:11:08 UTC, Tim Hsu wrote:

On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch


 will do.


I've tried it in the first place.

...

Error: this is not an lvalue


In that case casting to void* should be fine.

Re: Passing this to void *


On Wednesday, 22 November 2017 at 15:07:54 UTC, Stefan Koch wrote:

On Wednesday, 22 November 2017 at 15:07:08 UTC, Tim Hsu wrote:

I am a C++ game developer and I want to give it a try.

It seems "this" in Dlang is a reference instead of pointer.

How can I pass it as void *?

void foo(void *);

class Pizza {
public:
this() {
Pizza newone = this;
// works but newone is actually not this pizza.
foo();
// this does not work..
foo(this);
}
}

void main() {
Pizza pizza = new Pizza();
// this works...
foo();
}


 will do.


I've tried it in the first place.

...

Error: this is not an lvalue

betterC and noboundscheck

2017-11-22 Thread Oleg B via Digitalmars-d-learn


Hello. I try compile simple example:

import core.stdc.stdio;
import std.algorithm : min;

extern (C) void main()
{
char[256] buf;
buf[] = '\0';

auto str = "hello world";
auto ln = min(buf.length, str.length);
buf[0..ln] = str[0..ln];
printf("%s\n", buf.ptr);
}

rdmd -betterC bettercarray2.d

and get error:

/tmp/.rdmd-1000/rdmd-bettercarray2.d-435C14EC3DAF09FFABF8ED6919B624C1/objs/bettercarray2.o:
 In function `main':
bettercarray2.d:(.text.main[main]+0xbc): undefined reference to 
`_d_arraycopy'

collect2: error: ld returned 1 exit status
Error: linker exited with status 1

If I understand correctly _d_arraycopy is part of druntime and it 
check bounds of array access.


If I add -noboundscheck flag all works fine.

dmd version is 2.076.1

Why -betterC flag not 'include' -noboundscheck flag?
It's bug or in some cases it's useful?

Re: Passing this to void *

2017-11-22 Thread Stefan Koch via Digitalmars-d-learn


On Wednesday, 22 November 2017 at 15:07:08 UTC, Tim Hsu wrote:

I am a C++ game developer and I want to give it a try.

It seems "this" in Dlang is a reference instead of pointer.

How can I pass it as void *?

void foo(void *);

class Pizza {
public:
this() {
Pizza newone = this;
// works but newone is actually not this pizza.
foo();
// this does not work..
foo(this);
}
}

void main() {
Pizza pizza = new Pizza();
// this works...
foo();
}


 will do.

Passing this to void *


I am a C++ game developer and I want to give it a try.

It seems "this" in Dlang is a reference instead of pointer.

How can I pass it as void *?

void foo(void *);

class Pizza {
public:
this() {
Pizza newone = this;
// works but newone is actually not this pizza.
foo();
// this does not work..
foo(this);
}
}

void main() {
Pizza pizza = new Pizza();
// this works...
foo();
}

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


On Wednesday, 22 November 2017 at 13:21:05 UTC, Timon Gehr wrote:
BTW of course you must realize that you can make the compiler 
brutally obsolete by just quickly writing down the most 
efficient possible correct machine code in a hex editor, so I'm 
not too sure why you participate in a discussion on the forums 
of a compiled language at all.




I've participated in order to counter the proposition put forward 
in the subject of this thread.


The core language of D does NOT need what C# is proposing - that 
is my view.


If, over time, a large number of D programmers have the same 
laissez-faire approach towards checking for null, as C# 
programmers, then maybe they'll start demanding the same thing - 
but even then, I'll argue the same points I've argued thus far.


I also think that relying too much on sophisticated IDE's and AI 
like compilers, really changes the way you think about and write 
code. I don't rely on either. Perhaps that's why I've never 
considered nulls to be an issue. I take proactive steps to 
protect my code, before the compiler ever sees it. And actually, 
I cannot recall any null related error in any code I've deployed. 
It's just never been an issue.


And that's another reason why this topic interests me - why is it 
such an issue in the C# community? From Mads blog about it, it 
seems to be because they're just not doing null checks. And so 
the language designers are being forced to step in. If that's not 
the reason, then I've misunderstood, and await the correct 
explanation.

[Issue 18005] New: AA leak

2017-11-22 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 18005
   Summary: AA leak
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: blocker
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

import
std.stdio,
std.typecons,
std.array,
std.conv,
std.algorithm,
std.range;


void main(string[] args)
{
uint[string] vv;

foreach(a; 20_000.iota.map!(a => a * 50_000))
{
vv[a.to!string] = a;
}

uint cnt;

while(true)
{
import core.memory;

writefln(`%g MB used, %g MB free`, GC.stats.usedSize / 1024f /
1024, GC.stats.freeSize / 1024f / 1024);

new ubyte[13 * 1024 * 1024];

GC.collect;
GC.minimize;

if(cnt++ == 30) break;
}
}


On windows:

0.860535 MB used, 4.13947 MB free
13.8644 MB used, 10.6395 MB free
26.8683 MB used, 17.1395 MB free
39.8723 MB used, 23.6395 MB free
52.8762 MB used, 30.1395 MB free
65.8801 MB used, 36.6395 MB free
78.884 MB used, 45.6356 MB free
91.8879 MB used, 57.6317 MB free
104.892 MB used, 72.6277 MB free
117.896 MB used, 59.6238 MB free
130.9 MB used, 77.6199 MB free
143.904 MB used, 64.616 MB free
156.907 MB used, 85.6121 MB free
169.911 MB used, 72.6082 MB free
182.915 MB used, 96.6043 MB free
195.919 MB used, 83.6004 MB free
208.923 MB used, 110.596 MB free
221.927 MB used, 97.5926 MB free
234.931 MB used, 84.5887 MB free
247.935 MB used, 114.585 MB free
260.939 MB used, 101.581 MB free
273.943 MB used, 88.577 MB free
286.946 MB used, 121.573 MB free
299.95 MB used, 108.569 MB free
312.954 MB used, 95.5652 MB free
325.958 MB used, 131.561 MB free
338.962 MB used, 118.557 MB free
351.966 MB used, 105.554 MB free
364.97 MB used, 144.55 MB free
377.974 MB used, 131.546 MB free
390.978 MB used, 118.542 MB free

And on linux:

1.41583 MB used, 3.58417 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free
14.4197 MB used, 10.0842 MB free

--

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


On Wednesday, 22 November 2017 at 13:21:05 UTC, Timon Gehr wrote:


You do realise, that all of the issues you mention can just be 
handled by coding correctly in the first place.

...


Yes, just like everyone else, I realize that if correct code is 
written, we end up with correct code, but thanks for pointing 
it out.


You're welcome.

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


On Wednesday, 22 November 2017 at 13:21:05 UTC, Timon Gehr wrote:

On 22.11.2017 01:19, codephantom wrote:

No, I ideally want the type system to point out when the code 
is not obviously correct. That does not mean I assume that the 
code is correct when it compiles (given that I'm using a 
language that does not require me to prove absence of all bugs, 
and even if it did I'd at most assume that either the language 
implementation is incorrect or my code is correct, with a 
certain margin of error due to undetected hardware failures).



This is very unwise.
...


Thanks for pointing that out.



You're welcome.

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


On Wednesday, 22 November 2017 at 13:47:19 UTC, Timon Gehr wrote:

On 22.11.2017 05:55, codephantom wrote:
No, the question should be, what can the compiler prove to be 
true/false, correct/incorrect about your code, and what effort 
have you made in your code to assist the compiler to make that 
determination.


If you've made no effort to provide the compiler with the 
context it needs to make a useful determination, then don't 
complain when the compiler gets it wrong. That is my first 
point.


My second point, is that it is already possible to provide 
such context to the compiler, without having to make reference 
types non nullable, and therefore having to introduce a new 
nullable reference type.

...


It's really not.




Your arguments need a little more work.

Re: Looking for a job in USA

2017-11-22 Thread Steven Schveighoffer via Digitalmars-d


On Wednesday, 22 November 2017 at 10:24:52 UTC, Indigo wrote:


I have been told by several that Australia is a good place to 
go and I myself have thought about it. It seems that Australia 
is probably a rather insulated society in that the rest of the 
world could kill itself off and they'd be ok(probably a lot to 
do with it it being so physically isolated and somewhat small. 
Goods and people can't move as easily between it and the rest 
so mentally the people are more independent minded and closer 
knitted society). I've heard though that it is expensive to 
live there and one it is difficult to stay.


Australia is not small. Who told you that?

https://www.google.com.au/maps/place/Australia

If you want to talk about small, consider the tiny land mass of 
Indonesia just to our north - it has the 4th largest populated 
country in the world (260+ million). That's more than 10 times 
Australia's population, in such a small land mass. Needless to 
say, that's something our defense forces are keanly aware of, and 
constantly monitoring.


We are also close to the worlds busiest shipping lanes, and goods 
travel very easily between us and the rest of the world. We are 
the 23rd largest export economy in the world. In 2016, we 
exported $159B and imported $181B. So we have a negative trade 
balance actually, which makes us very vulnerable to what's going 
on in the rest of the world. As long as China is ok, we're ok. As 
long as U.S is ok, China is ok..and around around it goes...we 
all rise together, and we all go down together.


https://atlas.media.mit.edu/en/profile/country/aus/

I wouldn't say we are a close knitted society. We are a country 
built on immigration, and it's very diverse here. But we do share 
(we'll most of us anyway) certain values that help bind us 
together - which is not easy when your population is so diverse, 
or when you have increasing numbers of people coming in, with the 
completely opposite values. This is our biggest threat I think 
(i.e. internal stability, not external threats). External threats 
are easily deterred when you have friends like the U.S.


But we are very independent minded, that much you got correct ;-)

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

2017-11-22 Thread Timon Gehr via Digitalmars-d


On 22.11.2017 05:55, codephantom wrote:

... >> The question isn't whether we should use the type system to prevent
bugs. The question is which set of problems really make sense to 
prevent with the type system.




No, the question should be, what can the compiler prove to be 
true/false, correct/incorrect about your code, and what effort have you 
made in your code to assist the compiler to make that determination.


If you've made no effort to provide the compiler with the context it 
needs to make a useful determination, then don't complain when the 
compiler gets it wrong. That is my first point.


My second point, is that it is already possible to provide such context 
to the compiler, without having to make reference types non nullable, 
and therefore having to introduce a new nullable reference type.

...


It's really not.

Which make more sense? Knowing that a reference type could potentially 
be null, and therefore check for null,


You are saying this as if there was always a reasonable thing to do if 
the reference is in fact null. This is just not the case. I.e. this 
option sometimes makes no sense. Also, if checking for null is always 
required, why wouldn't the compiler complain if it is missing?


or dealing with all the flow on 
conquences of making a reference type non nullable by default?


Even with such a change, the Goldbach Conjecture still cannot be resolved.



If the correctness of a program depends on the Goldbach Conjecture, 
that's still something one might want to know about. We could then just 
add the correctness of the Goldbach conjecture as an assumption, and 
then verify that under the given assumption, the program is actually 
correct. Once the Goldbach conjecture gets resolved, we can get rid of 
the assumption.

Re: TickDuration deprecation

On 11/18/17 9:03 AM, Timon Gehr wrote:

(Jonathan M Davis from comment #4)
 > TickDuration will soon be deprecated, and none of the other time stuff
 > supports floating point. Anyone who wants that functionality can 
calculate

 > the floating point values from the integral values that the types do
 > provide. It's not something that most code should be doing, but the API
 > makes it possible for those who care.

"Not something that most code should be doing"? I have never used 
StopWatch and then /not/ wanted to do something like to!("seconds",double)!

There seems to be no good reason to break my code beyond requiring a 
different import here. What are the perceived shortcomings of the 
to!("seconds", double) interface?

My take on this, as someone who has argued extensively NOT to use double 
for timing calculations (I was responsible for adding the TimeSpan type 
in Tango (the equivalent of Duration) and marginalizing Interval (based 
on double) [1]):

1. All OS calls with timing requirements use non-floating point to 
represent how long to sleep. After all a CPU uses discrete math, and the 
timing implementation is no different.

2. Sometimes it is VERY important to use exact representation for 
everything.

  Example: I want to sleep for 1 microsecond, if you had a function 
that accepts a floating point value, and you pass in 0.000_001, you 
might actually sleep for 0 ticks, which is vastly different.

3. Sometimes it is not as important.

  Example: if you want to sleep for 1.75 seconds, having a function 
that converts the float representation of 1.75 into a Duration is 
useful, and reasonably accurate. It isn't going to ruin your application 
if the sleep passed to the OS is 1.74999 seconds. Your sleep 
probably isn't going to be exactly accurate anyways, as most of use use 
non-real-time OSes.

4. There are many libraries, the most obvious one to me is Apple's core 
library, which use a double for representing time everywhere. So it's 
not without precedent.

5. Responding to Walter's one-liner resistance, if the one liner is 
trivial to get right, then sure, don't include it. It could even be 
written in-line. But if it's easy to get WRONG, or is annoying to have 
to write, then I think it's worth having, even if it's a one-liner.

   In my opinion, type conversion is one of those things that falls 
into that second category. How can I construct the most accurate 
Duration with a given double that is in the form of seconds? You'd have 
to know the representation of Duration as hectonanoseconds in order to 
get this right. While trivial to write once you *know* that, it's not 
trivial to write if you *don't*. Having a library function (even a 
one-liner) that says "I'll save you from the implementation details" is 
useful.

  related: https://github.com/dlang/druntime/pull/1927

  Bottom line: one-liner-ness shouldn't be an automatic disqualifier.

---

After having used Apple's SDK quite a bit, I've changed my opinion 
slightly since my Tango days. It is useful to have a floating point 
representation of time, and can be used to good effect. I would be fine 
with a mechanism to convert to/from double with a Duration in druntime 
(in fact, Tango kept this), but still want to have the representation be 
as accurate as possible when it comes to calling OS functions. All the 
public APIs of druntime/phobos should take/return only Durations, not 
doubles, and let the user convert if they want to use doubles elsewhere.

-Steve

[1] http://dsource.org/projects/tango/ticket/671

Re: Precise GC state

2017-11-22 Thread Nicholas Wilson via Digitalmars-d


On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote:

On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:

Hi all !
https://github.com/dlang/druntime/pull/1603


Only the Win32 build fails as

Error: more than 32767 symbols in object file

What's wrong?


Thats a linker(?) limitation for OMF (or whatever is the win32 
object file format).

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

2017-11-22 Thread Timon Gehr via Digitalmars-d


On 22.11.2017 02:09, codephantom wrote:

On Wednesday, 22 November 2017 at 00:49:02 UTC, Jonathan M Davis wrote:
While I definitely don't think that it's generally very hard to avoid 
bugs with null pointers/references, telling someone to code correctly 
in the first place isn't very useful.


Fair enough...perhaps I'm being too explicit with my argument.

However, my point is, that one should not overly rely on some magical 
compiler for telling you what is 'true'.

...


That is not the role of the compiler here. The task of the compiler in 
this circumstance is to tell you what is obvious, not what is true.



How can a compiler know that G is true if it cannot prove that G is true?
...


Because you proved it to the compiler.

You need to take this into account during your coding. Otherwise the 
runtime system is your last line of defence.




You seem to assume that Rice's theorem applies to compilers, but not 
programmers. Why is that?

Re: Precise GC state

2017-11-22 Thread Nordlöw via Digitalmars-d


On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:

Hi all !
https://github.com/dlang/druntime/pull/1603


Only the Win32 build fails as

Error: more than 32767 symbols in object file

What's wrong?

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

2017-11-22 Thread Timon Gehr via Digitalmars-d


On 22.11.2017 01:19, codephantom wrote:

On Tuesday, 21 November 2017 at 20:02:06 UTC, Timon Gehr wrote:


I'm confident that you would be able to use null safe languages 
properly if that is what had been available for most of your career.




You do realise, that all of the issues you mention can just be handled 
by coding correctly in the first place.

...


Yes, just like everyone else, I realize that if correct code is written, 
we end up with correct code, but thanks for pointing it out.


BTW of course you must realize that you can make the compiler brutally 
obsolete by just quickly writing down the most efficient possible 
correct machine code in a hex editor, so I'm not too sure why you 
participate in a discussion on the forums of a compiled language at all.


If your program calls 'std.math.log' with an argument of '-123.4', then 
that's probably NOT a bug. It's more likely to be incorrect code.


https://en.wikipedia.org/wiki/Software_bug


Why not bounds-check the argument before passing it to the function?
...


Walter said NaN is underused, not me.

If you access a field of an invalid instance of an object, that's 
probably NOT a bug. It's more likely to be incorrect code.


https://en.wikipedia.org/wiki/Software_bug

Before you 
access a field of an object, check that the object is valid.

...


If I know that it is valid, I might not want to check it.
Then, if, let's say, you come along and read my code, I do not need you 
to point out that I didn't check the field access. If you still do, I 
can now either explain to you why it is unnecessary, which will waste my 
time and does not guarantee that you will buy it, or I can write the 
code in a language that requires me to provide the proof up front, such 
that you will not have to bother me. And even if you still doubt that 
the proof is actually correct, it will not be my problem, but instead 
you'll need to take it to the guy who wrote the compiler. This is one of 
the reasons why Walter does not like non-null types. ;o)



Its seems to be,


Spelling mistakes can be avoided by just spelling correctly.

that you prefer to rely on the type system, during 
compilation, for safety.


No, I ideally want the type system to point out when the code is not 
obviously correct. That does not mean I assume that the code is correct 
when it compiles (given that I'm using a language that does not require 
me to prove absence of all bugs, and even if it did I'd at most assume 
that either the language implementation is incorrect or my code is 
correct, with a certain margin of error due to undetected hardware 
failures).



This is very unwise.
...


Thanks for pointing that out.


btw. what was the last compiler you wrote?



Embarrassing questions can be avoided by just coming up with the correct 
answer yourself.

Re: writeln, alias this and dynamic arrays.

2017-11-22 Thread matthewh via Digitalmars-d-learn


Thank you all for the helpful responses.
I will read more about ranges.

[Issue 18002] assert subverts the type system with the messages that it accepts

2017-11-22 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #3 from anonymous4  ---
The message is not necessarily static and immutability is only a requirement of
default druntime implementation of assert failure handler, so it should be
enough for the assert failure handler to idup the string before passing it to
AssertError constructor.

--

Re: Having "in" for arrays


On Wednesday, 22 November 2017 at 10:32:48 UTC, lobo wrote:

On Wednesday, 22 November 2017 at 09:36:43 UTC, Dukc wrote:
On Wednesday, 22 November 2017 at 08:03:50 UTC, Fra Mecca 
wrote:

void main()
{
auto v = ["r", "i", "o"];
assert ("r" in v);
}


Also note that even if it wereimplemented, you search for 'r' 
instead of "r". "r" is a string, but you would want to search 
for a char.


Isn't 'v' an array of strings?  If it were a array of chars, 
then the search would be 'r'.


bye,
lobo


Oops, you're correct. My bad.

Re: Precise GC state

2017-11-22 Thread Adam Wilson via Digitalmars-d


On 11/22/17 02:53, Temtaime wrote:

Hi all !
https://github.com/dlang/druntime/pull/1603

Can someone investigate and bring it to us ?
4 years passed from gsoc 2013 and there's still no gc.
Many apps suffers from false pointers and bringing such a gc will help
those who affected by it.
It seems all the tests are passed except win32 because of optlink failures.
Maybe there's some chance to accelerate this PR ?

Thanks all

+1

--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: TickDuration deprecation

2017-11-22 Thread Daniel Kozak via Digitalmars-d

Ok I understand why there is no conversion from Duration to float, but
would be possible to make Duration.total not a member function? So insted
of:

static mytotal(string unit)(Duration dur)
{
return dur.total!unit;
}

alias msecs = mytotal!"msecs";

I could just add
alias msecs = total!"msecs";

On Wed, Nov 22, 2017 at 11:48 AM, Walter Bright via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On 11/22/2017 1:38 AM, Timon Gehr wrote:
>
>> My claim is not that conversion from time to floating point values
>> associated with a few natural units is "properly part of the time
>> abstraction", just that it should exist. Do you agree with that?
>>
>
> I refer to my reply to Jon Degenhardt which has a substantial answer to
> that.
>

Precise GC state

2017-11-22 Thread Temtaime via Digitalmars-d


Hi all !
https://github.com/dlang/druntime/pull/1603

Can someone investigate and bring it to us ?
4 years passed from gsoc 2013 and there's still no gc.
Many apps suffers from false pointers and bringing such a gc will 
help those who affected by it.
It seems all the tests are passed except win32 because of optlink 
failures.

Maybe there's some chance to accelerate this PR ?

Thanks all

Re: TickDuration deprecation


On 11/22/2017 1:38 AM, Timon Gehr wrote:
My claim is not that conversion from time to floating point values associated 
with a few natural units is "properly part of the time abstraction", just that 
it should exist. Do you agree with that?


I refer to my reply to Jon Degenhardt which has a substantial answer to that.

Re: TickDuration deprecation