Re: TickDuration deprecation

[Jon Degenhardt via Digitalmars-d]

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

There is another, perhaps obsolete, consideration.

Some CPUs do not have floating point units. C, for example, is 
carefully set up so that when you don't need floating point, it 
isn't required to have an FPU. This made C usable on cheap 
processors.


It's sorta like "why is the GC linked in even though I never 
used it?"


Hi Walter - I wonder if there is a miscommunication. My 
understanding is that the question is whether there should be a 
built-in conversion from Duration to float/double in a specific 
unit of measure, like milliseconds. It sounds as if your concern 
is more to ensure that the time package not be required to 
support something other than integral values in its internal 
operations.


Perhaps there is an alternative perspective, but being able to 
convert a Duration to a double in a specific unit of measure 
would not seem to place any burden on the time package to support 
the result of conversion as a first class time object. In this 
view, what happens with the converted value is entirely in the 
hands of the end user, not the time package. If the user decides 
to use the double in a mathematical operation, floating point 
round off error is the responsibility of the user, not the time 
package.


To give a concrete example of why this is conversion is useful - 
I often do performance analysis involving service calls that take 
from single digit milliseconds to hundreds of milliseconds, with 
standard deviations in that ballpark. I might use tens of 
thousands of timing samples and analyze those samples using stats 
and graphing packages. Those packages all use doubles, and it is 
generally convenient to work in units appropriate for the 
measurements being done, milliseconds in the case I described. In 
this case, the last step in generating a timing value is to 
convert to milliseconds as a double and store it somewhere, often 
a log file. These will be read back in by the stats/graphing 
package, where follow-up processing will be done.


In the older version of StopWatch, this last step conversion 
could be done with a call like:


double ms = sw.peek.to!("msecs", double));

In the new version, a call needs to be something like:

double ms = sw.peek.total!("hnsecs").to!double / 1e+04);

The latter form is more error prone and less clear about intent, 
etc. It sounds as the rationale for depreciating the previous 
form of conversion is because the end user may incur floating 
point round-off error by performing mathematical operations on 
the double value. The user can still perform the conversion, but 
must go to greater effort. It sounds as if the other part of the 
rationale is that conversion is likely to be rare. In my 
experience, this is not the case.

Re: TickDuration deprecation

[Walter Bright via Digitalmars-d]

There is another, perhaps obsolete, consideration.

Some CPUs do not have floating point units. C, for example, is carefully set up 
so that when you don't need floating point, it isn't required to have an FPU. 
This made C usable on cheap processors.


It's sorta like "why is the GC linked in even though I never used it?"

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

[codephantom via Digitalmars-d]

On Wednesday, 22 November 2017 at 00:49:02 UTC, Jonathan M Davis 
wrote:
Any time the type system can prevent a bug, it's useful. I 
don't see why that would be a problem or unwise.


That is not unwise.

What is 'unwise' is what I said was unwise..that is, putting your 
trust in the compiler's capacity to always know what the truth 
is. That is unwise.


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.


But where is the proof that this is either true, or false?

There is a fundamental error in assuming that something can only 
be either true or false. Some things require too much effort to 
prove, or may simply be unprovable. How much time should the 
compiler spend trying to prove something?


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.


Which make more sense? Knowing that a reference type could 
potentially be null, and therefore check for null, 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.

[Issue 14034] std.algorithm.mean

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

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

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

   What|Removed |Added

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

--

[Issue 14034] std.algorithm.mean

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

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/b5572e8f31f69078691c9d92b8759a5c21f1c341
Fix issue 14034: Add mean to Phobos

--

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

[codephantom via Digitalmars-d]

On Wednesday, 22 November 2017 at 01:48:55 UTC, Jonathan M Davis 
wrote:
In the case of null, you _can_ prove it if you have 
non-nullable types.


True (well...you can at least 'assert' it anyway).

But if the intention is to 'assist the compiler towards knowing 
the truth/correctness about your statement', then this can be 
easily done without introducing a new nullable reference type -

i.e.
if(object != null)
 use it;

Either way, checks are made.

So I still don't see the point of adding a new nullable reference 
type to a language, unless one is asserting that it is ok to not 
already be checking for null (which seems to be the case for a 
large number of C# programmers - hence the proposal).

[Issue 17997] autotester's d_do_test has strange failures with Win32

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

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

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7350

--

Re: TickDuration deprecation

[Walter Bright via Digitalmars-d]

On 11/21/2017 1:40 PM, Timon Gehr wrote:

Computer clocks have discrete ticks, they are not continuous.
That may be true, but the plotting library may still just expect a list of 
doubles. What's the point of removing the simple conversion function that was 
already available for such use cases? This is a breaking change with zero benefits.


I'm in general opposed to "kitchen sink" abstractions, preferring pluggable 
component abstractions. Floating point has no business being in a type that is 
represented as an integral type. There are no 0.3 clock ticks, the notion does 
not exist.




The behavior maps cleanly onto integral math,

I'm not doing computations on times. I could just use Duration for that.


Time durations are always discrete quanta by the nature of the clock used.



not fuzzy fp math.

There is nothing fuzzy about floating point operations,


Fuzzy as in inexact. Integral time computations are always an exact multiple of 
clock ticks.



but still, yes, for some 
use cases, the tiny rounding error will just not matter.


Whether the rounding error matters or not should not be decided by the time 
package, it should be decided by what the user decides to do with the time values.


I.e. it is not properly part of the time abstraction.

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

[Jonathan M Davis via Digitalmars-d]

On Wednesday, November 22, 2017 01:25:48 codephantom via Digitalmars-d 
wrote:
> On Wednesday, 22 November 2017 at 00:49:02 UTC, Jonathan M Davis
>
> 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.
> >
> > - Jonathan M Davis
>
> Those that can be proven.

Sure. If it can't be proven that something is a bug, then the compiler
shouldn't be giving an error in that case (and IMHO, it shouldn't be warning
about it either, since any good programmer doesn't leave warnings in their
project, effectively making warnings errors).

In the case of null, you _can_ prove it if you have non-nullable types. If
it's not legal for a pointer or reference to be null, then the compiler can
guarantee that it's not null. But then you either have the extra
complication of having both nullable and non-nullable pointers/references in
the language, or you force all pointers/references to use something like
std.typecons.Nullable to treat them as nullable or use a construct in the
language which does the same, and that arguably doesn't make a lot of sense
given that underneath the hood, all pointers or references are going to be
nullable, even if you're not allowed to make them null by the type system.
But it would reduce the amount of code where you would have to worry about
potentially having null values.

However, if you don't have non-nullable pointers/references, then you really
can't prove that a pointer or reference is non-null in the general case. You
can prove it under certain circumstances, but ultimately you're going to end
up with an algorithm that only works part of the time. So, best case, it
gives you an error when it definitively knows that you're trying to
dereference null, but that would likely generally be in the cases where you
would very quickly find it yourself as soon as you ran your code. So, while
the compiler check might be useful, I doubt that it would ultimately help
much with preventing bugs in practice.

- Jonathan M Davis

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

[codephantom via Digitalmars-d]

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.


By 'correct code', I mean code that assists the compiler, so that 
it can determine what the truth is (or is meant to be).

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

[codephantom via Digitalmars-d]

On Wednesday, 22 November 2017 at 00:49:02 UTC, Jonathan M Davis 
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.


- Jonathan M Davis



Those that can be proven.

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

[codephantom via Digitalmars-d]

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'.


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


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

[Issue 18004] [Home]std.meta: template DerivedToFront(TList...) bug.

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

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

Basile B.  changed:

   What|Removed |Added

   Severity|enhancement |normal

--

Using PyD

[sivakon via Digitalmars-d-learn]

I can create a python project by creating a PyDobject and `python 
setup.py install` and get the output.


If I want to add an external library in D (usually I do that with 
`dub run --single` command), how do I accomplish that?


In the project below, if I want to use some D libraries, how do I 
build it?

https://github.com/ariovistus/pyd/tree/master/examples/hello

Thanks,
Siva

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

[Jonathan M Davis via Digitalmars-d]

On Wednesday, November 22, 2017 00:19:51 codephantom via Digitalmars-d 
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.

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. Of course, it's better to do that, but people
make mistakes all the time. The real question is whether the problem is big
enough in general or bad enough when it happens to add something to the
language to mitigate it - e.g. no one should be failing to initialize
variables, but it happens sometimes, and default-initializing variables like
D does helps prevent a certain class of bugs. The programmer still needs to
make sure that they deal with initialization correctly, but the problems
that they have when they screw it up are less drastic than they are in C/C++
where variables don't get default-initialized unless they're classes with
default constructors.

