Re: What is the FreeBSD situation?

[codephantom via Digitalmars-d]

On Saturday, 4 November 2017 at 11:04:33 UTC, rjframe wrote:
Many people seem to leave the module statement out of their 
main.d/app.d files; I think it's a way to say "this is the main 
thing - don't import it from somewhere else." Basically, it's 
easier to act like that code isn't in a module than it is to 
have the compiler support code not in a module.


I think maybe, the compiler should just refuse to compile 
anything, unless the module namespace is explicitely stated. I 
don't know what the effects of that would be in total, but it 
would avoid compilation errors when, for example, you do what I 
do - which is create 100's of snippets of code, save each snippet 
with a name corresponding to the thing 'snipped' (so I can easily 
find them again), and then discovering that they won't compile.


(i.e. D having neither a default global namespace, and then the 
compiler making implicit assumptions about what namespace to use, 
based on the file name, seems problematic. Better to just 'refuse 
to compile' a file, unless it explicitely states a module 
namespace.


e.g. (the .d files further below, without any module name 
specified, will not compile - presumably because the compiler is 
having problems resolving the namespace.


So why is the compiler forced to do that anyway? Why not just 
refuse to compile simply because no module namespace was provided 
- then a nice clear message stating that, could be provided back 
to the user, instead of the cryptic message: "  Error: function 
expected before (), not module writeln of type void"



-save this as writeln.d and it will not compile 
-

import std.stdio;

void main()
{
writeln("Hello World!");
}
---


-save this as to.d and it will not compile -
import std.stdio;
import std.conv;

void main()
{
auto i = to!string(55);

}

Re: problem with multiwayMerge and chunkBy

[Nicholas Wilson via Digitalmars-d-learn]

On Saturday, 4 November 2017 at 18:57:17 UTC, Matthew Gamble 
wrote:

Dear most helpful and appreciated D community,

I'm a non-pro academic biologist trying to code a modeler of 
transcription in D. I've run into a small roadblock. Any help 
would be greatly appreciated. I'm hoping someone can tell me 
why I get the following run-time error from this code. I've 
reduced it to something simple:


import std.algorithm;
import std.range;

auto d =[2,4,6,8];
auto e =[1,2,3,5,7];
auto f =[d,e];

writeln(f.multiwayMerge.chunkBy!"a == b");//error happens
writeln(f.multiwayMerge.array.chunkBy!"a == b");//no 
error, but there must be a better way!


My understanding is that chunkBy should be able to take an 
input range. Is that not true? I'm trying to get a merged 
sorted view of two sorted ranges followed by merging records 
based on a predicate without allocating memory or swapping the 
underlying values. Speed will be very important at the end of 
the day and sticking the ".array" in the middle kills me, given 
the size of the actual ranges.


It should, this looks like a bug somewhere, please file one at 
issues.dlang.org/ .


in the mean time

struct Replicate(T)
{
Tuple!(T, uint) e;
@property bool empty() { return e[1] == 0 ; }
@property auto front() {return e[0]; }
void popFront() { --e[1]; }
}

Replicate!T replicate(T)(Tuple!(T, uint) e)
{
return typeof(return)(e);
}

f.multiwayMerge.group!"a == b".map!(replicate).writeln;

Does the same thing provided your predicate is "a == b".

Re: What are the unused but useful feature you know in D?

[rikki cattermole via Digitalmars-d]

On 04/11/2017 6:13 PM, bauss wrote:

On Saturday, 4 November 2017 at 13:27:29 UTC, rikki cattermole wrote:

On 04/11/2017 2:14 PM, jmh530 wrote:

[...]


Okay so:

A signature when it is initiated is aware of the implementation it is 
referencing. Allowing it to change how it behaves for compatibility 
reasons.


An interface is designed so that a class/interface must know of the 
interface to inherit from.


While signatures can and probably will inherit from others, this is 
not how it is used unlike with interfaces. Because this is a massive 
change in how we view them and their usage, extending interfaces is 
not appropriate. Luckily an already existing concept exists in the 
literature which does solve most of the goals and that is signatures 
from the ML family.


I will make a mental note to rewrite that section.


It reminds a lot of traits in Rust.

https://doc.rust-lang.org/1.8.0/book/traits.html


Rust traits are a variant of ML's signature. Only they decided to add a 
whole new concept which is 'impl' to it.


While it is a nice idea, it would be a pain to use in real life and 
defeat the purpose of a signature. Which is to act as more of a 
'concept' abstraction to other items.


Because we have such powerful meta-programming features I see no reason 
to separate out the two. We can do it all in one which makes it nice and 
consistent between all the different implementations for a signature 
type. So far its starting to feel right at home against our structs and 
class support, I think.

Re: Improve "Improve Contract Syntax" DIP 1009

[Timon Gehr via Digitalmars-d]

On 04.11.2017 10:12, Adam D. Ruppe wrote:

On Saturday, 4 November 2017 at 13:59:39 UTC, Jonathan M Davis wrote:
I'm very much of the opinion that proper unit tests pretty much 
eliminate the need for out contracts.


I think that sqrt example is just bad.


It is indeed bad, because it is buggy.
(The out contract may overflow.)

Out contracts shouldn't be 
testing specific values,


It's not testing specific values. It is testing for input-dependent 
properties of the output (which in this case happen to pinpoint the 
output exactly for each input).


but rather ranges or nullness or other such 
things that arguably should be part of the return type, but just don't 
fit in the type system for whatever reason.


I don't see how that is in contrast to the given example. Clearly, the 
conditions that it is testing for should have been represented in the 
type system. Then the example would not compile. Also, one would not be 
able to complain about runtime overhead.

Re: Improve "Improve Contract Syntax" DIP 1009

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 4 November 2017 at 16:57:50 UTC, Adam D. Ruppe wrote:
On Saturday, 4 November 2017 at 15:27:39 UTC, Ola Fosheim 
Grøstad wrote:
No, Jonathan is correct. The postcondition should be able to 
access values as they were stated in the precondition.


Yes, they should be able to access values, but D's limitations 
on this doesn't make them useless or replaced by unittests. 
They do a different job than unittests.


But then they do a job that subtyping does better…? So why do 
this with "contracts"?


Anyhow, I think the ideal for contracts in terms of debugging is 
to express postconditions in terms of public interface rather 
than internal representation, e.g. for a stack push:


oldthis.size() + 1 == newthis.size()  // or length() or whatever 
the interface provides


Then hammer the interface in unit tests rather than writing the 
explicit test in the unit test itself. (e.g. the unit test does 
not have to know the conditions, just explore a wide range of 
configurations).

Re: Any book recommendation for writing a compiler?

[Eugene Wissner via Digitalmars-d-learn]

On Wednesday, 1 November 2017 at 20:53:44 UTC, Dr. Assembly wrote:
Hey guys, if I were to get into dmd's source code to play a 
little bit (just for fun, no commercial use at all), which 
books/resources do you recommend to start out?


A few more resources on writing a frontend (lexer, syntactic and 
semantic analizer).


http://thinkingeek.com/gcc-tiny/
Tells how to create a GCC frontend for a Pascal-like language, 
tiny. Can be useful since you can look how it applies to a real 
dfrontend in GDC.


https://ruslanspivak.com/lsbasi-part1/
Very clear tutorial on writing a Pascal interpreter in Python. 
Very beginner friendly, but not complete yet.


http://buildyourownlisp.com/contents
It is an online book that teaches C by writing an interpreter for 
a Lisp-like language, lispy. The code can be easely translated to 
D.


If you want you can also look at some haskell books. A simple 
parser is one of the standard projects used to teach haskell.

Debug info for druntime.

[ciechowoj via Digitalmars-d-learn]

What is the fastest way to have the detailed debug info for 
druntime? I have a program that fails in Fiber constructor after 
I create and delete at least 68_209 Fibers one after another. For 
68_208 works fine, one more and it aborts. I'm trying to use gdb 
to debug, but most likely don't have symbols for druntime. I 
compiled the druntime from source, is there a way to make the 
dmd/dub use the source compiled version?

Re: Reorganization and list of D libraries (300+)

[Fra Mecca via Digitalmars-d-announce]

On Saturday, 4 November 2017 at 12:11:39 UTC, FreeSlave wrote:



I checked README.md in this repo. Not sure why my nick is used 
in place of name of lnk library.

Also inilike has nothing to do with argv.


Thank you, corrected

Re: Reorganization and list of D libraries (300+)

[Fra Mecca via Digitalmars-d-announce]

On Saturday, 4 November 2017 at 11:26:42 UTC, Jacob Carlborg 
wrote:


DWT is using the EPL, Eclipse Public License, license.
I'm missing the ddb [1] and mysql-native [2] database libraries.
There are many list like this for other languages, they're 
usually called "awesome-" where  is the language.


[1] https://github.com/pszturmaj/ddb
[2] https://github.com/mysql-d/mysql-native


I checked awesome-D but it is not focused only on libraries and 
it is not updated at all.

Also, I wanted to highlight the license and the use of @nogc

I added mysql-native, while I ignored ddb because the project 
provides no description and no documentation. Maybe a README 
would be enought to get you through the examples.

Also, updated DWT

Please send a PR if you feel like the project could be improved

Re: Any book recommendation for writing a compiler?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Saturday, 4 November 2017 at 15:51:30 UTC, Basile B. wrote:
People who say that after reading the dragon book, you will 
program your own programming language are lying.


Well, you most certainly can write your own programming language 
after reading about 30% of the dragon book, but I think you can 
find easier books to get started these days.


For more advanced stuff I would recommend downloading power 
points or notes from university courses on master or ph.d. level. 
The books  and articles on more advanced stuff are often heavy on 
formalisms and difficult to digest for most programmers.

Re: What are the unused but useful feature you know in D?

[Walter Bright via Digitalmars-d]

On 6/25/2017 9:31 PM, H. S. Teoh via Digitalmars-d wrote:

It happens for template functions, member functions of templated
aggregates (structs/classes), and auto functions.
And all function literals, and all functions generated by the compiler (such as 
lazy delegates and aggregate destructors).

Re: Diamond MVC / Template Engine - v2.1.0 Released

[bauss via Digitalmars-d-announce]

On Friday, 3 November 2017 at 14:43:32 UTC, WebFreak001 wrote:

On Friday, 3 November 2017 at 14:16:53 UTC, bauss wrote:
On Thursday, 2 November 2017 at 22:55:04 UTC, WebFreak001 
wrote:

[...]


I don't normally use VS Code, so to create a template for it 
are there anything specific it must include?


And yeah I'll come up with some longer examples and tutorials, 
for now I've made a temporary website with a bit of 
documentation as well API docs.


https://diamondmvc.github.io/Diamond/


Cool, I will take a look at that website.

There aren't actually templates in vscode but my D plugin adds 
some for D projects, you can check the folder in here: 
https://github.com/Pure-D/code-d/tree/master/templates


Created a pull-request with empty templates for Diamond projects.

problem with multiwayMerge and chunkBy

[Matthew Gamble via Digitalmars-d-learn]

Dear most helpful and appreciated D community,

I'm a non-pro academic biologist trying to code a modeler of 
transcription in D. I've run into a small roadblock. Any help 
would be greatly appreciated. I'm hoping someone can tell me why 
I get the following run-time error from this code. I've reduced 
it to something simple:


import std.algorithm;
import std.range;

auto d =[2,4,6,8];
auto e =[1,2,3,5,7];
auto f =[d,e];

writeln(f.multiwayMerge.chunkBy!"a == b");//error happens
writeln(f.multiwayMerge.array.chunkBy!"a == b");//no 
error, but there must be a better way!


My understanding is that chunkBy should be able to take an input 
range. Is that not true? I'm trying to get a merged sorted view 
of two sorted ranges followed by merging records based on a 
predicate without allocating memory or swapping the underlying 
values. Speed will be very important at the end of the day and 
sticking the ".array" in the middle kills me, given the size of 
the actual ranges.


Thank you so much for your help. The full tale-of-the-tape is 
below.


Thanks,
Matt

error:
[[1], [2, 2], [3], [4], [5], [6], [7], [8
core.exception.AssertError@C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\primitives.d(2055):
 Attempting to popFront() past the end of an array of int

0x7FF7A30775D3 in d_assert_msg
0x7FF7A303E497 in std.range.primitives.popFront!int.popFront 
at 
C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\primitives.d(2056)
0x7FF7A304450C in std.algorithm.setops.MultiwayMerge!("a < 
b", int[][]).MultiwayMerge.popFront at 
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\setops.d(877)
0x7FF7A304A700 in 
std.algorithm.iteration.ChunkByChunkImpl!(binaryFun, 
std.algorithm.setops.MultiwayMerge!("a < b", 
int[][])).ChunkByChunkImpl.popFront at 
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\iteration.d(1624)
0x7FF7A3054877 in 
std.format.formatRange!(std.stdio.File.LockingTextWriter, 
std.algorithm.iteration.ChunkByChunkImpl!(binaryFun, 
MultiwayMerge!("a < b", int[][])), char).formatRange at 
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(2960)
0x7FF7A3054796 in 
std.format.formatValue!(std.stdio.File.LockingTextWriter, 
std.algorithm.iteration.ChunkByChunkImpl!(binaryFun, 
MultiwayMerge!("a < b", int[][])), char).formatValue at 
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(3676)
0x7FF7A3054704 in 
std.format.formatElement!(std.stdio.File.LockingTextWriter, 
std.algorithm.iteration.ChunkByChunkImpl!(binaryFun, 
MultiwayMerge!("a < b", int[][])), char).formatElement at 
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(3180)
0x7FF7A305410E in 
std.format.formatRange!(std.stdio.File.LockingTextWriter, 
std.algorithm.iteration.ChunkByImpl!("a == b", MultiwayMerge!("a 
< b", int[][])), char).formatRange at 
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(2964)
0x7FF7A3053F66 in 
std.format.formatValue!(std.stdio.File.LockingTextWriter, 
std.algorithm.iteration.ChunkByImpl!("a == b", MultiwayMerge!("a 
< b", int[][])), char).formatValue at 
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(3676)
0x7FF7A304B053 in 
std.format.formattedWrite!(std.stdio.File.LockingTextWriter, 
char, std.algorithm.iteration.ChunkByImpl!("a == b", 
MultiwayMerge!("a < b", int[][]))).formattedWrite at 
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(568)
0x7FF7A3069BA2 in 
std.stdio.File.write!(std.algorithm.iteration.ChunkByImpl!("a == 
b", MultiwayMerge!("a < b", int[][])), char).write at 
C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(1407)
0x7FF7A30699DB in 
std.stdio.writeln!(std.algorithm.iteration.ChunkByImpl!("a == b", 
MultiwayMerge!("a < b", int[][]))).writeln at 
C:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(3604)
0x7FF7A303E258 in gappedIntervals.__unittestL70_4 at 
C:\Users\matth\Documents\GambleLabCodeBaseLocal\intervals\gappedIntervals.d(78)

0x7FF7A3061917 in void gappedIntervals.__modtest()
0x7FF7A307C08B in int 
core.runtime.runModuleUnitTests().__foreachbody1(object.ModuleInfo*)
0x7FF7A3082663 in int object.ModuleInfo.opApply(scope int 
delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*))
0x7FF7A308594F in int rt.minfo.moduleinfos_apply(scope int 
delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref 
rt.sections_win64.SectionGroup)
0x7FF7A30858BF in int rt.minfo.moduleinfos_apply(scope int 
delegate(immutable(object.ModuleInfo*)))
0x7FF7A3082637 in int object.ModuleInfo.opApply(scope int 
delegate(object.ModuleInfo*))

0x7FF7A307C005 in runModuleUnitTests
0x7FF7A3070B7D in void rt.dmain2._d_run_main(int, char**, 
extern (C) int function(char[][])*).runAll()
0x7FF7A3070ADF in void rt.dmain2._d_run_main(int, char**, 
extern (C) int function(char[][])*).tryExec(scope void delegate())

0x7FF7A30708DF in d_run_main
0x7FF7A306F9F2 in __entrypoint.main
0x7FF7A30BA0C5 in __scrt_common_main_seh 

Re: Improve "Improve Contract Syntax" DIP 1009

[Mark via Digitalmars-d]

On Saturday, 4 November 2017 at 15:38:42 UTC, Jonathan M Davis 
wrote:
On Saturday, November 04, 2017 15:27:39 Ola Fosheim Grøstad via 
Digitalmars- d wrote:
On Saturday, 4 November 2017 at 14:12:08 UTC, Adam D. Ruppe 
wrote:
> On Saturday, 4 November 2017 at 13:59:39 UTC, Jonathan M 
> Davis

>
> wrote:
>> [...]
>
> I think that sqrt example is just bad. Out contracts 
> shouldn't be testing specific values, but rather ranges or 
> nullness or other such things that arguably should be part 
> of the return type, but just don't fit in the type system 
> for whatever reason.


No, Jonathan is correct. The postcondition should be able to 
access values as they were stated in the precondition.


In principle, that would be nice, but in practice, it's not 
really feasible. In the general case, there's no way to save 
the state of the parameter at the beginning of the function 
call (you could with some types, but for many types, you 
couldn't). IIRC, it's been discussed quite a bit in the past, 
and there are just too many problems with it.


- Jonathan M Davis


Yeah, I can see some of the problems that would arise from that. 
I think out contracts can work well for @safe strongly pure 
functions, but IIRC most functions in Phobos aren't strongly 
pure. Too bad. :(

Re: Improve "Improve Contract Syntax" DIP 1009

[Mark via Digitalmars-d]

On Saturday, 4 November 2017 at 06:08:22 UTC, Jonathan M Davis 
wrote:
And even if you did have access to the input, some functions 
consume their input without any way to save it (e.g. an input 
range that isn't a forward range)


[...]

- Jonathan M Davis


True. I had (strongly) pure functions in my mind and I didn't 
realize that things don't work as smooth in the impure case.

Re: What are the unused but useful feature you know in D?

[bauss via Digitalmars-d]

On Saturday, 4 November 2017 at 13:27:29 UTC, rikki cattermole 
wrote:

On 04/11/2017 2:14 PM, jmh530 wrote:

[...]


Okay so:

A signature when it is initiated is aware of the implementation 
it is referencing. Allowing it to change how it behaves for 
compatibility reasons.


An interface is designed so that a class/interface must know of 
the interface to inherit from.


While signatures can and probably will inherit from others, 
this is not how it is used unlike with interfaces. Because this 
is a massive change in how we view them and their usage, 
extending interfaces is not appropriate. Luckily an already 
existing concept exists in the literature which does solve most 
of the goals and that is signatures from the ML family.


I will make a mental note to rewrite that section.


It reminds a lot of traits in Rust.

https://doc.rust-lang.org/1.8.0/book/traits.html

Re: Improve "Improve Contract Syntax" DIP 1009

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 4 November 2017 at 15:27:39 UTC, Ola Fosheim Grøstad 
wrote:
No, Jonathan is correct. The postcondition should be able to 
access values as they were stated in the precondition.


Yes, they should be able to access values, but D's limitations on 
this doesn't make them useless or replaced by unittests. They do 
a different job than unittests.

[Issue 17962] dirEntries now truncates Unicode file names

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

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

--- Comment #2 from Vladimir Panteleev  ---
Heh. I predicted bugs like this would eventually happen years ago during the
big autodecoding debates.

Auto-decoding must die.

--

[Issue 6820] etc.c.curl missing const

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

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

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

   What|Removed |Added

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

--

[Issue 6820] etc.c.curl missing const

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

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

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

https://github.com/dlang/phobos/commit/a516b51d0e44316f6371a3cd78bd3133a035e99b
Fix Issue 6820 - etc.c.curl missing const

https://github.com/dlang/phobos/commit/25a6420e2bc277c75c934e14adfdf5951797e1d8
Merge pull request #5843 from Darredevil/issue-6820-curl-missing-const

Fix Issue 6820 - etc.c.curl missing const
merged-on-behalf-of: Vladimir Panteleev 

--

Re: Improve "Improve Contract Syntax" DIP 1009

[H. S. Teoh via Digitalmars-d]

On Sat, Nov 04, 2017 at 09:38:42AM -0600, Jonathan M Davis via Digitalmars-d 
wrote:
> On Saturday, November 04, 2017 15:27:39 Ola Fosheim Grøstad via Digitalmars-
> d wrote:
> > On Saturday, 4 November 2017 at 14:12:08 UTC, Adam D. Ruppe wrote:
> > > On Saturday, 4 November 2017 at 13:59:39 UTC, Jonathan M Davis
> > >
> > > wrote:
> > >> I'm very much of the opinion that proper unit tests pretty
> > >> much eliminate the need for out contracts.
> > >
> > > I think that sqrt example is just bad. Out contracts shouldn't
> > > be testing specific values, but rather ranges or nullness or
> > > other such things that arguably should be part of the return
> > > type, but just don't fit in the type system for whatever reason.
> >
> > No, Jonathan is correct. The postcondition should be able to
> > access values as they were stated in the precondition.
> 
> In principle, that would be nice, but in practice, it's not really
> feasible.  In the general case, there's no way to save the state of
> the parameter at the beginning of the function call (you could with
> some types, but for many types, you couldn't). IIRC, it's been
> discussed quite a bit in the past, and there are just too many
> problems with it.
[...]

This isn't as bad as it sounds. If you really cared for out-contracts
being able to access the original state of the parameters, just make the
parameters const.  In the cases where you can't make them const,
out-contracts are probably impractical anyway -- independently of how D
implements them, if your function is going to mutate parameters then the
only way the out-contract would work is if a copy of the parameters were
made.  But if you're already going to do that, might as well just make
the parameters const and do the copy inside the function body.

But as Adam said, out-contracts aren't really intended for semantic
enforcement, but they are more like extensions of the type system. E.g.,
asserting that a returned pointer is never null, or that a returned
value is never negative, or stays within some range of values, etc..
Basically, stuff the caller can assume about the return value as far as
the set of possible values is concerned.  For most non-trivial
functions, semantic enforcement requires you to basically reimplement
the function body, which is kinda pointless.  If you want semantic
enforcement, that's what unittests are for.


T

-- 
Caffeine underflow. Brain dumped.

Re: Any book recommendation for writing a compiler?

[Basile B. via Digitalmars-d-learn]

On Thursday, 2 November 2017 at 14:24:01 UTC, Basile B. wrote:
On Wednesday, 1 November 2017 at 20:53:44 UTC, Dr. Assembly 
wrote:
Hey guys, if I were to get into dmd's source code to play a 
little bit (just for fun, no commercial use at all), which 
books/resources do you recommend to start out?


You don't need to read books to write a compiler, a bit of 
theory from "here or there" will be enough, particularly if you 
start from scratch, there's almost no chance that you ever 
touch the more edgy things (something like theory of types 
maybe ).


A few ones written in D (sorted by URL length):

- https://github.com/dlang/dmd
- https://github.com/BBasile/yatol
- https://github.com/higgsjs/Higgs
- https://github.com/VoltLang/Volta
- https://github.com/beast-lang/beast-dragon

Otherwise a subreddit that's not been quoted yet:

- https://www.reddit.com/r/ProgrammingLanguages/ and their 
homepage listing a few projects from people who have started 
"the journey": http://www.proglangdesign.net/


Dr Assembly what i mean can be illustrated by this:

You see this https://github.com/matijapretnar/eff ?
http://www.eff-lang.org/ ?

People who say that after reading the dragon book, you will 
program your own programming language are lying.

Re: Improve "Improve Contract Syntax" DIP 1009

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 4 November 2017 at 15:38:42 UTC, Jonathan M Davis 
wrote:
In principle, that would be nice, but in practice, it's not 
really feasible. In the general case, there's no way to save 
the state of the parameter at the beginning of the function 
call (you could with some types, but for many types, you 
couldn't). IIRC, it's been discussed quite a bit in the past, 
and there are just too many problems with it.


It is obviously possible for a language that has been designed 
for contracts. Whether it is practical is a matter of 
optimization in my view…


Anyway, without having such a focus it makes little sense to say 
that a language supports programming by contracts or pre/post 
conditions. It is more of a syntactical construct in D. Although 
class invariants are still useful in debugging.


C++ is getting pre/post conditions I think. Not sure if it will 
be a plain syntactical construct like in D or something more 
advanced.

Re: Improve "Improve Contract Syntax" DIP 1009

[Jonathan M Davis via Digitalmars-d]

On Saturday, November 04, 2017 15:27:39 Ola Fosheim Grøstad via Digitalmars-
d wrote:
> On Saturday, 4 November 2017 at 14:12:08 UTC, Adam D. Ruppe wrote:
> > On Saturday, 4 November 2017 at 13:59:39 UTC, Jonathan M Davis
> >
> > wrote:
> >> I'm very much of the opinion that proper unit tests pretty
> >> much eliminate the need for out contracts.
> >
> > I think that sqrt example is just bad. Out contracts shouldn't
> > be testing specific values, but rather ranges or nullness or
> > other such things that arguably should be part of the return
> > type, but just don't fit in the type system for whatever reason.
>
> No, Jonathan is correct. The postcondition should be able to
> access values as they were stated in the precondition.

In principle, that would be nice, but in practice, it's not really feasible.
In the general case, there's no way to save the state of the parameter at
the beginning of the function call (you could with some types, but for many
types, you couldn't). IIRC, it's been discussed quite a bit in the past, and
there are just too many problems with it.

- Jonathan M Davis

Re: Improve "Improve Contract Syntax" DIP 1009

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 4 November 2017 at 14:12:08 UTC, Adam D. Ruppe wrote:
On Saturday, 4 November 2017 at 13:59:39 UTC, Jonathan M Davis 
wrote:
I'm very much of the opinion that proper unit tests pretty 
much eliminate the need for out contracts.


I think that sqrt example is just bad. Out contracts shouldn't 
be testing specific values, but rather ranges or nullness or 
other such things that arguably should be part of the return 
type, but just don't fit in the type system for whatever reason.


No, Jonathan is correct. The postcondition should be able to 
access values as they were stated in the precondition.

Re: Improve "Improve Contract Syntax" DIP 1009

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 4 November 2017 at 13:59:39 UTC, Jonathan M Davis 
wrote:
I'm very much of the opinion that proper unit tests pretty much 
eliminate the need for out contracts.


I think that sqrt example is just bad. Out contracts shouldn't be 
testing specific values, but rather ranges or nullness or other 
such things that arguably should be part of the return type, but 
just don't fit in the type system for whatever reason.


Consider this:

class A {
A clone()
out(result) { assert(result !is null); }
body {
return new A();
}
}
class B : A {
override B clone() {
return new B();
}
}

void main() {
A a = new B();
A c = a.clone();
}


The `clone` method defined in the base class arguably out to 
return a NotNull!A, encoding that contract in the type, but we 
can't really do that with D without breaking the inheritance - 
where B is statically defined to return B too, since NotNull!B 
isn't covariant to NotNull!A the way B is covariant to A. (At 
least not with any techniques I can think of at this time.)


So you can't encode it in the return type... but you can encode 
it in the out contract for a runtime check.


It also clearly documents that the subclasses must not return 
null (and can add their own restrictions to further subclasses). 
One problem I have with some of D's contracts right now is that 
they are convoluted, ugly code that make for passable internal 
unit tests, you can't reasonably display as documentation as part 
of the interface.


But regardless, I say you should not think of out as tests. Think 
of it as type system extensions.

Re: Improve "Improve Contract Syntax" DIP 1009

[Jonathan M Davis via Digitalmars-d]

On Saturday, November 04, 2017 13:02:45 Nick Treleaven via Digitalmars-d 
wrote:
> On Saturday, 4 November 2017 at 06:08:22 UTC, Jonathan M Davis
>
> wrote:
> > Heck, take a really simply one like sqrt. All you have to check
> > in the out contract is the return value. You have no idea what
> > was passed in. So, how would you write an out contract
> > verifying that you got the correct number? If you also had
> > access to the input, then you could do the reverse operation by
> > squaring the result to see if it matched the input (assuming of
> > course that floating point rounding errors don't make that not
> > work), but you don't have access to the input.
>
> I don't think I've ever written an out contract, so I am inclined
> to agree with you. However, there is a sqrt example for integers
> in the official docs, it does access its input:
>
> https://dlang.org/spec/contracts.html#pre_post_contracts
>
> long square_root(long x)
> in
> {
>  assert(x >= 0);
> }
> out (result)
> {
>  assert((result * result) <= x && (result+1) * (result+1) > x);
> }

I was sure that you couldn't do that, but apparently, I was wrong. However,
it does rely on the parameter not having been mutated. e.g.

void main()
{
foo(42);
}

void foo(int x)
out
{
import std.stdio;
writeln(x);
}
body
{
x = 7;
}

prints 7.

Being able to access the input of a function that doesn't mutate its input
does increase the usefulness of out contracts, but there are still plenty of
functions where you can't determine whether the output is correct just by
looking at the input without reimplementing the function in the out contract
to make sure that the results match (e.g. as I pointed out before, a hash
function isn't reversible, which means that you can't just verify the hash
for arbitrary input).

I'm very much of the opinion that proper unit tests pretty much eliminate
the need for out contracts.

- Jonathan M Davis

Re: What are the unused but useful feature you know in D?

[rikki cattermole via Digitalmars-d]

On 04/11/2017 2:14 PM, jmh530 wrote:

On Saturday, 4 November 2017 at 12:20:37 UTC, rikki cattermole wrote:


Like signatures which I'm working on!

https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md


The first example kind of reminds me of what I was trying to do with 
isSubTypeOf [1]. If you know that any function you can call on T can 
also be called on U, then it has the same effect. That being said, I'm 
not sure I really understand what you mean in the whole "Why not extend 
interfaces" part.



[1] https://github.com/dlang/phobos/pull/5700


Okay so:

A signature when it is initiated is aware of the implementation it is 
referencing. Allowing it to change how it behaves for compatibility reasons.


An interface is designed so that a class/interface must know of the 
interface to inherit from.


While signatures can and probably will inherit from others, this is not 
how it is used unlike with interfaces. Because this is a massive change 
in how we view them and their usage, extending interfaces is not 
appropriate. Luckily an already existing concept exists in the 
literature which does solve most of the goals and that is signatures 
from the ML family.


I will make a mental note to rewrite that section.

Re: What are the unused but useful feature you know in D?

[jmh530 via Digitalmars-d]

On Saturday, 4 November 2017 at 12:20:37 UTC, rikki cattermole 
wrote:


Like signatures which I'm working on!

https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md


The first example kind of reminds me of what I was trying to do 
with isSubTypeOf [1]. If you know that any function you can call 
on T can also be called on U, then it has the same effect. That 
being said, I'm not sure I really understand what you mean in the 
whole "Why not extend interfaces" part.



[1] https://github.com/dlang/phobos/pull/5700

Re: Improve "Improve Contract Syntax" DIP 1009

[Nick Treleaven via Digitalmars-d]

On Saturday, 4 November 2017 at 06:08:22 UTC, Jonathan M Davis 
wrote:
Heck, take a really simply one like sqrt. All you have to check 
in the out contract is the return value. You have no idea what 
was passed in. So, how would you write an out contract 
verifying that you got the correct number? If you also had 
access to the input, then you could do the reverse operation by 
squaring the result to see if it matched the input (assuming of 
course that floating point rounding errors don't make that not 
work), but you don't have access to the input.


I don't think I've ever written an out contract, so I am inclined 
to agree with you. However, there is a sqrt example for integers 
in the official docs, it does access its input:


https://dlang.org/spec/contracts.html#pre_post_contracts

long square_root(long x)
in
{
assert(x >= 0);
}
out (result)
{
assert((result * result) <= x && (result+1) * (result+1) > x);
}

Re: What are the unused but useful feature you know in D?

[rikki cattermole via Digitalmars-d]

On 04/11/2017 1:16 PM, Eljay wrote:

On Monday, 26 June 2017 at 00:38:21 UTC, Mike wrote:
IMO, part of the problem is that D has the wrong defaults (e.g. 
`immutable` by default, `@safe` by default, `final` by default, 
etc...), so users have to opt in to these things when they should 
really only be opting out of them.  Unfortunately, changing this would 
be disruptive and will probably never happen without a fork.


If/when D 3.0 happens, as a breaking change, hopefully the defaults can 
be made to be better right defaults.  (D 1.x to D 2.x had *cough* some 
breaking changes.)


I also hope that for D 3.0, both Walter and Andrei play with F# or OCaml 
for a while.  There's a lot of Good Things in F# and OCaml that perhaps 
could be considered for D 3.0.


Like signatures which I'm working on!

https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md

Re: What are the unused but useful feature you know in D?

[Eljay via Digitalmars-d]

On Monday, 26 June 2017 at 00:38:21 UTC, Mike wrote:
IMO, part of the problem is that D has the wrong defaults (e.g. 
`immutable` by default, `@safe` by default, `final` by default, 
etc...), so users have to opt in to these things when they 
should really only be opting out of them.  Unfortunately, 
changing this would be disruptive and will probably never 
happen without a fork.


If/when D 3.0 happens, as a breaking change, hopefully the 
defaults can be made to be better right defaults.  (D 1.x to D 
2.x had *cough* some breaking changes.)


I also hope that for D 3.0, both Walter and Andrei play with F# 
or OCaml for a while.  There's a lot of Good Things in F# and 
OCaml that perhaps could be considered for D 3.0.

Re: Reorganization and list of D libraries (300+)

[FreeSlave via Digitalmars-d-announce]

On Saturday, 4 November 2017 at 00:12:19 UTC, Fra Mecca wrote:


https://github.com/FraMecca/D_Libraries_Registry



I checked README.md in this repo. Not sure why my nick is used in 
place of name of lnk library.

Also inilike has nothing to do with argv.

Re: Anticipate the usage of Visual Studio 2017 Developer Command Prompt?

[Rainer Schuetze via Digitalmars-d]

On 04.11.2017 12:16, Andre Pany wrote:

On Saturday, 4 November 2017 at 09:39:02 UTC, Rainer Schuetze wrote:



On 03.11.2017 21:51, Andre Pany wrote:

On Friday, 3 November 2017 at 11:52:10 UTC, Andre Pany wrote:

[...]


I have an idea which solves several problems.

Current state:
The dmd windows archive has a folder "bin" with a 32 bit dmd compiler 
which is able to create x86 and x86_64 applications. By default the 
dmd compiler creates 32 bit applications using the optlink link.exe 
contained also in this folder.


Idea:
Within the folder "bin64" the 64 bit dmd compiler could be shipped 
within the dmd windows archive. I assume the 64 bit dmd compiler is 
able to create x86 and x86_64 applications. In folder "bin64" no 
optlink link.exe should be available.
The usage of either the microsoft link.exe or another linker (maybe 
the one from LDC) is anticipated. The 64 bit dmd compiler could have 
the option -m64 set as default.


The user can decide whether he wants to use the "stable" dmd compiler 
with usage of optlink or he want to use the 64 bit dmd compiler which 
is open for other linkers than optlink by simply setting his path 
variable to bin or to bin64.


Using this approach:
- DMD compiler is working out of the box for the VS Developer Command 
Prompt - no need to rename the optlink link.exe
- A 64 bit dmd compiler is shipped which solves issues on large D 
projects


What do you think?

Kind regards
André


Finding the wrong linker seems to happen quite often, but I wonder why:

sc.ini usually has the absolute path to the linker set via the LINKCMD 
variable, so finding the correct executable should not be a problem if 
the installer has set things up correctly. If extracted from the zip 
there are also defaults that might not work but should not find the 
wrong linker.


Is it the result of trying to fix the sc.ini manually?

The problem with overriding the LIB environment variable is that 
optlink and the MS linker both use it, but stumble over the libraries 
for the other linker due to different file formats.


I think the best option forward is to not rely on the installer to 
find the correct setup at installation time, but detect the available 
linker and its environment before invoking it:


- if the environment is already set up via vcvarsall, i.e. 
VCINSTALLDIR set, use that to call the approriate linker


- if VCINSTALLDIR is not set, use the registry to find the best fit, 
i.e. highest available VS version


- some way to override the automatism should be available, too.

We might also be able to provide some fallback if no VS installation 
is found, based on the LLVM linker, but with limited C 
runtime/platform library support.


I would say, by executing vcvarsall the user showed his intention to use 
the coff libraries and the Microsoft linker for the actual console 
session instead of the omf libraries.


I see a disadvantage by detecting the vc installation directory / lib 
directories. All paths are specific for the vs version. If there is x 
new vs version we are always behind.


But Microsoft has a solution for this problem. Vcvarsall sets the linker 
as first element of the path variable and the lib env variable points to 
the right folder. This solution will work for old vs version and any 
upcoming version.


That's what I wrote above, too: the settings from vcvarsall should take 
precedence. The library path for the phobos library must be added, though.




I set linkcmd to "link.exe". Unfortunately the link.exe in the dmd bin 
folder has precedence over the path env variable.


This is caused by CreateProcess looking in the directory of the calling 
process first. This could be avoided in dmd by searching the PATH 
folders explicitly before invoking the linker.

Re: private keyword dont appear to do anything

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, November 04, 2017 11:03:52 Paolo Invernizzi via Digitalmars-d-
learn wrote:
> On Friday, 3 November 2017 at 23:32:52 UTC, H. S. Teoh wrote:
> > [...]
>
> What's wrong with the introduction of another visibility
> attribute that behave like the C++ private?
>
> Just curious...

Well, if a good enough DIP could be written to convince Walter and Andrei,
then I'm sure it could be added, but it probably isn't worth it. If you
really want that level of separation, then you can always just put your
class or struct in its own module, and in practice, the fact that other
stuff in a module _could_ access the private members of a struct or class
doesn't tend to be a problem - and adding yet another access modifier does
make the language and its implementation that much more complicated. It also
might break existing code that uses type introspection and has logic based
on what access level a symbol has.

Ultimately, while I don't think that there's any technical reason why we
couldn't make such a change, I think that it's trying to solve a problem
that doesn't really exist, and for the change to be made, a solid argument
would have to be made as to why it's a real problem that needs fixing and
why the proposed solution is the right one.

- Jonathan M Davis

Re: private keyword dont appear to do anything

[Basile B. via Digitalmars-d-learn]

On Friday, 3 November 2017 at 12:43:15 UTC, rikki cattermole 
wrote:
Visibility modifiers like private, and public are to the module 
not the scope.


"Symbols with private visibility can only be accessed from 
within the same module."


This is how module based languages work,


Pascal has "strict private". I like it because you can enforce 
the usage of setters and getters within the same module.


http://wiki.freepascal.org/User_Changes_3.0#.22strict_protected.22_visibility_modifier

To have strict privacy in D we have to isolate the "strict" thing 
in a file.

Re: Reorganization and list of D libraries (300+)

[Jacob Carlborg via Digitalmars-d-announce]

On 2017-11-04 01:12, Fra Mecca wrote:

Hi all.

Lurking in this forum I had the feeling that lots of D developers tend 
to rewrite lots of code that could be found in libraries. This is not 
bad per se but I thought that one of the reason could have been the 
current process of library discovery.


For this reason I have edited a list of libraries that could aid in this 
process.


I also considered that the following features could be of importance to 
you:

- License
- Garbage collector
- last modification (automated)

The list is of course not complete and I could not test all of the 
libraries I included.


I welcome you to modify it, open PRs or issues on github.

https://github.com/FraMecca/D_Libraries_Registry

I hope it could lead to a better ecosystem for the whole D community.


DWT is using the EPL, Eclipse Public License, license.
I'm missing the ddb [1] and mysql-native [2] database libraries.
There are many list like this for other languages, they're usually 
called "awesome-" where  is the language.


[1] https://github.com/pszturmaj/ddb
[2] https://github.com/mysql-d/mysql-native

--
/Jacob Carlborg

Re: Anticipate the usage of Visual Studio 2017 Developer Command Prompt?

[Andre Pany via Digitalmars-d]

On Saturday, 4 November 2017 at 09:39:02 UTC, Rainer Schuetze 
wrote:



On 03.11.2017 21:51, Andre Pany wrote:

On Friday, 3 November 2017 at 11:52:10 UTC, Andre Pany wrote:

[...]


I have an idea which solves several problems.

Current state:
The dmd windows archive has a folder "bin" with a 32 bit dmd 
compiler which is able to create x86 and x86_64 applications. 
By default the dmd compiler creates 32 bit applications using 
the optlink link.exe contained also in this folder.


Idea:
Within the folder "bin64" the 64 bit dmd compiler could be 
shipped within the dmd windows archive. I assume the 64 bit 
dmd compiler is able to create x86 and x86_64 applications. In 
folder "bin64" no optlink link.exe should be available.
The usage of either the microsoft link.exe or another linker 
(maybe the one from LDC) is anticipated. The 64 bit dmd 
compiler could have the option -m64 set as default.


The user can decide whether he wants to use the "stable" dmd 
compiler with usage of optlink or he want to use the 64 bit 
dmd compiler which is open for other linkers than optlink by 
simply setting his path variable to bin or to bin64.


Using this approach:
- DMD compiler is working out of the box for the VS Developer 
Command Prompt - no need to rename the optlink link.exe
- A 64 bit dmd compiler is shipped which solves issues on 
large D projects


What do you think?

Kind regards
André


Finding the wrong linker seems to happen quite often, but I 
wonder why:


sc.ini usually has the absolute path to the linker set via the 
LINKCMD variable, so finding the correct executable should not 
be a problem if the installer has set things up correctly. If 
extracted from the zip there are also defaults that might not 
work but should not find the wrong linker.


Is it the result of trying to fix the sc.ini manually?

The problem with overriding the LIB environment variable is 
that optlink and the MS linker both use it, but stumble over 
the libraries for the other linker due to different file 
formats.


I think the best option forward is to not rely on the installer 
to find the correct setup at installation time, but detect the 
available linker and its environment before invoking it:


- if the environment is already set up via vcvarsall, i.e. 
VCINSTALLDIR set, use that to call the approriate linker


- if VCINSTALLDIR is not set, use the registry to find the best 
fit, i.e. highest available VS version


- some way to override the automatism should be available, too.

We might also be able to provide some fallback if no VS 
installation is found, based on the LLVM linker, but with 
limited C runtime/platform library support.


I would say, by executing vcvarsall the user showed his intention 
to use the coff libraries and the Microsoft linker for the actual 
console session instead of the omf libraries.


I see a disadvantage by detecting the vc installation directory / 
lib directories. All paths are specific for the vs version. If 
there is x new vs version we are always behind.


But Microsoft has a solution for this problem. Vcvarsall sets the 
linker as first element of the path variable and the lib env 
variable points to the right folder. This solution will work for 
old vs version and any upcoming version.


I set linkcmd to "link.exe". Unfortunately the link.exe in the 
dmd bin folder has precedence over the path env variable.


Kind regards
Andre

Re: private keyword dont appear to do anything

[Paolo Invernizzi via Digitalmars-d-learn]

On Friday, 3 November 2017 at 23:32:52 UTC, H. S. Teoh wrote:

[...]


What's wrong with the introduction of another visibility 
attribute that behave like the C++ private?


Just curious...

---
Paolo

Re: What is the FreeBSD situation?

[rjframe via Digitalmars-d]

On Sat, 04 Nov 2017 09:51:12 +, codephantom wrote:

>> It might also make sense, that if a source code file does not contain a
>> module statement, then it should not be treated as a module, and the
>> compiler should look to the import statements instead of implicitly
>> making in a module.
>>
> 
> I should add one more thing.
> 
> Both Andrei's book (The D Programming Language), and Ali's book
> (Programming in D), provide the usual 'hello world' thing, at the
> beginning. In both cases, the 'module' statement is not part of that
> example. That is consistent with other 'hello world' I've seen in D. All
> the other code in both book also consistently leaves out the 'module'
> statement.
> 
> My point being, given that "D is serious about modularity" (as Andrei
> put it in his book), then I think all 'hello world' examples should
> include the 'module' specifier as well, and explain why it's there too.
> I think that would really aid those who are new to the language..

Many people seem to leave the module statement out of their main.d/app.d 
files; I think it's a way to say "this is the main thing - don't import it 
from somewhere else." Basically, it's easier to act like that code isn't 
in a module than it is to have the compiler support code not in a module.

Re: What is the FreeBSD situation?

[codephantom via Digitalmars-d]

On Saturday, 4 November 2017 at 08:46:37 UTC, Jonathan M Davis 
wrote:
Well, the modules need names. So, either, the compiler is going 
to have to pick a name for you, or you're going to have to give 
it one.


ok..just one more ... I can't help myself..

I know that D does not have a 'global namespace', but what if did?

Then, if a file does not declare its own module namespace (like 
none of my 109 snippets) then what's the big deal with having the 
compiler just use that (statically known) global name space.


I wonder what the implication would be, if any.

oh..and it would save a few keystrokes...which seems to be a main 
focus of numerous DIPs ;-)

Re: What is the FreeBSD situation?

[Jonathan M Davis via Digitalmars-d]

On Saturday, November 04, 2017 09:34:05 codephantom via Digitalmars-d wrote:
> On Saturday, 4 November 2017 at 08:46:37 UTC, Jonathan M Davis
>
> wrote:
> > Well, the modules need names. So, either, the compiler is going
> > to have to pick a name for you, or you're going to have to give
> > it one. In general though, D was designed with the idea that
> > modules would match files and packages would match directories
> > - and that the names on disk would match the ones in the file.
> > Overall, things are much simpler that way. On some level, you
> > can get around that by giving module names that don't match the
> > file names, but in general, you're just begging for trouble if
> > you don't make your file names and module names match (at least
> > some stuff is going to be looking for modules by looking at the
> > file system for them with the assumption that the package names
> > match folders and the module names match files). So, in the
> > long run, you'll just have fewer problems if you make your file
> > names and module names match.
> >
> > - Jonathan M Davis
>
> Yes. All that makes complete sense I guess.
>
> It might also make sense, that if a source code file does not
> contain a module statement, then it should not be treated as a
> module, and the compiler should look to the import statements
> instead of implicitly making in a module.

The language has no concept of any D code not being in a module. Not only
would adding such a concept complicate things, but it wouldn't help real
world programs. Having the module name infered from the file name was a
simple solution to the problem and usually doesn't cause problems (at least
as long as you're just dealing with toy programs).

Personally, I think that we would have been better off just requiring the
module statements (especially since it doesn't work to have modules in
packages without the module statements), but I doubt that that change would
be accepted at this point, particularly since it wouldn't matter for much
other than toy programs. Mostly all it would do is force folks to use module
statements up front when learning the language instead of trying to go
without like some do and then inevitably hitting issues when they start to
use packages. And that has value, but I doubt that it would be enough of an
argument to get such a change made.

- Jonathan M Davis

Re: What is the FreeBSD situation?

[codephantom via Digitalmars-d]

On Saturday, 4 November 2017 at 09:34:05 UTC, codephantom wrote:

Yes. All that makes complete sense I guess.

It might also make sense, that if a source code file does not 
contain a module statement, then it should not be treated as a 
module, and the compiler should look to the import statements 
instead of implicitly making in a module.


btw. That bug in gdc, which appear to do just that, is a nice 
bug ;-)


I should add one more thing.

Both Andrei's book (The D Programming Language), and Ali's book 
(Programming in D), provide the usual 'hello world' thing, at the 
beginning. In both cases, the 'module' statement is not part of 
that example. That is consistent with other 'hello world' I've 
seen in D. All the other code in both book also consistently 
leaves out the 'module' statement.


My point being, given that "D is serious about modularity" (as 
Andrei put it in his book), then I think all 'hello world' 
examples should include the 'module' specifier as well, and 
explain why it's there too. I think that would really aid those 
who are new to the language..

[Issue 15831] IFTI voldemort type exploding bloat

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

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

calex  changed:

   What|Removed |Added

 CC||calex+bugzilla-mail@aristow
   ||eb.net

--

Re: Anticipate the usage of Visual Studio 2017 Developer Command Prompt?

[Rainer Schuetze via Digitalmars-d]

On 03.11.2017 21:51, Andre Pany wrote:

On Friday, 3 November 2017 at 11:52:10 UTC, Andre Pany wrote:

Hi,

Visual Studio has a batch file which sets all needed environment 
variables for the Microsoft linker (LIB environment variables points 
to all necessary folders). Even the folder containing the link.exe for 
the specified architecture (x86, amd64) is added to the path variable 
as first path.



vsdevcmd -arch=amd64


As the sc.ini targets the windows development (visuals studio) after 
calling the developer command prompt, dmd should be able to compile 
-m32mscoff, -m64 out of the box without the need to change anything 
within sc.ini.


There is even a comment in sc.ini which points in this direction:
; Add the library subdirectories of all VC and Windows SDK versions so 
things

; just work for users using dmd from the VS Command Prompt

Unfortunately it does not work for various reasons:
- optlink has the filename link.exe which conflicts with the filename 
of the microsoft linker
- from my investigation I have the assumption that even if an 
environment variable LIB exists, the value is discarded by the sc.ini 
logic. I tried hard, but it seems existing environment variable LIB 
cannot be used in sc.ini


If you can use the windows installer, it will set the right values in 
sc.ini. But there are scenarios in which you cannot use the windows 
installer but have to use the dmd zip archive (build infrastructure 
scripts).


In my scenario it seems the only possibility is to adapt my build 
infrastructure scripts to:

- extract dmd archive
- delete link.exe (optlink)
- modify the sc.ini

That is a solution for my case, but my gut feeling is, it should be 
solved in general

to ease the usage of the microsoft linker.

I thought it was planned to rename the optlink link.exe to optlink.exe?

Kind regards
André


I have an idea which solves several problems.

Current state:
The dmd windows archive has a folder "bin" with a 32 bit dmd compiler 
which is able to create x86 and x86_64 applications. By default the dmd 
compiler creates 32 bit applications using the optlink link.exe 
contained also in this folder.


Idea:
Within the folder "bin64" the 64 bit dmd compiler could be shipped 
within the dmd windows archive. I assume the 64 bit dmd compiler is able 
to create x86 and x86_64 applications. In folder "bin64" no optlink 
link.exe should be available.
The usage of either the microsoft link.exe or another linker (maybe the 
one from LDC) is anticipated. The 64 bit dmd compiler could have the 
option -m64 set as default.


The user can decide whether he wants to use the "stable" dmd compiler 
with usage of optlink or he want to use the 64 bit dmd compiler which is 
open for other linkers than optlink by simply setting his path variable 
to bin or to bin64.


Using this approach:
- DMD compiler is working out of the box for the VS Developer Command 
Prompt - no need to rename the optlink link.exe

- A 64 bit dmd compiler is shipped which solves issues on large D projects

What do you think?

Kind regards
André


Finding the wrong linker seems to happen quite often, but I wonder why:

sc.ini usually has the absolute path to the linker set via the LINKCMD 
variable, so finding the correct executable should not be a problem if 
the installer has set things up correctly. If extracted from the zip 
there are also defaults that might not work but should not find the 
wrong linker.


Is it the result of trying to fix the sc.ini manually?

The problem with overriding the LIB environment variable is that optlink 
and the MS linker both use it, but stumble over the libraries for the 
other linker due to different file formats.


I think the best option forward is to not rely on the installer to find 
the correct setup at installation time, but detect the available linker 
and its environment before invoking it:


- if the environment is already set up via vcvarsall, i.e. VCINSTALLDIR 
set, use that to call the approriate linker


- if VCINSTALLDIR is not set, use the registry to find the best fit, 
i.e. highest available VS version


- some way to override the automatism should be available, too.

We might also be able to provide some fallback if no VS installation is 
found, based on the LLVM linker, but with limited C runtime/platform 
library support.

Re: What is the FreeBSD situation?

[codephantom via Digitalmars-d]

On Saturday, 4 November 2017 at 08:46:37 UTC, Jonathan M Davis 
wrote:
Well, the modules need names. So, either, the compiler is going 
to have to pick a name for you, or you're going to have to give 
it one. In general though, D was designed with the idea that 
modules would match files and packages would match directories 
- and that the names on disk would match the ones in the file. 
Overall, things are much simpler that way. On some level, you 
can get around that by giving module names that don't match the 
file names, but in general, you're just begging for trouble if 
you don't make your file names and module names match (at least 
some stuff is going to be looking for modules by looking at the 
file system for them with the assumption that the package names 
match folders and the module names match files). So, in the 
long run, you'll just have fewer problems if you make your file 
names and module names match.


- Jonathan M Davis


Yes. All that makes complete sense I guess.

It might also make sense, that if a source code file does not 
contain a module statement, then it should not be treated as a 
module, and the compiler should look to the import statements 
instead of implicitly making in a module.


btw. That bug in gdc, which appear to do just that, is a nice bug 
;-)

Re: Release D 2.077.0

[Dmitry Olshansky via Digitalmars-d-announce]

On Saturday, 4 November 2017 at 08:19:17 UTC, Walter Bright wrote:

On 11/3/2017 1:20 PM, Dmitry Olshansky wrote:
Sadly array ops would be insufficient for said problem. It 
wasn’t a direct element wise expression.


That sounds like that might be why it failed vectorization :-)


As I recall it there were no trivial loops there. Usually these 2 
magicians could make compiler eat it in a few hours of shuffling 
the code. They vectorized about half a dozen loops that way.


The last one took 10 times more then the others taken together ;)



If you recall the expression, it would be interesting to see it.


Even if I had it saved somewhere the place was NDA-ed to death. I 
traded 3 months of intellectual work (and property) for a modest 
amount of money. Interesting experience but no illusions about 
R centers anymore.

Re: LDC 1.5.0

[Joakim via Digitalmars-d-announce]

On Saturday, 4 November 2017 at 08:44:12 UTC, codephantom wrote:

On Saturday, 4 November 2017 at 08:40:19 UTC, Joakim wrote:

It is fairly easy to compile ldc yourself:

https://wiki.dlang.org/Building_LDC_from_source


Have you tried those instructions on 'FreeBSD'?


Not those instructions maybe, but I wrote the first ports script 
for FreeBSD back in 2010, so I have built ldc there:


https://www.freshports.org/lang/ldc-devel


Have you ever had to deal with pkg conflicts in FreeBSD?

I have ;-(


Can't say that ever really hit me, not sure how it's relevant to 
building ldc either.

[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

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

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

--- Comment #3 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7284

--

Re: What is the FreeBSD situation?

[Rainer Schuetze via Digitalmars-d]

On 04.11.2017 09:30, Walter Bright wrote:

On 11/3/2017 5:29 AM, Rainer Schuetze wrote:
Note that dmd still runs on Windows XP, though it is not officially 
supported. You just need to be careful about using TLS variables on 
it :-(
to avoid spreading this false information: TLS in D works in 
dynamically loaded DLLs on WinXP since 2010.


The fact that we haven't officially tested that it works for years means 
be careful about attesting that it does work.


It is working in Visual D since that time.



Even simple DLL support in Windows keeps breaking because it is not part 
of the autotester test suite.


Agreed, they haven't been officially tested a lot in the past, but you 
have merged the PR to do that back in April: 
https://github.com/dlang/dmd/pull/6709

Re: What is the FreeBSD situation?

[Jonathan M Davis via Digitalmars-d]

On Saturday, November 04, 2017 01:30:12 Walter Bright via Digitalmars-d 
wrote:
> On 11/3/2017 5:29 AM, Rainer Schuetze wrote:
> >> Note that dmd still runs on Windows XP, though it is not officially
> >> supported. You just need to be careful about using TLS variables on it
> >> :-(
> >
> > to avoid spreading this false information: TLS in D works in dynamically
> > loaded DLLs on WinXP since 2010.
>
> The fact that we haven't officially tested that it works for years means
> be careful about attesting that it does work.
>
> Even simple DLL support in Windows keeps breaking because it is not part
> of the autotester test suite.

Just the other day, a fix for std.experimental.allocator that was supposed
to fix FreeBSD 10.x/11.x fixed 32-bit but broke 64-bit - and it had no
effect on FreeBSD 8.4 or whatever it is that's running on the main
autotester FreeBSD boxes. The problem was caught and fixed, but for any
given platform, unless we're running it as part of the autotester, or
someone runs the tests locally and reports any breakages that occur, it's
trivial for bugs to creep in, as annoying as that is.

As such, I don't think that the odds are good at all that running modern D
programs on Windows XP is going to work correctly in general. I don't expect
that it's completely broken, but I sure wouldn't trust it without running
the complete test suite in XP to verify whatever version of dmd, druntime,
and Phobos you're trying to use - and I think that we may even be using some
Windows API calls in Phobos which were introduced in Vista, since a lot of
improved API calls were added in Vista, and it's certainly the case that
_those_ won't work in XP.

I confess that I have little sympathy if D doesn't work in XP though given
that the fact that Microsoft doesn't support it anymore makes it completely
unsafe to run unless it's not connected to the Internet.

- Jonathan M Davis

Re: What is the FreeBSD situation?

[Jonathan M Davis via Digitalmars-d]

On Saturday, November 04, 2017 08:38:58 codephantom via Digitalmars-d wrote:
> On Saturday, 4 November 2017 at 08:17:44 UTC, Jonathan M Davis
>
> wrote:
> > Per the spec, if you don't give a module declaration, the name
> > of the module is the name of the file (minus the extension).
> > So, if you just give a module name (which you generally would
> > in any real program rather than a quick test program), then
> > it's not a problem - unless you give the module a name which
> > conflicts with something that you're trying to use.
>
> Thanks. I had actually read that spec, but forgot all about it.
>
> Having only used D for a month or so, I'm only writing snippets
> (107 so far), not actual programs.
>
> I actually had to edit the source code of my editor, so that when
> I create/save a .d file, if I happen to use hypens, then my
> editor will now automatically replace them with underscores
> (again, just because the way D deals with files).
>
> I think I'll do some more editing, and have my editor insert a
> default module name as well.
>
> Still, I don't like the spec. I would prefer that dmd did not
> implictly do stuff like that. Then I could regain the freedom to
> name my files however I wanted.

Well, the modules need names. So, either, the compiler is going to have to
pick a name for you, or you're going to have to give it one. In general
though, D was designed with the idea that modules would match files and
packages would match directories - and that the names on disk would match
the ones in the file. Overall, things are much simpler that way. On some
level, you can get around that by giving module names that don't match the
file names, but in general, you're just begging for trouble if you don't
make your file names and module names match (at least some stuff is going to
be looking for modules by looking at the file system for them with the
assumption that the package names match folders and the module names match
files). So, in the long run, you'll just have fewer problems if you make
your file names and module names match.

- Jonathan M Davis

Re: LDC 1.5.0

[Joakim via Digitalmars-d-announce]

On Saturday, 4 November 2017 at 02:43:35 UTC, codephantom wrote:

On Friday, 3 November 2017 at 17:17:04 UTC, kinke wrote:

Hi everyone,

on behalf of the LDC team, I'm glad to finally officially 
announce LDC 1.5. The highlights of this version in a nutshell:




Great stuff.

No binary release for FreeBSD though??

:-(


There were some in the recent past, last done for the 1.2 release 
and 1.3 beta1:


https://github.com/ldc-developers/ldc/releases

Unfortunately, almost nobody was downloading them:

http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc

Maybe FreeBSD users prefer using the package from ports, though 
it hasn't kept up:


https://www.freshports.org/lang/ldc/

It is fairly easy to compile ldc yourself:

https://wiki.dlang.org/Building_LDC_from_source

Re: LDC 1.5.0

[codephantom via Digitalmars-d-announce]

On Saturday, 4 November 2017 at 08:40:19 UTC, Joakim wrote:

It is fairly easy to compile ldc yourself:

https://wiki.dlang.org/Building_LDC_from_source


Have you tried those instructions on 'FreeBSD'?

Have you ever had to deal with pkg conflicts in FreeBSD?

I have ;-(

Re: What is the FreeBSD situation?

[codephantom via Digitalmars-d]

On Saturday, 4 November 2017 at 08:17:44 UTC, Jonathan M Davis 
wrote:
Per the spec, if you don't give a module declaration, the name 
of the module is the name of the file (minus the extension). 
So, if you just give a module name (which you generally would 
in any real program rather than a quick test program), then 
it's not a problem - unless you give the module a name which 
conflicts with something that you're trying to use.


Thanks. I had actually read that spec, but forgot all about it.

Having only used D for a month or so, I'm only writing snippets 
(107 so far), not actual programs.


I actually had to edit the source code of my editor, so that when 
I create/save a .d file, if I happen to use hypens, then my 
editor will now automatically replace them with underscores 
(again, just because the way D deals with files).


I think I'll do some more editing, and have my editor insert a 
default module name as well.


Still, I don't like the spec. I would prefer that dmd did not 
implictly do stuff like that. Then I could regain the freedom to 
name my files however I wanted.

Re: Proposal: Support for objects in switch statements

[angel via Digitalmars-d]

On Wednesday, 1 November 2017 at 01:16:32 UTC, solidstate1991 
wrote:
After I started to alter my graphics engine to use the multiple 
kinds of bitmaps (now using multiple language features, like 
templates and aliases) on one layer, I noticed that type 
detection of bitmap objects would be easier and better 
readable, if instead of:


if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
...
}else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...

I could easily use this:

switch(bitmapObject.classinfo){
case typeof(Bitmap4Bit):
...
case typeof(Bitmap8Bit):
}

On the other hand I cannot really think other uses for such 
language feature, maybe with structs.


The idea IS good, I am sure it has already happened to many.
May it be there are some technical problems with it ?

Re: What is the FreeBSD situation?

[Walter Bright via Digitalmars-d]

On 11/3/2017 5:29 AM, Rainer Schuetze wrote:
Note that dmd still runs on Windows XP, though it is not officially supported. 
You just need to be careful about using TLS variables on it :-(
to avoid spreading this false information: TLS in D works in dynamically loaded 
DLLs on WinXP since 2010.


The fact that we haven't officially tested that it works for years means be 
careful about attesting that it does work.


Even simple DLL support in Windows keeps breaking because it is not part of the 
autotester test suite.

Re: Note from a donor

[Joakim via Digitalmars-d]

On Saturday, 4 November 2017 at 02:33:35 UTC, Computermatronic 
wrote:

On Friday, 3 November 2017 at 18:26:54 UTC, Joakim wrote:

On Friday, 3 November 2017 at 18:08:54 UTC, 12345swordy wrote:

On Friday, 3 November 2017 at 17:25:26 UTC, Joakim wrote:


Most programmers will one day be coding on mobile devices, 
though I admit I'm in a small, early-adopting minority now:


http://bergie.iki.fi/blog/six-weeks-working-android/



A blog post is not evidence that the majority of programmers 
will be coding on mobile devices.


Yes, but it is evidence of what I said, that "I'm in a small, 
early-adopting minority now."  I don't know how you expect 
evidence for something that _will_ happen, it's a prediction 
I'm making, though based on current, rising trends like all 
those in this feed:


https://mobile.twitter.com/termux


Can we please get back on topic please?


Yes, it is as simple as changing the topic up top back to the 
original, like I have now and you didn't, and discussing 
something else.  You don't have to read messages that were marked 
as OT, like mine were, nobody's making you.


Whether or not windows is 'dying' is irrelevant, since it is 
not going to die out as a development platform for at least the 
next 5 years.


I, like many other windows users, want to be able to compile 
64bit binaries in windows, without having to download and 
install the bloated and time consuming to download and install 
Visual Studio.


I do most of my programming in Sublime Text, and frequently 
re-install windows. This may not be the case for many windows 
users of D, but clearly many windows users of D would like to 
be able to compile x64 out of the box.


I was intrigued by someone saying in this thread that Go supports 
Win64 COFF out of the box, so I just tried it out in wine and 
indeed it works with their hello world example.  Running "go 
build -x" shows that they ship a link.exe for Win64 with their 
Win64 zip, guess it's the Mingw one?


If you want something similar for the D compiler packages for 
Win64, I suggest you file a bugzilla issue, as that's where the 
core team and other D devs look for stuff to do:


https://issues.dlang.org

The more info you have about the linker Go is using, the better.  
Best if you just submit a pull request for dmd or its installer, 
making it use this other linker so that VS is not needed:


https://github.com/dlang/dmd/pulls
https://github.com/dlang/installer/pulls

D is a community effort, pitch in to make the things you want 
happen.

Re: Release D 2.077.0

[Walter Bright via Digitalmars-d-announce]

On 11/3/2017 1:20 PM, Dmitry Olshansky wrote:
Sadly array ops would be insufficient for said problem. It wasn’t a direct 
element wise expression.


That sounds like that might be why it failed vectorization :-)

If you recall the expression, it would be interesting to see it.

Re: What is the FreeBSD situation?

[Jonathan M Davis via Digitalmars-d]

On Saturday, November 04, 2017 08:02:38 codephantom via Digitalmars-d wrote:
> On Saturday, 4 November 2017 at 03:19:00 UTC, Jonathan M Davis
>
> wrote:
> > So, that implies that you're doing something funny, but if
> > you're installing dmd with an installer or package manager,
> > then I would think that it would at least be set up correctly.
>
> ok. I worked it out.
>
> my file was named: to.d
>
> so that caused dmd some confusion it seems.
>
> change the name to something else, then dmd is ok with that code.
>
> There's some real 'gotchas' when it comes to file names and
> dmd... I'm not sure I like it.
>
> Interestingly, gdc didn't care that my file was named to.d, it
> did what I wanted the code to do. Would like dmd to do the same
> ;-)
>
> But ldc does the same thing as dmd...neither likes a file named
> to.d when you're calling a template with the same name.

Per the spec, if you don't give a module declaration, the name of the module
is the name of the file (minus the extension). So, if you just give a module
name (which you generally would in any real program rather than a quick test
program), then it's not a problem - unless you give the module a name which
conflicts with something that you're trying to use. If you'd had

module to;

at the top of the module, then you'd have the same problem regardless of the
file name. The module name wins out over the imported name when there's a
conflict, because the module name is a local symbol. In practice, that's
rarely a problem, though poor module-naming practices could certainly make
it a problem.

You can also work around it by using the fully qualified name (std.conv.to
in this case) or by aliasing the symbol to a new name (I think that you can
also statically import a symbol with a new name, but if so, that's basically
the same as statically importing it and then aliasing it).

If gdc doesn't have the same behavior, it's either a bug, and/or it's
related to the fact that the last released version of gdc matched dmd 2.068
(IIRC). So, right now, gdc is a terrible compiler to use unless you don't
care about using a really old version of D. I think that they're getting
close to releasing an update that's much closer to the current version of
dmd, but IIUC, the switch of the frontend from C++ to D was a huge roadblock
for them, since they had a lot of redesign work to do (they also don't have
much manpower). So, it's taken them quite a while to get back up-to-date.

- Jonathan M Davis

Re: What is the FreeBSD situation?

[codephantom via Digitalmars-d]

On Saturday, 4 November 2017 at 03:19:00 UTC, Jonathan M Davis 
wrote:
So, that implies that you're doing something funny, but if 
you're installing dmd with an installer or package manager, 
then I would think that it would at least be set up correctly.


ok. I worked it out.

my file was named: to.d

so that caused dmd some confusion it seems.

change the name to something else, then dmd is ok with that code.

There's some real 'gotchas' when it comes to file names and 
dmd... I'm not sure I like it.


Interestingly, gdc didn't care that my file was named to.d, it 
did what I wanted the code to do. Would like dmd to do the same 
;-)


But ldc does the same thing as dmd...neither likes a file named 
to.d when you're calling a template with the same name.

Re: Improve "Improve Contract Syntax" DIP 1009

[Jonathan M Davis via Digitalmars-d]

On Friday, November 03, 2017 12:34:22 Mark via Digitalmars-d wrote:
> On Friday, 3 November 2017 at 02:32:41 UTC, Jonathan M Davis
>
> wrote:
> > Pretty much the only case where out contracts work well is when
> > you have a very specific, testable condition that all results
> > must have and which does not depend on the input, and most
> > functions simply don't work that way.
> > - Jonathan M Davis
>
> Can you give an example of a function for which this doesn't work?

Um, most functions? Heck, take a really simply one like sqrt. All you have
to check in the out contract is the return value. You have no idea what was
passed in. So, how would you write an out contract verifying that you got
the correct number? If you also had access to the input, then you could do
the reverse operation by squaring the result to see if it matched the input
(assuming of course that floating point rounding errors don't make that not
work), but you don't have access to the input.

And even if you did have access to the input, some functions consume their
input without any way to save it (e.g. an input range that isn't a forward
range), and not all operations are reversible - e.g. if you have a hash
function, you can't get the original value back from it to check against
what was passed in. So, for a lot of stuff, even if you had the original
input, you would have to essentially implement the function a second time in
the out contract to verify the result, and who's to say that the
implementation in the out contract isn't just as buggy as the one in the
main function (assuming that it's even different at all)? And that's still
assuming that you had access to the input parameters in the out contract,
which you don't.

In order to have an out contract be of any use, it needs to be able to
verify something about the state of the result without having any clue what
the input was. You essentially need to be able to pass the result to a
function that says whether an arbitrary result is valid or not. Something
like sort can do that, because you know that the result is supposed to be
sorted, and that's a testable condition (albeit a condition that's not very
cheap to test), but for most functions there simply doesn't exist a test for
knowing whether the result is correct by only looking at the result.

On the other hand, if you know what output a function is supposed to have
for a given input, it's trivial to test that with a unit test. The only
thing that's worse about that is that if you could somehow test the result
in an out contract, then it's possible to test the result for every
invocation of that function instead of just testing a specific set of
inputs. So, upon occasion, an out contract may be useful, but it rarely is,
and even if it is, if your unit tests are good, they'll likely catch all of
the problems that the out contract would catch, and the out contract would
slow down every non-release build, so if the unit tests are enough to catch
the bugs, then having the out contract just needlessly slows down your
program (which may or may not matter, depending on what you do with
non-release builds, but it can matter).

So, all in all, I think that unit tests solve the problem that out contracts
are trying to solve and do it in a way that works in general, whereas out
contracts only work in specific cases. So, I don't see much point in using
them.

- Jonathan M Davis