Personally, I don't think that null pointer dereferencing is enough of a
problem to start insisting on non-nullable pointers or references
(especially at this point in D's development), and when it happens, it's
very clear what went wrong, so you avoid subtle problems like you'd get with
something like initializing a variable to garbage. So, I don't think that
there's enough value in having non-nullable pointers or references to add
them. In my experience, it just isn't hard to avoid problems with null. But
at the same time, I think that it's perfectly legitimate to be looking to
mitigate a source of bugs, and if you have a pointer or reference that
really never should be null, having that guaranteed by the type system
prevents mistakes, which is useful.

> Its seems to be, that you prefer to rely on the type system,
> during compilation, for safety. This is very unwise.

Any time the type system can prevent a bug, it's useful. I don't see why
that would be a problem or unwise. That's part of why many of us prefer
statically typed languages to dynamically typed languages. The compiler
catches more bugs for us that way. 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.

- Jonathan M Davis

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

[codephantom via Digitalmars-d]

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());
//}
}

}

// --

[Issue 18004] [Home]std.meta: template DerivedToFront(TList...) bug.

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

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

--- Comment #1 from shove  ---
Phobos version: 2.077.0

--

[Issue 18004] New: [Home]std.meta: template DerivedToFront(TList...) bug.

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

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

  Issue ID: 18004
   Summary: [Home]std.meta: template DerivedToFront(TList...) bug.
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: sh...@163.com

file: std.meta
line: 745

template DerivedToFront(TList...)
{
...
}

Incorrect running result, Example code that demonstrates the behavior:

import std.meta;

@safe unittest
{
class A { }
class B : A { }
class C : B { }

alias Types2 = AliasSeq!(A, C, C, B, B, C);
static assert(is(DerivedToFront!(Types2) == AliasSeq!(C, C, C, B, B, A)));
}

--

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

[codephantom via Digitalmars-d]

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.


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. Why not bounds-check the argument before passing 
it to the function?


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. Before 
you access a field of an object, check that the object is valid.


Its seems to be, that you prefer to rely on the type system, 
during compilation, for safety. This is very unwise.


btw. what was the last compiler you wrote?

interfacing c++

[Markus via Digitalmars-d-learn]

hi, im trying to interface a cpp class. I'd like to interface a 
bigger library and I'm trying to figure out the minimum effort.


--- c++ part:
#include 
class some_class {
public:
  static some_class* __ctor();
  some_class();
  ~some_class();
  void some_method();
};
some_class* some_class::__ctor() {
  auto thiz = new some_class();
  std::cout << "hello from __ctor, thiz:" << thiz << std::endl;
  return thiz;
}
some_class::some_class() { std::cout << "some_class constructor, 
this:" << this << std::endl; }
some_class::~some_class() { std::cout << "some_class destructor, 
this:" << this << std::endl; }

void some_class::some_method() {
  std::cout << "some_class some_method, this:" << this << 
std::endl;

}

--- d part:
extern (C++) {
  class some_class {
final this();
final ~this();
final void some_method();
  }
}
void main() {
  some_class someClass = new some_class(); // works, __ctor() 
gets called, and it calls the constructor.

  someClass.some_method; // works
  destroy(someClass); // crashes (SIGSEGV) inside lifetime.d 
rt_finalize2()

}

---
OS: ubuntu 17.10
compiler: DMD64 D Compiler v2.077.0

I could do the instancing/destruction by functions and write a 
custom d class that calls these methods in this()/~this(). But I 
was hoping not needing to write a class in D AND in cpp. and i 
was hoping to save another step/level of instancing.


Any idea how to make the destructor of cpp compatible with 
"~this()"?


Thx in advance
Markus

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

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

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

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

[Timon Gehr via Digitalmars-d]

On 21.11.2017 07:46, Dmitry Olshansky wrote:


The spec describes unsound language, the hole in type-system are plugged 
at VM level by run-time checks.


Also this jawel:

Cat[] cats = new Cat[3];
...
Animals[] animals = cats; // the same array

animals[0] = new Dog();

cats[0].smth(); // ClassCast exception or some such



Actually, the "java.lang.ArrayStoreException" will be thrown already 
when you attempt to add the dog to the cat array. This is by design 
though (and explicitly supported by the JVM). The reason why the 
null-related Java type system hole does not lead to memory corruption is 
that the JVM does not support generics. (It's all translated to explicit 
type casts that are expected to always succeed, but the JVM still checks 
them.)

Re: TickDuration deprecation

[Timon Gehr via Digitalmars-d]

On 21.11.2017 21:52, Walter Bright wrote:

On 11/18/2017 8:17 AM, Jonathan M Davis wrote:

Folks have asked for the ability to create Durations from floating point
values too, and I rejected that for the same reason - using floating 
point
values with time is just begging for bugs, and Walter backed me up on 
that

one.


Yup. It's the same reason one does not do accounting with floating point.
...


The use case here is plotting the time taken by an algorithm depending 
on instance size.



Computer clocks have discrete ticks, they are not continuous.


That may be true, but the plotting library may still just expect a list 
of doubles. What's the point of removing the simple conversion function 
that was already available for such use cases? This is a breaking change 
with zero benefits.



The behavior maps cleanly onto integral math,


I'm not doing computations on times. I could just use Duration for that.


not fuzzy fp math.



There is nothing fuzzy about floating point operations, but still, yes, 
for some use cases, the tiny rounding error will just not matter.

Re: TickDuration deprecation

[Walter Bright via Digitalmars-d]

On 11/18/2017 8:17 AM, Jonathan M Davis wrote:

Folks have asked for the ability to create Durations from floating point
values too, and I rejected that for the same reason - using floating point
values with time is just begging for bugs, and Walter backed me up on that
one.


Yup. It's the same reason one does not do accounting with floating point.

Computer clocks have discrete ticks, they are not continuous. The behavior maps 
cleanly onto integral math, not fuzzy fp math.

Re: SublimeLinter-contrib-dmd: dmd feedback as you type

[Bastiaan Veelo via Digitalmars-d-announce]

On Tuesday, 21 November 2017 at 18:43:29 UTC, drug wrote:

31.10.2017 01:22, Bastiaan Veelo пишет:
SublimeLinter-contrib-dmd [1] is a plug-in for the Sublime 
Text 3 editor [2]. Unlike linters that are based on DScanner, 
it actually invokes dmd on the file that is being edited, as 
you edit.


Thank you for your tool! It works like a charm even in mixins 
and works out of box. I installed it just in case but now I've 
caught myself that I start using it.


Thanks for the thumbs up :-)

[Issue 17127] bad example code for std.concurrency.Generator

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

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

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

https://github.com/dlang/phobos/commit/d2e716b20ed571ac00e184cdb84a0c158c5136c9
Issue 17127 - bad example code for std.concurrency.Generator

https://github.com/dlang/phobos/commit/4e197f22630329bc44203b72712cb43020fd710e
Merge pull request #5870 from wilzbach/std-concurrency-tests-2

Issue 17127 - bad example code for std.concurrency.Generator
merged-on-behalf-of: Jack Stouffer 

--

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

[Timon Gehr via Digitalmars-d]

On 19.11.2017 23:54, Walter Bright wrote:

... > There's also an issue of how to derive a class from a base class.
...


How so?

While we are talking applicability to D: The main issue is to ensure 
that fields of objects are initialized properly before being accessed. D 
already needs to do this, but fails, which means references to immutable 
data are not guaranteed to yield consistent results between dereferences.





What should the default initializer for a type do?

There should be none for non-nullable types.
I suspect you'd wind up needing to create an "empty" object just to 
satisfy that requirement. Such as for arrays of objects, or objects 
with a cyclic graph.
Again, just use a nullable reference if you need null. The C# language 
change makes the type system strictly more expressive. There is 
nothing that cannot be done after the change that was possible before, 
it's just that the language allows to document and verify intent better.


This implies one must know all the use cases of a type before designing it.
...


No. The opposite is the case: you can just change the type once the 
requirements change. Then the type system shows you precisely where you 
need to update your code. In D, such a change is quite hard to make.




Yes, my own code has produced seg faults from erroneously assuming a 
value was not null. But it wouldn't have been better with 
non-nullable types, since the logic error would have been hidden


It was your own design decision to hide the error.


No, it was a bug. Nobody makes design decisions to insert bugs :-) The 
issue is how easy the bug is to have, and how difficult it would be to 
discover it.

...


You added a special invalid instance that does not blow up on 
dereference. That was a conscious design decision. If your point is that 
there can be bugs unrelated to null, well that's unrelated to null.





and may have been much, much harder to recognize and track down.
No, it would have been better because you would have been used to the 
more explicit system from the start and you would have just written 
essentially the same code with a few more compiler checks in those 
cases where they apply, and perhaps you would have suffered a handful 
fewer null dereferences.


I'm just not convinced of that.
...


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.




The point of types is to classify values into categories such that 
types in the same category support the same operations. It is not very 
clean to have a special null value in all those types that does not 
support any of the operations that references are supposed to support. 
Decoupling the two concepts into references an optionality gets rid of 
this issue, cleaning up both concepts.


I do understand that point. But I'm not at all convinced that 
non-nullable types in aggregate results in cleaner, simpler code, for 
reasons already mentioned.

...


I guess that depends on one's definition of clean and simple. Using 
nullable references for passing around references known to be non-null 
is not clean in my book.



I wish there was a null for int types.

AFAIU, C# will now have 'int?'.


Implemented as a pointer to int? That is indeed one way to do it, but 
rather costly.

...


It lowers to Nullable, which is a struct with a boolean flag.




It can also be pretty annoying.


Yes, it can be annoying, so much better to have a number that looks like 
it might be right, but isn't, because 0.0 was used as a default 
initializer when it should have been 1.6. :-)

...


That's not what I was saying.



It really depends on the use case. Also this is in direct 
contradiction with your earlier points. NaNs don't usually blow up.


"blow up" - as I've said many times, I find the visceral aversion to seg 
faults puzzling.


This is a misinterpretation. My language does not carry implicit 
emotional context during technical discussions. Given that you have a 
bug, blowing up is often the ideal outcome. It is even better to not 
have the bug in the first place. That's what explicit null (often) does 
for you.


(Also, I'd posit the reason why you don't understand why segfaults can 
be very painful to some is that you are in the compiler business.)


Why is that worse than belatedly discovering a NaN in 
your output, which you now have to back search it to its source?

...


That is the opposite of the point I was making. You said: "bugs should 
terminate the program" and then "NaNs are underused". If my program 
calls 'std.math.log' with an argument of '-123.4', then that's probably 
a bug, so there seemed to be an inconsistency.


My attitude towards programming bugs is to have them immediately halt 
the program as soon as possible, so:

...


My attitude is that ideally they are catched even sooner, during design 
time or compilation.


You are contrasting bugs that produce incorrect outputs and bugs that 
crash your 

Silicon Valley D Meetup - December 14, 2017 - "Experimenting with Link Time Optimization" by Jon Degenhardt

[Ali Çehreli via Digitalmars-d-announce]

Meetup page: https://www.meetup.com/D-Lang-Silicon-Valley/events/245288287/

LDC[1], the LLVM-based D compiler, has been adding Link Time 
Optimization capabilities over the last several releases. [...]


This talk will look at the results of applying LTO to one set of 
applications, eBay's TSV utilities[2]. [...]


Jon Degenhardt is a member of eBay's Search Science team.
[...] D quickly became his favorite programming language, one he uses 
whenever he can.


Ali

[1] https://github.com/ldc-developers/ldc#ldc--the-llvm-based-d-compiler

[2] https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/

Re: Visual D >> TRACKER : error TRK0004: Failed to locate: "FileTracker32.dll". The system cannot find the file specified.

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

On Tuesday, 21 November 2017 at 04:39:52 UTC, A Guy With a 
Question wrote:
I'm trying to learn D using Visual D in Visual Studio Community 
2015. Both dmd and ldc give me this error when building from 
Visual Studio. Any ideas? I'm able to build C++ projects...


So I figured this one out. I set my dmd directory wrong. I could 
not find where to correct this though in visual d's 
configurations. I probably just kept glossing over it. What I 
ended up doing was uninstalling visual d and reinstalling where I 
noticed it defaulted me to my D folder, but I needed to point it 
at dmd's root folder.


Just in case anyone was wondering what the fix was to this.

Re: DConf 2014 YouTube videos unavailable

[Atila Neves via Digitalmars-d]

On Monday, 20 November 2017 at 17:46:25 UTC, Steven Schveighoffer 
wrote:

On 11/20/17 11:48 AM, Luís Marques wrote:
The DConf 2014 talk pages have links to YouTube, but all of 
the links I tried resulted in an YouTube error, "This video is 
unavailable."


They still exist, but the links are different.

e.g.:

https://www.youtube.com/watch?v=FGgFMZhnXvU

Is different than the link listed here: 
http://dconf.org/2014/talks/chevalier_boisvert.html


https://www.youtube.com/watch?v=cJGNItlMWBM

Not sure if this is youtube's doing or not, but feel free to PR 
dconf.org if you want to fix the links:


https://github.com/dlang/dconf.org

-Steve


My talk is still on archive.org (different link, though), but not 
on youtube. Maybe it was flagged for some weird reason?


Atila

Re: .NET introduces Span, basically D slices

[flamencofantasy via Digitalmars-d]

On Sunday, 19 November 2017 at 14:46:32 UTC, Rumbu wrote:

On Sunday, 19 November 2017 at 02:16:36 UTC, Luís Marques wrote:

https://github.com/dotnet/corefxlab/blob/master/docs/specs/span.md

Seems like D wisdom is creeping in. For instance, the Data 
Pipelines section basically explains why ranges/slices and 
algorithms are nice and relevant: 



Sorry to disappoint, but Span is something else. The .net 
equivalent of D slices is in fact the not so popular 
ArraySegment available in .net since 2008.


Span will allow access to unmanaged and stack memory in the 
same way as using a standard array.


Actually Span is a lot more like D slices in that it can use 
any type of memory.
ArraySegment can only be initialized with an array type and 
thus is very far from being like a D slice.
I use D slices exclusively with non-GC memory or mapped files and 
similarly I can now make use of Span but I was never able to 
employ ArraySegment.

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

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

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

--- Comment #2 from hst...@quickfur.ath.cx ---
See the code I posted in issue #18003.  The compiler should reject any attempt
to pass a slice of a local variable to assert().

--

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

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords||accepts-invalid

--

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

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #1 from hst...@quickfur.ath.cx ---
*** Issue 18003 has been marked as a duplicate of this issue. ***

--

[Issue 18003] assert performs implicit conversion of mutable local static char array to string

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from hst...@quickfur.ath.cx ---


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

--

Re: String copying fails when output from assert

[H. S. Teoh via Digitalmars-d-learn]

On Tue, Nov 21, 2017 at 12:05:21PM -0700, Jonathan M Davis via 
Digitalmars-d-learn wrote:
> On Tuesday, November 21, 2017 18:49:40 David Zhang via Digitalmars-d-learn 
> wrote:
[...]
> >   char[64] chars;
> >   chars[0..str.length] = str;
> >   assert(false, chars[0..str.length]);
[...]
> Well, the assertion is going to throw an AssertError, which takes a
> string for its message. It doesn't copy the contents of the string.
> It's just taking a slice just like whenever you pass a string to any
> other function.  So, it refers to the same memory as what's passed in.
> So, if what it's passed is a string that refers to memory on the
> stack, then when it goes to print the message, it's going to be
> garbage, because the stack was unwound, and the static array is gone.
> 
> Honestly, I'd argue that it's a bug that it allows you provide a
> message as a char[] instead of immutable(char)[]. It seems that the
> compiler is implicitly converting char[] to immutable(char)[] in this
> case, which is very bad. It would matter less if you were giving the
> assertion a char[] that referred to memory on the heap, but it still
> shouldn't be allowed.

Yeah, this is a bug.  I filed an issue:

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


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system 
vulnerabilities cannot touch Linux---is priceless. -- Frustrated system 
administrator.

[Issue 18003] assert performs implicit conversion of mutable local static char array to string

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

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

--- Comment #1 from hst...@quickfur.ath.cx ---
P.S. Marking both functions as @safe and compiling with -dip25 and -dip1000
also fails to catch this leak of a reference to a local variable outside f().

--

[Issue 18003] New: assert performs implicit conversion of mutable local static char array to string

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

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

  Issue ID: 18003
   Summary: assert performs implicit conversion of mutable local
static char array to string
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Code:
--
void f() {
char[6] err = "Argh!";
assert(0, err[0 .. $]);
}
void main() {
f();
}
--

In the assert output, the message is garbled because it's a slice of the local
variable `err`, which has gone out of scope by the time the error message is
displayed.

Expected behaviour: assert() should not allow mutable char[] as second
argument, or the compiler should not allow implicit conversion of a mutable
char[] slice to immutable(char)[].

--

[Issue 17995] template NoDuplicates(TList...) bug.

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

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

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

   What|Removed |Added

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

--

Re: String copying fails when output from assert

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 21, 2017 19:13:36 David Zhang via Digitalmars-d-learn 
wrote:
> On Tuesday, 21 November 2017 at 19:05:21 UTC, Jonathan M Davis
>
> wrote:
> > Well, the assertion is going to throw an AssertError, which
> > takes a string for its message. It doesn't copy the contents of
> > the string. It's just taking a slice just like whenever you
> > pass a string to any other function. So, it refers to the same
> > memory as what's passed in. So, if what it's passed is a string
> > that refers to memory on the stack, then when it goes to print
> > the message, it's going to be garbage, because the stack was
> > unwound, and the static array is gone.
> >
> > Honestly, I'd argue that it's a bug that it allows you provide
> > a message as a char[] instead of immutable(char)[]. It seems
> > that the compiler is implicitly converting char[] to
> > immutable(char)[] in this case, which is very bad. It would
> > matter less if you were giving the assertion a char[] that
> > referred to memory on the heap, but it still shouldn't be
> > allowed.
> >
> > You really should be giving assertions a value that is an
> > actual string that lives on the heap when providing a message,
> > not a char[], and definitely not a char[] that's a slice of a
> > static array.
> >
> > - Jonathan M Davis
>
> Right. So a literal would work, because it's in the .data
> segment, or inlined. Basically, only strings from the heap, or
> that are compiled into the code are valid for assert messages.

Or any kind of exception message.

> What kind of behavior would an assert from stdc have (id,
> betterC)?

I don't know. It calls the C implementation at that point, so it won't throw
an AssertError, but I don't know exactly how it's implemented. It probably
just prints the message and then kills the program, so it'll probably work
even with a slice of a static array, but I don't know for sure. However,
unless the code is specifically versioned to only be betterC, it would be a
really bad idea to rely on that behavior. And if assert ever gets fixed such
that it properly rejects messages that aren't actually strings, passing it a
char[] wouldn't work anymore anyway.

- Jonathan M Davis

[Issue 17995] template NoDuplicates(TList...) bug.

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

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

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

https://github.com/dlang/phobos/commit/a6e9b151fe63ca1098fa75456f925a7b69135572
Fix issue 17995

https://github.com/dlang/phobos/commit/284e5210edca36ad4d279850dd369c503706dd90
Merge pull request #5867 from Biotronic/issue17995

Fix issue 17995
merged-on-behalf-of: Martin Nowak 

--

Re: dmd/ldc failed with exit code -11

[Anonymouse via Digitalmars-d-learn]

On Tuesday, 21 November 2017 at 13:28:44 UTC, Anonymouse wrote:
Looking at the dmd command dub issues and testing them myself I 
notice that if I reorder the arguments it builds.


$ dmd -d -oftest source/arsd/*.d source/kameloso/plugins/*.d 
source/kameloso/*.d
zsh: segmentation fault (core dumped)  dmd -d -ofkek 
source/arsd/*.dd source/kameloso/plugins/*.d 
source/kameloso/*.d


$ dmd -d -oftest source/kameloso/plugins/*.d 
source/kameloso/*.d source/arsd/*.d

$ echo $?
0


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().



Program received signal SIGSEGV, Segmentation fault.
0x557ef1f7 in TemplateInstance::needsCodegen() 
(this=0x7f7feff8>) at ddmd/dtemplate.d:6181

(gdb) bt
[...58165 all the way to 1...]
#58166 0x557ef351 in TemplateInstance::needsCodegen() 
(this=0x7fff4a8f1eb0) at ddmd/dtemplate.d:6241
#58167 0x557ef351 in TemplateInstance::needsCodegen() 
(this=0x7fff4a8f2640) at ddmd/dtemplate.d:6241
#58168 0x557ef351 in TemplateInstance::needsCodegen() 
(this=0x7fff4a8f4480) at ddmd/dtemplate.d:6241
#58169 0x557ef351 in TemplateInstance::needsCodegen() 
(this=0x7fff4a8f4c10) at ddmd/dtemplate.d:6241
#58170 0x557ef642 in TemplateInstance::needsCodegen() 
(this=0x72553280) at ddmd/dtemplate.d:6335
#58171 0x558d7851 in 
toObjFile::ToObjFile::visit(TemplateInstance*) 
(this=0x7fffc128, ti=0x72553280) at ddmd/toobj.d:1126
#58172 0x557f2426 in TemplateInstance::accept(Visitor*) 
(this=0x72553280, v=0x7fffc128) at ddmd/dtemplate.d:7438
#58173 0x558d59c2 in toObjFile(Dsymbol*, bool) 
(ds=0x72553280, multiobj=false) at ddmd/toobj.d:1335
#58174 0x558c6f19 in genObjFile(Module*, bool) 
(m=0x77e95bf0, multiobj=false) at ddmd/glue.d:402
#58175 0x5585f7e8 in ddmd.mars.tryMain(ulong, 
const(char)**) (argv=0x7fffd928, argc=36) at 
ddmd/mars.d:1013

#58176 0x5586003f in D main () at ddmd/mars.d:1115


This part (function final bool needsCodegen(), line 6181):


6233│ // Determine necessity of tinst before tnext.
6234│ if (tinst && tinst.needsCodegen())
6235│ {
6236│ minst = tinst.minst; // cache result
6237│ assert(minst);
6238│ assert(minst.isRoot() || 
minst.rootImports());

6239│ return true;
6240│ }
6241│-->  if (tnext && (tnext.needsCodegen() || 
tnext.minst))

6242│ {
6243│ minst = tnext.minst; // cache result
6244│ assert(minst);
6245│ return minst.isRoot() || 
minst.rootImports(); 6246│ }

Re: String copying fails when output from assert

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 21, 2017 18:59:14 David Zhang via Digitalmars-d-learn 
wrote:
> On Tuesday, 21 November 2017 at 18:56:03 UTC, Adam D. Ruppe wrote:
> > On Tuesday, 21 November 2017 at 18:49:40 UTC, David  Zhang
> >
> > wrote:
> >>assert(false, chars[0..str.length]);
> >>
> >> }
> >>
> >> What am I missing here?
> >
> > You're escaping a reference to a local variable there. chars[]
> > is a pointer to the stack, which is promptly smashed when the
> > assert error starts working up the call chain, so by the time
> > it actually prints, you have undefined behavior.
>
> So I'd have to allocate the buffer on the heap then...
> Is there any way to do this without allocating to the stack?

Why would you need to allocate on the stack to allocate on the heap? If you
have a string to pass assert for its message, then just pass it the string.
If you have a char[], then idup it. If you have a static array on the stack,
then idup it. And if you're iduping in the assert statement, then it should
only idup when the assertion fails.

- Jonathan M Davis

Re: String copying fails when output from assert

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 21, 2017 12:05:21 Jonathan M Davis via Digitalmars-d-
learn wrote:
> On Tuesday, November 21, 2017 18:49:40 David Zhang via Digitalmars-d-learn
> wrote:
> > Hi,
> >
> > I've been trying to copy a string, then output it from an
> > `assert(false)` statement, but the copy seems to be corrupted
> > somehow.
> >
> > void main()
> > {
> >
> >   string str = "some string";
> >
> >  //initializing `chars` with any value doesn't do anything
> >
> >   char[64] chars;
> >   //char[64] chars = '!';
> >
> >   //memcpy doesn't work either, though the output's different
> >   //import core.stdc.string;
> >   //memcpy([0], [0], str.length);
> >
> >   chars[0..str.length] = str;
> >   assert(false, chars[0..str.length]);
> >
> > }
> >
> > What am I missing here?
>
> Well, the assertion is going to throw an AssertError, which takes a string
> for its message. It doesn't copy the contents of the string. It's just
> taking a slice just like whenever you pass a string to any other
> function. So, it refers to the same memory as what's passed in. So, if
> what it's passed is a string that refers to memory on the stack, then
> when it goes to print the message, it's going to be garbage, because the
> stack was unwound, and the static array is gone.
>
> Honestly, I'd argue that it's a bug that it allows you provide a message
> as a char[] instead of immutable(char)[]. It seems that the compiler is
> implicitly converting char[] to immutable(char)[] in this case, which is
> very bad. It would matter less if you were giving the assertion a char[]
> that referred to memory on the heap, but it still shouldn't be allowed.
>
> You really should be giving assertions a value that is an actual string
> that lives on the heap when providing a message, not a char[], and
> definitely not a char[] that's a slice of a static array.

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

- Jonathan M Davis

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

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

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

  Issue ID: 18002
   Summary: assert subverts the type system with the messages that
it accepts
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: issues.dl...@jmdavisprog.com

This code should not compile but does

=
void main()
{
char[] message = "foo".dup;
assert(0, message);
}
=

When assert fails, it gets converted to an AssertError, which - like all
Throwables - takes a string for its message. So, the fact that assert accepts a
char[] rather than a string means that either it's iduping what it's given or
that it's implicitly converting char[] to immutable(char)[], which violates the
type system. And as this D.Learn post demonstrates:

http://forum.dlang.org/post/oiyngoqbjmmyscvlm...@forum.dlang.org

if you go and pass it a slice of a static array, it does _not_ copy the
contents. It's clearly slicing them, which means that it is implicitly
converting the char[] to immutable(char)[], thus violating the type system, and
in the case where you pass it a slice of a static array, you're then dealing
with an invalid pointer.

I don't know why assert accepts anything other than string for its message
(particularly given that AssertError requires a string, and the message needs
to be on the stack), but either it needs to be fixed so that it requires
string, and passing it a char[] is an error, or the implementation needs to
idup the message. I'm inclined to think that restricting it to string and
forcing the user to idup the char[] in the rare case that that's what's wanted
would be the better option, but either way, it needs to be fixed so that assert
doesn't subvert the type system.

--

Re: String copying fails when output from assert

[David Zhang via Digitalmars-d-learn]

On Tuesday, 21 November 2017 at 19:05:21 UTC, Jonathan M Davis 
wrote:
Well, the assertion is going to throw an AssertError, which 
takes a string for its message. It doesn't copy the contents of 
the string. It's just taking a slice just like whenever you 
pass a string to any other function. So, it refers to the same 
memory as what's passed in. So, if what it's passed is a string 
that refers to memory on the stack, then when it goes to print 
the message, it's going to be garbage, because the stack was 
unwound, and the static array is gone.


Honestly, I'd argue that it's a bug that it allows you provide 
a message as a char[] instead of immutable(char)[]. It seems 
that the compiler is implicitly converting char[] to 
immutable(char)[] in this case, which is very bad. It would 
matter less if you were giving the assertion a char[] that 
referred to memory on the heap, but it still shouldn't be 
allowed.


You really should be giving assertions a value that is an 
actual string that lives on the heap when providing a message, 
not a char[], and definitely not a char[] that's a slice of a 
static array.


- Jonathan M Davis


Right. So a literal would work, because it's in the .data 
segment, or inlined. Basically, only strings from the heap, or 
that are compiled into the code are valid for assert messages.


What kind of behavior would an assert from stdc have (id, 
betterC)?

[Issue 18001] Wrong code on signed 32-bit compare of INT_MIN with zero

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

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

Re: String copying fails when output from assert

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 21, 2017 18:49:40 David Zhang via Digitalmars-d-learn 
wrote:
> Hi,
>
> I've been trying to copy a string, then output it from an
> `assert(false)` statement, but the copy seems to be corrupted
> somehow.
>
> void main()
> {
>   string str = "some string";
>
>  //initializing `chars` with any value doesn't do anything
>   char[64] chars;
>   //char[64] chars = '!';
>
>   //memcpy doesn't work either, though the output's different
>   //import core.stdc.string;
>   //memcpy([0], [0], str.length);
>
>   chars[0..str.length] = str;
>   assert(false, chars[0..str.length]);
> }
>
> What am I missing here?

Well, the assertion is going to throw an AssertError, which takes a string
for its message. It doesn't copy the contents of the string. It's just
taking a slice just like whenever you pass a string to any other function.
So, it refers to the same memory as what's passed in. So, if what it's
passed is a string that refers to memory on the stack, then when it goes to
print the message, it's going to be garbage, because the stack was unwound,
and the static array is gone.

Honestly, I'd argue that it's a bug that it allows you provide a message as
a char[] instead of immutable(char)[]. It seems that the compiler is
implicitly converting char[] to immutable(char)[] in this case, which is
very bad. It would matter less if you were giving the assertion a char[]
that referred to memory on the heap, but it still shouldn't be allowed.

You really should be giving assertions a value that is an actual string that
lives on the heap when providing a message, not a char[], and definitely not
a char[] that's a slice of a static array.

- Jonathan M Davis

Re: String copying fails when output from assert

[David Zhang via Digitalmars-d-learn]

On Tuesday, 21 November 2017 at 18:56:03 UTC, Adam D. Ruppe wrote:
On Tuesday, 21 November 2017 at 18:49:40 UTC, David  Zhang 
wrote:

assert(false, chars[0..str.length]);
}

What am I missing here?


You're escaping a reference to a local variable there. chars[] 
is a pointer to the stack, which is promptly smashed when the 
assert error starts working up the call chain, so by the time 
it actually prints, you have undefined behavior.


So I'd have to allocate the buffer on the heap then...
Is there any way to do this without allocating to the stack?

Re: String copying fails when output from assert

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

On Tuesday, 21 November 2017 at 18:49:40 UTC, David  Zhang wrote:

assert(false, chars[0..str.length]);
}

What am I missing here?


You're escaping a reference to a local variable there. chars[] is 
a pointer to the stack, which is promptly smashed when the assert 
error starts working up the call chain, so by the time it 
actually prints, you have undefined behavior.

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

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 21 November 2017 at 18:00:37 UTC, Meta wrote:
I don't quite understand the logic here, because it seems to be 
backwards reasoning. Constrain is a valid type 
because null inhabits it? That doesn't make sense to me. He 
also cites the "implicit constraint" that X extends U where X 
is ? super T, but X does not meet that constraint (Constrain) so how can  the type checker deduce that X 
extends U?


I haven't dug into the details of the paper as I think the 
authors didn't try to appear neutral, e.g. quoting null as the 
billon dollar mistake, and made their finding seem more 
spectacular than it is… What I get from skimming over it is this:


You get a call:

upcast(constrain,x) -> String

   where:
   constrain is of type Constrain
   x is of type X  (X is unspecified supertype of Integer)
   return type is String, which has X as subclass

   So you get String <: X <: Integer

The deduction that String is a superclass of Integer could come 
from:

Constrain

   where X = ? super Integer = unknown type that is supertype of 
Integer

String copying fails when output from assert

[David Zhang via Digitalmars-d-learn]

Hi,

I've been trying to copy a string, then output it from an 
`assert(false)` statement, but the copy seems to be corrupted 
somehow.


void main()
{
string str = "some string";

//initializing `chars` with any value doesn't do anything
char[64] chars;
//char[64] chars = '!';

//memcpy doesn't work either, though the output's different
//import core.stdc.string;
//memcpy([0], [0], str.length);

chars[0..str.length] = str;
assert(false, chars[0..str.length]);
}

What am I missing here?

Re: SublimeLinter-contrib-dmd: dmd feedback as you type

[drug via Digitalmars-d-announce]

31.10.2017 01:22, Bastiaan Veelo пишет:
SublimeLinter-contrib-dmd [1] is a plug-in for the Sublime Text 3 editor 
[2]. Unlike linters that are based on DScanner, it actually invokes dmd 
on the file that is being edited, as you edit. If dmd finds anything to 
complain about, an annotation is shown in the editor: warnings and 
deprecations in orange, errors in red. If SublimeLinter (a plug-in 
dependency) is configured to show tool tips, the error message pops up 
after a click on the annotation (see screen shots [1]). SublimeLinter 
offers shortcuts for jumping to errors and it is possible to postpone 
on-the-fly linting or lint only on request.


The advantages of using dmd for linting are:

1. The parser is always up-to-date.
2. Full symbol resolution, including imports.
3. Mixins are expanded.
4. Templates are validated.
5. Deprecation warnings are included.
6. The "did you mean …" assistance appears right where it is most helpful.

The plug-in is easily installed from within the editor, as described on 
the project page [1].


Dmd does not always get the column number exactly right, which can cause 
the annotation to be misplaced, but that is just a cosmetic deficiency. 
I have not tested this on larger code bases and only on Windows, but I 
expect it to work on all platforms supported by Sublime Text 3. Please 
let me know if you find any issues. The editor is not free, but it 
continues to work after your evaluation period has expired.


On request I can add an option to configure the path to dmd, currently 
it expects to find dmd using the system path.



Hope you like it,
Bastiaan.

[1] https://github.com/veelo/SublimeLinter-contrib-dmd
[2] http://www.sublimetext.com/
Thank you for your tool! It works like a charm even in mixins and works 
out of box. I installed it just in case but now I've caught myself that 
I start using it.

Re: object.Exception@generated\gtkd\gtkd\Loader.d(125):Library load failed(libgio-2.0.0.dll)

[Mike Wey via Digitalmars-d]

On 21-11-17 11:19, PECman wrote:

On Sunday, 19 November 2017 at 13:39:39 UTC, Mike Wey wrote:

On 19-11-17 08:35, PECman wrote:
I complied the D application with gtkD successfully.However,I cant 
run it successfully.My settings are OK.I dunno why it happened to me:-(

Who can help me?


That line usually includes the error returned from LoadLibrary which 
should give an indication of why it failed.


I assume you installed the GTK runtime for the architecture you are 
building for ( 32 or 64 bit ).


But the error is the messy code.
I have already installed the GTK runtime 32 bit(on Windows 7 32 bit)
What shall I do next?


That's unfortunate, usually there is some info on why it fails after the 
`(libgio-2.0-0.dll)`.


First check if the `bin` directory of the GTK installation is on the 
PATH, and if there are any other GTK installs on the PATH, GtkD should 
try to detect the correct runtime to use but that might have failed.


--
Mike Wey

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

[Meta via Digitalmars-d]

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

On Tuesday, 21 November 2017 at 06:03:33 UTC, Meta wrote:
I'm not clear on whether he means that Java's type system is 
unsound, or that the type checking algorithm is unsound. From 
what I can tell, he's asserting the former but describing the 
latter.


He claims that type systems with existential rules, 
hierarchical relations between types and null can potentially 
be unsound. His complaint is that if Java had been correctly 
implemented to the letter of the spec then this issue could 
have led to heap corruption if exploited by a malicious 
programmer.


Runtime checks are part of the type system though, so it isn't 
unsound as implemented as generated JVM does runtime type 
checks upon assignment.


AFAIK the complaint assumes that information from generic 
constraints isn't kept on a separate level.


It is a worst case analysis of the spec...


I don't quite understand the logic here, because it seems to be 
backwards reasoning. Constrain is a valid type 
because null inhabits it? That doesn't make sense to me. He also 
cites the "implicit constraint" that X extends U where X is ? 
super T, but X does not meet that constraint (Constrain) so how can  the type checker deduce that X extends U?

[Issue 17127] bad example code for std.concurrency.Generator

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

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

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

https://github.com/dlang/phobos/commit/5df663ead1203dea2fd7cbaae189bae99c1eafec
Issue 17127 - bad example code for std.concurrency.Generator

https://github.com/dlang/phobos/commit/a7953301bcbbb416cfcf2d35d3c1647e99a82ee9
Merge pull request #5872 from wilzbach/std-concurrency-tests-1

Issue 17127 - bad example code for std.concurrency.Generator
merged-on-behalf-of: Jack Stouffer 

--

Re: Project Highlight: Diamond MVC Framework

[Mengu via Digitalmars-d-announce]

On Tuesday, 21 November 2017 at 05:27:50 UTC, bauss wrote:

On Monday, 20 November 2017 at 14:39:43 UTC, Mike Parker wrote:
You may have seen announcements regarding Diamond here in the 
forums. The project maintainer, Jason Jensen, a.k.a bauss, 
provided me with some info about it for a Project Highlight on 
the D Blog.


Blog:
https://dlang.org/blog/2017/11/20/project-highlight-diamond-mvc-framework/

reddit:
https://www.reddit.com/r/programming/comments/7e98zk/diamond_a_vibedbased_mvc_web_framework_for_d/


Thank you for writing the article!


thank you for developing and maintaining such a huge project.

[Issue 17996] [Reg 2.077] don't build libphobos2.a with PIC for i386

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

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

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

https://github.com/dlang/phobos/commit/1f1efea282d5d9409bedcfcb8e8b9082b492d194
fix Issue 17996 - don't build libphobos2.a with PIC for i386

https://github.com/dlang/phobos/commit/3a2acacb4d4662cd6a2253f7cea2664c0afc11e2
Merge pull request #5868 from MartinNowak/fix17996

--

[Issue 18001] Wrong code on signed 32-bit compare of INT_MIN with zero

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

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

yebblies  changed:

   What|Removed |Added

   Keywords||wrong-code

--

[Issue 18001] New: Wrong code on signed 32-bit compare of INT_MIN with zero

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

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

  Issue ID: 18001
   Summary: Wrong code on signed 32-bit compare of INT_MIN with
zero
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: yebbl...@gmail.com

The following code prints "result: 1 -2147483648"

extern(C) int printf(const char* format, ...);

uint get()
{
return 0x8000;
}

void test(bool b, int v)
{
printf("result: %d %d\n", b, v);
}

void main()
{
test(cast(int)get() > 0, get());
}

This happens because the codegen for the compare is using the identity (a > 0)
=== (-a < 0) which doesn't hold for INT_MIN.

 <_Dmain>:
   0:   55  push   %rbp
   1:   48 8b ecmov%rsp,%rbp
   4:   48 83 ec 10 sub$0x10,%rsp
   8:   e8 00 00 00 00  callq  d <_Dmain+0xd>
9: R_X86_64_PC32_D5testx3getFZk-0x4
   d:   48 89 c6mov%rax,%rsi
  10:   f7 de   neg%esi
  12:   c1 ee 1fshr$0x1f,%esi
  15:   48 89 75 f8 mov%rsi,-0x8(%rbp)
  19:   e8 00 00 00 00  callq  1e <_Dmain+0x1e>
1a: R_X86_64_PC32   _D5testx3getFZk-0x4
  1e:   48 89 c7mov%rax,%rdi
  21:   48 8b 75 f8 mov-0x8(%rbp),%rsi
  25:   e8 00 00 00 00  callq  2a <_Dmain+0x2a>
26: R_X86_64_PC32   _D5testx4testFbiZv-0x4
  2a:   31 c0   xor%eax,%eax
  2c:   c9  leaveq
  2d:   c3  retq
...

--

[Issue 17999] UCRTVersion not properly set for Visual Studio Community 2017

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

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

--- Comment #2 from Bastiaan Veelo  ---
Use of the -m32mscoff option needs the same change under the
[Environment32mscoff] section.

--

Re: TickDuration deprecation

[Kagamin via Digitalmars-d]

On Sunday, 19 November 2017 at 19:29:06 UTC, Jon Degenhardt wrote:
1) Finding the documentation for Duration from the 
documentation of std.datetime.stopwatch is not quick enough. 
There is only one link from the page, and it's near the bottom, 
with the benchmark function (which is rarely what I need).


dpldocs sort of allow you to do it: 
http://dpldocs.info/experimental-docs/std.datetime.stopwatch.StopWatch.peek.html it links types used in function signature.

[Issue 18000] New: [scope] auto-generated opAssign not scope aware

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

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

  Issue ID: 18000
   Summary: [scope] auto-generated opAssign not scope aware
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
module bug;

struct File
{
@safe @nogc:
~this() scope
{
}

void* f;
}

void test() @safe @nogc
{
scope File f;
f = File();
}
CODE
dmd -c -dip1000 bug

bug.d(16): Error: scope variable f assigned to non-scope parameter this calling
bug.File.opAssign


We should infer scope for any auto-generated functions like opAssign.

--

Re: TickDuration deprecation

[Kagamin via Digitalmars-d]

On Saturday, 18 November 2017 at 22:46:20 UTC, Jon Degenhardt 
wrote:
I admittedly don't understand the argument that it should be 
hard to user programs to convert time durations to alternate 
standard units of measure.


If you want to communicate with a system that uses a floating 
point time format, you would need exactly same conversion 
algorithm not just something similar, so that round trip doesn't 
introduce computational errors.

[Issue 17966] chunkBy cannot accept an input range (from multiwayMerge)

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

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

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

https://github.com/dlang/druntime/commit/84ac676d1d26edd8b3611d857adc5caed42c92d5
fix Issue 17966 - don't build libphobos2.a with PIC for i386

https://github.com/dlang/druntime/commit/7c8ca6a4f0f3d4eb7564e00d4d770044ba8b889d
Merge pull request #1974 from MartinNowak/fix17996

--

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

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

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

--- Comment #14 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/9fee0ca6365408d753aedb517c0896af36966b65
Merge pull request #1966 from nemanja-boric-sociomantic/fiber-docs

--

Re: dub: Use Alternate Dependency

[jmh530 via Digitalmars-d-learn]

On Tuesday, 21 November 2017 at 07:36:25 UTC, drug wrote:


Probably author needs the following:
dependency "package" version="*" 
path="../relative/path/to/other/custom/package"

instead of
dependency "package" version="~>1.2.3"

this allows using custom package not registered on dub and 
after debugging register them and use them as usual.


That looks like it will be useful. For bauss's recommendation, I 
would effectively have to register the working directory with dub 
add-local and give it a version in order for it to work. I think 
it would work, but this looks to be fewer steps. I don't have to 
remember to remove it when I'm done, just to not use "git add .".

Re: DIP 1006 - Preliminary Review Round 1

[Martin Nowak via Digitalmars-d]

On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote:
DIP 1006 is titled "Providing more selective control over 
contracts".


https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md


Has come up a couple of times and it's a good idea to allow more 
control over which checks are enabled.
I find the suggested switch levels a bit counter-intuitive and 
would suggest


  -release=assert,in,out,invariant

to be the equivalent of the current

  -release

while allowing to enable any subset, e.g.

  -release=assert,in.

The effect of

  -release=assert -release=in

would be to enable both.

Using -release= also avoids any confusion about the interaction 
of -release and -contracts=.

Re: DIP 1006 - Preliminary Review Round 1

[Martin Nowak via Digitalmars-d]

On Wednesday, 12 April 2017 at 15:02:49 UTC, Mathias Lang wrote:
I would say that `-contracts=none` and `-unittest` should 
behave the same as `-release` and `-unittest`, and currently it 
only turns asserts on ( 
https://github.com/dlang/dmd/blob/ac3225a025b578d45ff39a40dda35006fb455a37/src/ddmd/mars.d#L1100-L1109 ).

I'll add a note about it in the DIP.


As said above, asserts in unittests are different, so we could 
separate enabling asserts in unittests and in the rest of the 
program.

[Issue 17999] UCRTVersion not properly set for Visual Studio Community 2017

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

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

--- Comment #1 from Bastiaan Veelo  ---
dmd-2.077.0

--

[Issue 17999] New: UCRTVersion not properly set for Visual Studio Community 2017

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

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

  Issue ID: 17999
   Summary: UCRTVersion not properly set for Visual Studio
Community 2017
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: basti...@veelo.net

When Visual Studio Community is the only version present on Windows 10, with
the minimal set of options that satisfies the dmd installer
(https://wiki.dlang.org/File:Visual_Studio_Installer.png) then dmd -m64 will
fail to link:
LINK : fatal error LNK1104: cannot open file 'libucrt.lib'
Error: linker exited with status 1104

The problem goes away after changing UCRTVersion in
C:\D\dmd2\windows\bin\sc.ini:

;UCRTVersion=winv6.3
UCRTVersion=10.0.10240.0


(Fresh dmd install.)

--

Re: "body" keyword is unnecessary

[Nick Treleaven via Digitalmars-d]

On Sunday, 19 November 2017 at 11:54:04 UTC, Tony wrote:

dmd --version
DMD64 D Compiler v2.077.0
Copyright (c) 1999-2017 by Digital Mars written by Walter Bright

dmd test_contracts.d
test_contracts.d(13): Error: missing `body { ... }` after `in` 
or `out`


Just made a pull to fix this:
https://github.com/dlang/dmd/pull/7347

Mirroring a drawable buf in DLangUI?

[Dukc via Digitalmars-d-learn]

I am using the DrawRescaled method of DrawBuf[1] of DLangUI To 
draw a PNG image to a CanvasWidget[2] subclass. It has a minor 
issue of the box bounds showing in area that shoud be transparent 
but otherwise works well.


My question is, does anybody know a way to draw that image 
backwards without making another PNG file to do so? I tried to 
pass a dstrect with negative width but that results in nothing 
being drawn.


1: 
http://buggins.github.io/dlangui/ddox/dlangui/graphics/drawbuf/DrawBuf.html
2: 
http://buggins.github.io/dlangui/ddox/dlangui/widgets/controls/CanvasWidget.html

[Issue 12385] Enum member should not be modifiable when the member is immutable

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

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

Mike  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #1 from Mike  ---
Pull Request Submitted: https://github.com/dlang/dmd/pull/7348

--

Re: dmd/ldc failed with exit code -11

[Anonymouse via Digitalmars-d-learn]

On Tuesday, 21 November 2017 at 10:12:11 UTC, Petar Kirov 
[ZombineDev] wrote:
On Tuesday, 21 November 2017 at 10:10:59 UTC, Petar Kirov 
[ZombineDev] wrote:

On Tuesday, 21 November 2017 at 00:15:04 UTC, Anonymouse wrote:
I have a large named enum (currently 645 members) of IRC 
event types. It's big by neccessity[1].


I'm using dub, and both dmd and ldc successfully build it in 
test and debug modes, but choke and die on plain and release. 
I bisected it down to when I did a big addition to the enum 
to encompass virtually all event types there are.




Try using https://github.com/CyberShadow/DustMite/wiki to 
obtain a minimal test case which reproduces the issue and file 
bug report(s).


This tool can actually be used straight from dub itself:
http://code.dlang.org/docs/commandline#dustmite


I'm having trouble constructing a dustmite test of that, as I can 
only pass it a initial known good state by removing the parts I 
know exhibit the segfault.


Looking at the dmd command dub issues and testing them myself I 
notice that if I reorder the arguments it builds.


$ dmd -d -oftest source/arsd/*.d source/kameloso/plugins/*.d 
source/kameloso/*.d
zsh: segmentation fault (core dumped)  dmd -d -ofkek 
source/arsd/*.dd source/kameloso/plugins/*.d source/kameloso/*.d


$ dmd -d -oftest source/kameloso/plugins/*.d 
source/kameloso/*.d source/arsd/*.d

$ echo $?
0

Re: dmd/ldc failed with exit code -11

[Anonymouse via Digitalmars-d-learn]

On Tuesday, 21 November 2017 at 00:36:00 UTC, rikki cattermole 
wrote:

Source code please.


https://github.com/zorael/kameloso.git

I'm not proud of some of the early bits there (main.d) so don't 
judge me, please. I'm learning as I go.


The offending bits are IRCEvent.Type in ircstructs.d[1]. If I 
comment out part of it[2] making the enum smaller, it compiles. 
dub build always works, dub build -b plain doesn't.



[1] 
https://github.com/zorael/kameloso/blob/master/source/kameloso/ircstructs.d#L22
[2] 
https://github.com/zorael/kameloso/blob/mite/source/kameloso/ircstructs.d#L417-L700

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

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

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

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

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

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

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

--- Comment #13 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/1c12d6d59e6a3eccf42efe379066c0a9c658fa36
Add std.concurrency.Generator overloads to accept Fiber's stack guard's size

As of 2.075 Fiber's stack protection pages are on by default, preventing
OS to merge mmaped ranges, so the total number of mmaped ranges is much
higher than before. In case there's no need for the stack overflow
protection and the high number of fibers, it may be wise to change this
setting, so the Generator's constructor overloads which support
this are added.

Fix issue 17914

--

[Issue 17998] New: Document Options for install.sh

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

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

  Issue ID: 17998
   Summary: Document Options for install.sh
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: john.michael.h...@gmail.com

The D install script install.sh is mentioned on the website a few times, but
all of its options are not described. I was surprised to learn from [1] that
you could use it to install ldc.

1] https://github.com/ldc-developers/ldc/pull/2421#pullrequestreview-77997374

--

Re: Turn a float into a value between 0 and 1 (inclusive)?

[Biotronic via Digitalmars-d-learn]

On Tuesday, 21 November 2017 at 09:21:29 UTC, Chirs Forest wrote:
I'm interpolating some values and I need to make an 
(elapsed_time/duration) value a float between 0 and 1 
(inclusive of 0 and 1). The elapsed_time might be more than the 
duration, and in some cases might be 0 or less. What's the most 
efficient way to cap out of bounds values to 0 and 1? I can do 
a check and cap them manually, but if I'm doing a lot of these 
operations I'd like to pick the least resource intensive way.


Good old comparisons should be plenty in this case:

T clamp(T)(T value, T min, T max) {
return value < min ? min : value > max ? max : value;
}

That's two comparisons and two conditional moves. You're not 
gonna beat that.


Also, if I wanted out of bounds values to wrap (2.5 becomes 
0.5) how would I get that value and also have 1.0 not give me 
0.0?


As Petar points out, this is somewhat problematic. You think of 
the codomain (set of possible results) as being the size (1.0 - 
0.0) = 1.0. However, since you include 1.0 in the set, the size 
is actually 1.0 + ε, which is very slightly larger. You could use 
a slightly modified version of Petar's function:


T zeroToOne(T)(T val) { return val % (1+T.epsilon); }

However, this induces rounding errors on larger numbers. e.g. 1.0 
+ ε becomes 0, while you'd want it to be ε.


I guess I should ask for some clarification - what would you 
expect the return value to be for 2.0? Is that 0.0 or 1.0? How 
about for -1.0?


A simple function that does give the results you want between 0.0 
and 1.0 (inclusive) is this:


T zeroToOne(T)(T val) {
if (val >= 0 && val <= 1.0) {
return val;
}
return val % 1;
}

The problem now, however, is that zeroToOne gives negative 
results for negative values. This is probably not what you want. 
This can be fixed with std.math.signbit:


T zeroToOne(T)(T val) {
import std.math : signbit;
if (val >= 0 && val <= 1.0) {
return val;
}
return (val % 1) + val.signbit;
}

If you're willing to give up the last 1/8388608th of precision 
(for float, 1/4503599627370496th for double) that including 1.0 
gives you, this can become:


T zeroToOne(T)(T val) {
import std.math : signbit;
return (val % 1) + val.signbit;
}

Which is easier to read, and consistent for values outside the 
[0,1) interval.


--
  Biotronic

[Issue 12929] Empty union followed by field causes ICE due to offset of 0.

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

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

Mike  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #3 from Mike  ---
Test cases submitted:  https://github.com/dlang/dmd/pull/7343

--

[Issue 17996] [Reg 2.077] don't build libphobos2.a with PIC for i386

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

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

Martin Nowak  changed:

   What|Removed |Added

Summary|[Reg 2.077] getopt fails to |[Reg 2.077] don't build
   |recognize argument  |libphobos2.a with PIC for
   ||i386

--

[Issue 17997] autotester's d_do_test has strange failures with Win32

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

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

--- Comment #1 from Walter Bright  ---
See https://github.com/dlang/dmd/pull/7333 for details.

--

[Issue 17997] New: autotester's d_do_test has strange failures with Win32

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

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

  Issue ID: 17997
   Summary: autotester's d_do_test has strange failures with Win32
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

d_do_test.d has an odd failure on Win32. I get two failures:

 Makefile:163: recipe for target 'test_results/compilable/test16031.d.out'
failed
 gmake[1]: *** [test_results/compilable/test16031.d.out] Error 127
 Makefile:201: recipe for target 'start_compilable_tests' failed
 gmake: *** [start_compilable_tests] Error 2

and:

 Makefile:170: recipe for target 'test_results/fail_compilation/cppeh2.d.out'
failed
 gmake[1]: *** [test_results/fail_compilation/cppeh2.d.out] Error 127
 Makefile:207: recipe for target 'start_fail_compilation_tests' failed
 gmake: *** [start_fail_compilation_tests] Error 2
 gmake: *** Waiting for unfinished jobs

In test16031.d it says:

 // REQUIRED_ARGS: -fPIC -lib
 // PERMUTE_ARGS:
 // DISABLED: win32 win64

and in cppeh2.d it says:

 // DISABLED: win32 win64

Running d_do_test locally on my Win32 box shows no abnormal behavior.

--

Re: object.Exception@generated\gtkd\gtkd\Loader.d(125):Library load failed(libgio-2.0.0.dll)

[PECman via Digitalmars-d]

On Sunday, 19 November 2017 at 13:39:39 UTC, Mike Wey wrote:

On 19-11-17 08:35, PECman wrote:
I complied the D application with gtkD successfully.However,I 
cant run it successfully.My settings are OK.I dunno why it 
happened to me:-(

Who can help me?


That line usually includes the error returned from LoadLibrary 
which should give an indication of why it failed.


I assume you installed the GTK runtime for the architecture you 
are building for ( 32 or 64 bit ).


But the error is the messy code.
I have already installed the GTK runtime 32 bit(on Windows 7 32 
bit)

What shall I do next?

Re: dmd/ldc failed with exit code -11

[Petar via Digitalmars-d-learn]

On Tuesday, 21 November 2017 at 10:10:59 UTC, Petar Kirov 
[ZombineDev] wrote:

On Tuesday, 21 November 2017 at 00:15:04 UTC, Anonymouse wrote:
I have a large named enum (currently 645 members) of IRC event 
types. It's big by neccessity[1].


I'm using dub, and both dmd and ldc successfully build it in 
test and debug modes, but choke and die on plain and release. 
I bisected it down to when I did a big addition to the enum to 
encompass virtually all event types there are.




Try using https://github.com/CyberShadow/DustMite/wiki to 
obtain a minimal test case which reproduces the issue and file 
bug report(s).


This tool can actually be used straight from dub itself:
http://code.dlang.org/docs/commandline#dustmite

Re: dmd/ldc failed with exit code -11

[Petar via Digitalmars-d-learn]

On Tuesday, 21 November 2017 at 00:15:04 UTC, Anonymouse wrote:
I have a large named enum (currently 645 members) of IRC event 
types. It's big by neccessity[1].


I'm using dub, and both dmd and ldc successfully build it in 
test and debug modes, but choke and die on plain and release. I 
bisected it down to when I did a big addition to the enum to 
encompass virtually all event types there are.




Try using https://github.com/CyberShadow/DustMite/wiki to obtain 
a minimal test case which reproduces the issue and file bug 
report(s).

Re: DMD test suite assertion failure in test_cdvecfill.d

[Petar via Digitalmars-d-learn]

On Tuesday, 21 November 2017 at 07:02:20 UTC, Michael V. Franklin 
wrote:

I'm getting this error when I try to run the DMD test suite.

cd dmd
make -C test -f Makefile

[...]


I don't think you're doing anything wrong, though you shouldn't 
be getting that error. File a bug report and try contacting 
Martin Nowak, as he's the author of this test, IIRC.

Re: Turn a float into a value between 0 and 1 (inclusive)?

[Petar via Digitalmars-d-learn]

On Tuesday, 21 November 2017 at 09:53:33 UTC, Petar Kirov 
[ZombineDev] wrote:
On Tuesday, 21 November 2017 at 09:21:29 UTC, Chirs Forest 
wrote:
I'm interpolating some values and I need to make an 
(elapsed_time/duration) value a float between 0 and 1 
(inclusive of 0 and 1). The elapsed_time might be more than 
the duration, and in some cases might be 0 or less. What's the 
most efficient way to cap out of bounds values to 0 and 1? I 
can do a check and cap them manually, but if I'm doing a lot 
of these operations I'd like to pick the least resource 
intensive way.


Also, if I wanted out of bounds values to wrap (2.5 becomes 
0.5) how would I get that value and also have 1.0 not give me 
0.0?


Is this what you're looking for:
https://www.desmos.com/calculator/8iytgsr3y3

In which case that would be simply:
T zeroToOne(T)(T val) { return val % 1; }


The problem, as you can see in the plot is that 0.9(9) remains 
0.9(9), however 1.0 and 1.001 become 0.0 and 0.001 
respectively and there's no way around this due to the inherent 
discontinuity of the function.

Re: Turn a float into a value between 0 and 1 (inclusive)?

[Petar via Digitalmars-d-learn]

On Tuesday, 21 November 2017 at 09:21:29 UTC, Chirs Forest wrote:
I'm interpolating some values and I need to make an 
(elapsed_time/duration) value a float between 0 and 1 
(inclusive of 0 and 1). The elapsed_time might be more than the 
duration, and in some cases might be 0 or less. What's the most 
efficient way to cap out of bounds values to 0 and 1? I can do 
a check and cap them manually, but if I'm doing a lot of these 
operations I'd like to pick the least resource intensive way.


Also, if I wanted out of bounds values to wrap (2.5 becomes 
0.5) how would I get that value and also have 1.0 not give me 
0.0?


Is this what you're looking for:
https://www.desmos.com/calculator/8iytgsr3y3

In which case that would be simply:
T zeroToOne(T)(T val) { return val % 1; }

Turn a float into a value between 0 and 1 (inclusive)?

[Chirs Forest via Digitalmars-d-learn]

I'm interpolating some values and I need to make an 
(elapsed_time/duration) value a float between 0 and 1 (inclusive 
of 0 and 1). The elapsed_time might be more than the duration, 
and in some cases might be 0 or less. What's the most efficient 
way to cap out of bounds values to 0 and 1? I can do a check and 
cap them manually, but if I'm doing a lot of these operations I'd 
like to pick the least resource intensive way.


Also, if I wanted out of bounds values to wrap (2.5 becomes 0.5) 
how would I get that value and also have 1.0 not give me 0.0?

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

[Ola Fosheim Grostad via Digitalmars-d]

On Tuesday, 21 November 2017 at 06:03:33 UTC, Meta wrote:
I'm not clear on whether he means that Java's type system is 
unsound, or that the type checking algorithm is unsound. From 
what I can tell, he's asserting the former but describing the 
latter.


He claims that type systems with existential rules, hierarchical 
relations between types and null can potentially be unsound. His 
complaint is that if Java had been correctly implemented to the 
letter of the spec then this issue could have led to heap 
corruption if exploited by a malicious programmer.


Runtime checks are part of the type system though, so it isn't 
unsound as implemented as generated JVM does runtime type checks 
upon assignment.


AFAIK the complaint assumes that information from generic 
constraints isn't kept on a separate level.


It is a worst case analysis of the spec...

Re: DMD PR management hits a new low

[Iain Buclaw via Digitalmars-d]

On 20 November 2017 at 00:11, Walter Bright via Digitalmars-d
 wrote:
> On 11/19/2017 3:54 AM, Iain Buclaw wrote:
>>
>> When I have time, I have it in my todo list to review everything below PR
>> 6000.
>>
>> https://issues.dlang.org/show_bug.cgi?id=17839
>
>
> Thank you, Iain! Recently I did a look through the old ones for optlink
> bugs, and found a number of them were already fixed, duplicates or no longer
> relevant.


FYI, this will likely be over the holiday period.  Probably the most
high priority ones to address are all Kenji's old PRs.