date:20170516

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

Atila Neves  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--

[Issue 17403] -main switch doesn't run correctly in unittest builds when linking separately

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

--- Comment #2 from Atila Neves  ---
That's... not what I expected. Thanks for the clarification.

--

[Issue 17404] New: creating type named 'object' fails to compile, but only if you import something

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

  Issue ID: 17404
   Summary: creating type named 'object' fails to compile, but
only if you import something
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: johnnymar...@gmail.com

The following compiles today:

struct object{}

OR

class object{]

But as soon as you import anything, even just an empty module, DMD will give
you the following error:

Error: struct mymodule.object conflicts with import mymodule.object at
mymodule.d

Again, if you don't have any imports it WILL compile, but if you import
anything, even an empty module then you get this odd error message.

I'm not sure if D allows you to name types 'object'.  If it does then this is
clearly a bug in the compiler.  If it doesn't then the error message should be
fixed.

--

Re: Equivalent to nullptr

2017-05-16 Thread Leonardo via Digitalmars-d-learn


On Thursday, 4 May 2017 at 04:34:40 UTC, Stanislav Blinov wrote:
In the meantime, you can get around the issue by redeclaring 
the function with another name and loading it manually just 
after calling DerelictSDL2.load():



import derelict.sdl2.sdl;

__gshared SDL_bool function (const(SDL_Point)*, int, 
const(SDL_Rect)*, SDL_Rect*) SDL_EnclosePoints_;


void main()
{
   DerelictSDL2.load();
   DerelictSDL2.bindFunc(cast(void**)_EnclosePoints_, 
"SDL_EnclosePoints");

   // ...
}


Now you'd need to call SDL_EnclosePoints_ instead of 
SDL_EnclosePoints.


Thank you.

[Issue 16053] SysTime.fromIsoExtString don't work if nanoseconds are presented

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

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

https://github.com/dlang/phobos/commit/21c09f18d33b65475a89c7d6ec75d87556e6c1e5
Issue 16053: Fix it so that SysTime's from*String supports more than 7 digits.

ISO 8601 says that it's up to the application to decide how many digits
to put in the fractional seconds if they're present. SysTime.to*String
puts up to 7 (stripping trailing zeroes), because that's
hecto-nanosecond precision, and SysTime holds the time in
hecto-nanoseconds. Currently, from*String only accepts up to 7 digits in
the fractional seconds, which _does_ follow the spec in that (per the
spec) the number of digits is up to the applications. However, while we
never emit more than 7 digits, other applications do, so only accepting
7 digits makes us incompatible with them, whereas accepting them would
make us more compatible with other programs, and it would actually be
more efficient, since we'd have fewer checks in the code.

So, these changes make is so that SysTime.from*String accepts more than 7
digits in the fractional seconds, but the additional digits are
truncated (since SysTime doesn't support more than 7 digits of
precision).

--

Re: D equivalent of C++11's function local static initialization?

2017-05-16 Thread Timothee Cour via Digitalmars-d-learn

NOTE: curious about both cases:
* thread local
* shared

On Tue, May 16, 2017 at 8:04 PM, Timothee Cour  wrote:
> what's the best D equivalent of C++11's function local static initialization?
> ```
> void fun(){
>   static auto a=[](){
> //some code
>return some_var;
>   }
> }
> ```
>
> (C++11 guarantees thread safety)

D equivalent of C++11's function local static initialization?

2017-05-16 Thread Timothee Cour via Digitalmars-d-learn

what's the best D equivalent of C++11's function local static initialization?
```
void fun(){
  static auto a=[](){
//some code
   return some_var;
  }
}
```

(C++11 guarantees thread safety)

Replacing std.math raw pointer arithmetic with a union type

2017-05-16 Thread tsbockman via Digitalmars-d

std.math contains a lot of raw pointer arithmetic for accessing 
the various bit fields of floating-point values (see 
https://en.wikipedia.org/wiki/IEEE_754-1985). Much of this code 
has several nearly-identical copies, manually specialized for 
each supported floating-point format.


Such code is verbose, hard to read, and, judging by the bugs and 
missing specializations I've found, hard to write correctly. It 
is also not compatible with CTFE.


A while ago I created Phobos #4336 
(https://github.com/dlang/phobos/pull/4336), which begins the 
process of replacing all the pointer arithmetic in std.math, and 
the supporting floatTraits template, using a fast union type: 
RealRep.


Ian Buclaw recently approved my work, but I believe that a pull 
request of this size and importance should be review by at least 
one other qualified person.


Would any of our other floating-point experts be willing to take 
a look?

Re: Low hanging fruit: dub git integration

2017-05-16 Thread rikki cattermole via Digitalmars-d


On 16/05/2017 7:10 PM, Andre Pany wrote:

Hi,

While integrating the git protocol into dub is complex, there is a much
much easier solution.

Github and bitbucket provides access to the source code, including
releases, branches and commits as archive files using the http protocol.

Without counting the actual unzip/untar coding I assume more or less 100
lines of additional coding is needed in dub.

In dub.json in addition to the existing path attribute of the dependeny
object a new attribute "url" has to be added. You can specify here an
url to a zip/tar.gz. This file has to be downloaded and extracted. The
extract path is then filled into the existing path attribute of the
dependency object.

The only issue is the untar/unzip logic...

This little tweak would make dub a lot more flexible like npm.

Kind regards
André


I've built a prototype UI[1] for some code[0] to solve this exact problem.

It may seem complex, but you can't rely on HTTP download options for 
easy access to repositories.


I would appreciate anyone taking the time to do the survey[1] (the 
question mark) which has a couple of tasks to do. It'll give you the 
basic idea of what I'm thinking UI wise.


[0] https://gist.github.com/rikkimax/4718740223748256d94b3b1474525012
[1] http://cattermole.co.nz/comp626/

Re: DIP 1003 Formal Review

2017-05-16 Thread Jonathan M Davis via Digitalmars-d

On Wednesday, May 17, 2017 01:01:29 MysticZach via Digitalmars-d wrote:
> I think there are several issues at hand, and they need to be
> dealt with individually:
>
> 1. `body` is a very useful identifier. It would be nice to have
> it available.
>
> 2. Contract syntax is too verbose.
>
> 3. a. Some people think code looks better with a keyword, e.g.
> `body`, `do`, etc. distinguishing the function from the contracts.
>
> 3. b. Other people think that such a keyword is unnecessarily
> redundant and does not justify its own existence.
>
> I think the thread will be more productive if the posters commit
> to answering just one of these issues, and reserve other issues
> for other threads. As the DIP in question is directly meant to
> address issue #1, it makes sense to try to solve that problem and
> only that problem here.

The issues are not completely separate, because one of the suggestions of
how to make the change with regards to body is to replace it with function.
So, while we don't need to decide to completely overhaul the syntax for
contracts, we do need to decide what we're going to do with the place where
body is used now - be it remove the need for body entirely, make it a
contextual keyword so that it's still used in contracts but is also usable
as an identifier, or replace it with another keyword such as function or do.

- Jonathan M Davis

Re: DIP 1003 Formal Review

2017-05-16 Thread Meta via Digitalmars-d


On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:
I think the thread will be more productive if the posters 
commit to answering just one of these issues


Agreed. Let's hope it's the topic that the DIP is actually 
addressing ;-)

Re: DIP 1003 Formal Review

2017-05-16 Thread MysticZach via Digitalmars-d


On Tuesday, 16 May 2017 at 18:57:37 UTC, H. S. Teoh wrote:
To me, it's actually worse, because now you have a visual 
conflation with do-loops.


Overall, what I don't like about contract syntax is that it is 
so unbearably verbose. It's not just the in and out blocks and 
the (IMO redundant) marking of the function body; it's also the 
repeated 'assert's that occur in the in and out blocks.


int foo(T, U)(T t, U u)
if (sigContraints!T && sigConstraints!U)
in
{
assert(t > 0 && u < 10);
}
out(val)
{
assert(val > 1 && val < 5);
}
body
{
// function body here
}

I understand this DIP is only to address the `body` part of 
this ugly verbosity, but imagine how much better it would be if 
we could write something like this instead:


int foo(T, U)(T t, U u)
if (sigConstraints!T && sigConstraints!U)
in (t > 0 && u < 10)
out(foo > 1 && foo < 5 )
{
// function body here
}

This is just tentative example syntax, of course.  We can argue 
over its fine points later, but the point is that the current 
syntax is far too verbose, and can easily be reduced to half 
the number of lines.  Merely changing `body` to `do` does 
nothing to address this, and seems to me to be just more 
useless churn, replacing one bit of verbosity with another bit 
of verbosity. (Not to mention the IMO very ugly syntax clash 
with do-loops, which will reduce code readability even more.)



T


I think there are several issues at hand, and they need to be 
dealt with individually:


1. `body` is a very useful identifier. It would be nice to have 
it available.


2. Contract syntax is too verbose.

3. a. Some people think code looks better with a keyword, e.g. 
`body`, `do`, etc. distinguishing the function from the contracts.


3. b. Other people think that such a keyword is unnecessarily 
redundant and does not justify its own existence.


I think the thread will be more productive if the posters commit 
to answering just one of these issues, and reserve other issues 
for other threads. As the DIP in question is directly meant to 
address issue #1, it makes sense to try to solve that problem and 
only that problem here.

Re: Weak Eco System?

2017-05-16 Thread Jonathan M Davis via Digitalmars-d

On Tuesday, May 16, 2017 23:17:10 Mike B Johnson via Digitalmars-d wrote:
> On Tuesday, 16 May 2017 at 21:08:34 UTC, Benro wrote:
> > On Tuesday, 16 May 2017 at 17:14:49 UTC, Basile B. wrote:
> >> For example the build.bat fix could have been made and merged
> >> in 10 min. if you would have took the time to report it!
> >
> > First of all. ! is not appreciated. This is considered yelling.
>
> Grow up!
>
> ! is not yelling. It makes no sound, has no meaning, and only
> exists to insert in to tight anuses that have no life.

Let's please be civil. It can be quite easy to misinterpet tone when dealing
only with text, but it looks to me like there's too much overacting in this
thread in general. Let's take the feedback and try and be constructive about
it. And regardless of what someone else posted, insults are not appropriate
here.

- Jonathan M Davis

Re: Weak Eco System?

2017-05-16 Thread Mike B Johnson via Digitalmars-d


On Tuesday, 16 May 2017 at 21:08:34 UTC, Benro wrote:

On Tuesday, 16 May 2017 at 17:14:49 UTC, Basile B. wrote:
For example the build.bat fix could have been made and merged 
in 10 min. if you would have took the time to report it!


First of all. ! is not appreciated. This is considered yelling.


Grow up!

! is not yelling. It makes no sound, has no meaning, and only 
exists to insert in to tight anuses that have no life.

[Issue 17403] -main switch doesn't run correctly in unittest builds when linking separately

2017-05-16 Thread Daniel Kozak via Digitalmars-d-announce

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
I think the invocation is incorrect - you need to specify -main when linking,
not compiling:

$ dmd -c -unittest foo.d 
$ dmd -main foo.o
$ ./foo
core.exception.AssertError@foo.d(1): unittest failure

--

Re: Harbored-mod 0.2.1 and DYaml 0.6.1 at dlang-community

2017-05-16 Thread via Digitalmars-d-announce


On Tuesday, 16 May 2017 at 22:03:17 UTC, Daniel Kozak wrote:
Nice, I have wait so many months until I decided to fork 
yamkeys because of d-yaml. Now I can delete it thanks. This 
makes my live easier.  This is something I want to propose many 
times, that there is something like dlang-community. Btw. is 
there some more info about it. Because I miss it somehow


On Tue, May 16, 2017 at 10:46 PM, Basile B. via 
Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> 
wrote:


Following Brian Schott Announce [1] about the migration of his 
projects to the dlang-community, I'm pleased to announce that 
the most popular repository from Ferdinand Majerech are now 
also hosted there.


- D-YAML, a YAML parser and emitter for D (native D 
implementation) is at https://github.com/dlang-community/D-YAML


- harbored-mod, a D documentation generator based on harbored 
is at https://github.com/dlang-community/harbored-mod


So far we pushed the commits done in several forks and the two 
projects are up to date, tested by TravisCI, buildable with 
either make or DUB.


Note about D-Yaml: People who forked D-Yaml for their projects 
are encouraged to push their change to dlang-community and 
give up their fork !


[1]: 
http://forum.dlang.org/post/abbprxuwgqlmuuwdf...@forum.dlang.org


AFAIK, the idea was born when we (André/stonemaster, 
Sebastian/wilzbach and me) had issues with dlang-tour [0] when 
DMD 2.072.0 was released and become the default on Travis-CI and 
I had to fork D-YAML [1] and other project(s) in order to get my 
fixes merged [2].


Sebastian:
Maybe it's not a bad idea to have a couple of important D 
packages like this one a community namespace, s.t. it doesn't 
depend on one maintainer?


Me:
I've also thought about that. Maybe a common github 
organization where all prominent members of the community have 
merge rights, though individual projects would still be driven 
by their authors. Similar to phobos experimental, but not tied 
to dmd releases, and with more lax requirements for entry and 
respectively a bit less guarantees.


But most importantly, Sebastian actually created the github 
organization and started the discussion [4], [5].


[0]: 
https://github.com/stonemaster/dlang-tour/pull/471#issuecomment-258311882

[1]: https://github.com/stonemaster/dlang-tour/pull/487
[2]: https://github.com/dlang-community/D-YAML/pull/49
[3]: 
https://github.com/wilzbach/yaml/pull/6#issuecomment-266241628

[4]: https://github.com/dlang-community/discussions/issues/2
[5]: https://github.com/dlang-community/D-Scanner/issues/421

Re: Cheetah: Keeping track of multiple connected clients

2017-05-16 Thread aberba via Digitalmars-d-learn


On Tuesday, 16 May 2017 at 21:56:16 UTC, aberba wrote:

On Tuesday, 16 May 2017 at 17:49:07 UTC, bauss wrote:

[...]


It really awesome the way you responded quickly. About 
targeting a client, suppose I have clients A, B, and C.


Message can be broadcast to all using above solution. But in 
case A want to sent message to B and not C, how does server 
detect the specific destination client's id? Does 
client.send(...) allow json string with target id from browser 
client?


I'm trying to find a way to receive meesage in one language 
along with target client's id and send to the target after I 
have translated to another lang.


The client is a browser socket using WebScoket() api. Or does 
cheetah only work with its D client?

Re: Harbored-mod 0.2.1 and DYaml 0.6.1 at dlang-community

2017-05-16 Thread Seb via Digitalmars-d-announce


On Tuesday, 16 May 2017 at 22:03:17 UTC, Daniel Kozak wrote:
Nice, I have wait so many months until I decided to fork 
yamkeys because of d-yaml. Now I can delete it thanks. This 
makes my live easier.  This is something I want to propose many 
times, that there is something like dlang-community. Btw. is 
there some more info about it. Because I miss it somehow



It's an organization that was formed to avoid exactly this issue 
of needing to fork popular repositories all the time. As Basile 
mentioned this means that instead of waiting for months a bug fix 
can be merged and released within minutes and thus actual 
development and improvement can happen - instead of wasting a lot 
of time recreating the same fix or being annoyed broken 
dependencies.
Due to being quite young, there's much public visibility or 
information yet.
However, if you have a project that you would like to be part of 
this org or just want to talk to us, please feel free to open an 
issue here:



https://github.com/dlang-community/discussions

(we abuse GH issues as a public mailing list)

Re: Harbored-mod 0.2.1 and DYaml 0.6.1 at dlang-community

Nice, I have wait so many months until I decided to fork yamkeys because of
d-yaml. Now I can delete it thanks. This makes my live easier.  This is
something I want to propose many times, that there is something like
dlang-community. Btw. is there some more info about it. Because I miss it
somehow

On Tue, May 16, 2017 at 10:46 PM, Basile B. via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> Following Brian Schott Announce [1] about the migration of his projects to
> the dlang-community, I'm pleased to announce that the most popular
> repository from Ferdinand Majerech are now also hosted there.
>
> - D-YAML, a YAML parser and emitter for D (native D implementation)
> is at https://github.com/dlang-community/D-YAML
>
> - harbored-mod, a D documentation generator based on harbored
> is at https://github.com/dlang-community/harbored-mod
>
> So far we pushed the commits done in several forks and the two projects
> are up to date, tested by TravisCI, buildable with either make or DUB.
>
> Note about D-Yaml: People who forked D-Yaml for their projects are
> encouraged to push their change to dlang-community and give up their fork !
>
> [1]: http://forum.dlang.org/post/abbprxuwgqlmuuwdf...@forum.dlang.org
>

Re: Cheetah: Keeping track of multiple connected clients

2017-05-16 Thread aberba via Digitalmars-d-learn


On Tuesday, 16 May 2017 at 17:49:07 UTC, bauss wrote:

On Tuesday, 16 May 2017 at 16:01:49 UTC, aberba wrote:
Does anyone know how to keep track of multiple clients in 
Cheetah socket lib such that one can directly message a client 
or broadcast to all connected clients.



Something like:

onMessage(... e)
{
...
   // send to all
   e.clients.broadcast (message);

...OR...
   // target a client
e.clients[clientID].send(message);
}

Or any D lib with similar function.


I have now added an internal client-storage to the project.

The server will have a getClientById(size_t) and a getClients() 
which can be used.


Ex.

foreach (client; e.server.getClients())  {
// ... Broadcast to each client here
}

...

e.server.getClientById(clientId).send(...);

Each client will be attached to a clientId when they connect.

The client id is a property of the SocketClient class.

To enable the internal storage you must set storeClients to 
true on the server when initializing it, otherwise the storage 
won't be used.


Ex.

server.storeClients = true;

If you don't want to get latest version of it, then you can 
just make your own storage ex. an associative array and then 
add each client to it when they connect.


Right now dub doesn't seem to be able to trigger a manual 
update on the package, so you might have to fetch the updates 
manually from the Github repository.


https://github.com/bausshf/cheetah/commit/9646fd407d274a94c37dc1b0297541963aeb3e6d


It really awesome the way you responded quickly. About targeting 
a client, suppose I have clients A, B, and C.


Message can be broadcast to all using above solution. But in case 
A want to sent message to B and not C, how does server detect the 
specific destination client's id? Does client.send(...) allow 
json string with target id from browser client?


I'm trying to find a way to receive meesage in one language along 
with target client's id and send to the target after I have 
translated to another lang.

Re: DIP 1003 Formal Review

2017-05-16 Thread jmh530 via Digitalmars-d


On Tuesday, 16 May 2017 at 21:39:19 UTC, jmh530 wrote:


I agree with your points, but it doesn't necessarily preclude 
adding in/out statements. My only qualm is that they would seem 
very similar to scope statements. Perhaps scope(in) and 
scope(out(x)) or something like that. Would not break any code 
to do it.


I meant adding in/out statements without removing the in/out 
block functionality the way it is now.

Re: DIP 1003 Formal Review

2017-05-16 Thread jmh530 via Digitalmars-d


On Monday, 15 May 2017 at 02:02:42 UTC, Basile B. wrote:


int fun(int a) {
  in assert(...);
  out(x) assert(...);

  // do stuff
}


It's nice, i like it but it cant work as simply. You're 
forgetting that interface member functions can have contracts. 
With this syntax interfaces member functions would always have 
a body BUT the current semantic is that interface member 
functions with bodies are final methods. Boom. Interfaces don't 
work anymore because there's no easy way to make the difference 
between an interface member function that's final and an 
interface member function that's not pre-implemented (so 
overridable) but has contracts.


I agree with your points, but it doesn't necessarily preclude 
adding in/out statements. My only qualm is that they would seem 
very similar to scope statements. Perhaps scope(in) and 
scope(out(x)) or something like that. Would not break any code to 
do it.

Re: Weak Eco System?

2017-05-16 Thread Basile B. via Digitalmars-d


On Tuesday, 16 May 2017 at 21:08:34 UTC, Benro wrote:

On Tuesday, 16 May 2017 at 17:14:49 UTC, Basile B. wrote:
For example the build.bat fix could have been made and merged 
in 10 min. if you would have took the time to report it!


First of all. ! is not appreciated. This is considered yelling.

Second. The dscanner issue was listed on there own Git 
"build.bat is out of date" for over 3 months. So please do not 
poke people about not reporting a issue, that is already known 
for 3 months. And in case of dscanner, using dup worked just as 
well but you need to figure it our yourself.


And for your information, i reported SEVERAL issues each time i 
gave D a try. More then half the times it ended up being a 
issue with dcd or dscanner. Why do i need to defend myself from 
you? Very welcoming attitude.


[...]

Getting blasted for supposedly not reporting bugs irks the hell 
out of me.


I didn't blast you, don't feel attacked by a simple exclamation 
mark: you didn't give all the information about the D-Scanner 
"build.bat" bug. I was only speaking about this.


The fact is as a user I'm quite satisfied with the state of the 
ecosystem.

Re: Weak Eco System?

2017-05-16 Thread Benro via Digitalmars-d


On Tuesday, 16 May 2017 at 16:31:54 UTC, WebFreak001 wrote:
Sorry to hear that, usually the issue is directly logged to the 
developer tools (Ctrl-Shift-P -> Toggle Developer Tools) which 
you can just send in as issue on 
https://github.com/Pure-D/code-d if it is broken. It should 
always have basic auto completion for the current file and 
project auto completion for dub projects (but not sub packages) 
as well as linting the file when saving and even showing build 
errors when using dub. If it can't find the D import directory 
(std, core) then it should also show a warning to you so I 
don't really know what went wrong without the log. In the next 
big version update the log will be easier to access by the 
output tab in vscode.


I will take another look at it tomorrow. The installation was at 
my work.


At home i need to deal with another issue, so i can not reproduce 
it. D installed on USB stick. Can not uninstall ( stick at work 
). Can not install new version because the old one can not 
uninstall. Yay...

Re: Weak Eco System?

2017-05-16 Thread Benro via Digitalmars-d


On Tuesday, 16 May 2017 at 17:14:49 UTC, Basile B. wrote:
For example the build.bat fix could have been made and merged 
in 10 min. if you would have took the time to report it!


First of all. ! is not appreciated. This is considered yelling.

Second. The dscanner issue was listed on there own Git "build.bat 
is out of date" for over 3 months. So please do not poke people 
about not reporting a issue, that is already known for 3 months. 
And in case of dscanner, using dup worked just as well but you 
need to figure it our yourself.


And for your information, i reported SEVERAL issues each time i 
gave D a try. More then half the times it ended up being a issue 
with dcd or dscanner. Why do i need to defend myself from you? 
Very welcoming attitude.


Some authors responded fast but had been unable to fix the issue 
because it was:


* DCD ( Twice ).
* Incompatibility between D versions, plugin was not updated. 
Solved it with running the older D version.
* A 3th party plugin, that was use was incompatibility ( one with 
a version issue and one where it did not fix a D regression issue 
).


I do not take away from the editor authors there hard word but 
when they need to rely on dscanner, dcd etc for stability, they 
end up with bug reports that are constantly not there issue.


Getting blasted for supposedly not reporting bugs irks the hell 
out of me. The Code-d issue i have nothing to report because 
there is not a single error message. It simply does not work. 
Output is clean. Workspace-d reported no issue. Bug report: It 
does not work. Yea, the author will love that one. O_o


The IntelliJ IDEA, yea, i need to report that one but i was tired 
after the whole installation cycle. I tried that one in the end. 
That was my bad.


I rather post it here and bring focus on the whole issue then 
simply report it on git and then months later coming back to see 
nothing has changed ( again and again ).

Re: Snap packages for DMD and DUB

2017-05-16 Thread via Digitalmars-d-announce

On Tuesday, 16 May 2017 at 20:35:51 UTC, Joseph Rushton Wakeling 
wrote:
On Tuesday, 16 May 2017 at 19:56:56 UTC, Joseph Rushton 
Wakeling wrote:
With your patch in the repo, the packages should be 
automatically rebuilt and uploaded some time in the next hours.
 I'll follow up with an announcement here once that has 
happened.


Patches with Petar's PIC fix in them have now been uploaded to 
the store.  I've tested on Ubuntu 16.10 and 17.04 and they seem 
to work well.


Nice, thanks for the quick merge :)

Re: Low hanging fruit: dub git integration

2017-05-16 Thread Andre Pany via Digitalmars-d

On Tuesday, 16 May 2017 at 19:41:32 UTC, Brad Anderson wrote:

On Tuesday, 16 May 2017 at 18:10:52 UTC, Andre Pany wrote:

Hi,

While integrating the git protocol into dub is complex, there
is a much much easier solution.

Github and bitbucket provides access to the source code,
including releases, branches and commits as archive files
using the http protocol.

Without counting the actual unzip/untar coding I assume more
or less 100 lines of additional coding is needed in dub.

In dub.json in addition to the existing path attribute of the
dependeny object a new attribute "url" has to be added. You
can specify here an url to a zip/tar.gz. This file has to be
downloaded and extracted. The extract path is then filled into
the existing path attribute of the dependency object.

The only issue is the untar/unzip logic...

This little tweak would make dub a lot more flexible like npm.

Kind regards
André

This is actually exactly how dub fetches source code but the
registry does it rather than dub itself (I'm not sure why)[1].
A bare URL dependency may be controversial though because it
makes versioning more difficult to ensure.

1.
https://github.com/dlang/dub-registry/blob/d825840770bb29356495f265480035ed7e3321b8/source/dubregistry/repositories/github.d#L89

In my scenario I have github repositories stored on the company
github server but not on the public github server. Also running
an own dub registry server is not an option as I would have to
adapt the source code (settings are hard coded) and the license
type of dub registry is lgpl.

Kind regards
André

Harbored-mod 0.2.1 and DYaml 0.6.1 at dlang-community

2017-05-16 Thread Basile B. via Digitalmars-d-announce

Following Brian Schott Announce [1] about the migration of his 
projects to the dlang-community, I'm pleased to announce that the 
most popular repository from Ferdinand Majerech are now also 
hosted there.


- D-YAML, a YAML parser and emitter for D (native D 
implementation)

is at https://github.com/dlang-community/D-YAML

- harbored-mod, a D documentation generator based on harbored
is at https://github.com/dlang-community/harbored-mod

So far we pushed the commits done in several forks and the two 
projects are up to date, tested by TravisCI, buildable with 
either make or DUB.


Note about D-Yaml: People who forked D-Yaml for their projects 
are encouraged to push their change to dlang-community and give 
up their fork !


[1]: 
http://forum.dlang.org/post/abbprxuwgqlmuuwdf...@forum.dlang.org

Re: DIP 1003 Formal Review

2017-05-16 Thread Steven Schveighoffer via Digitalmars-d


On 5/16/17 3:43 PM, Timon Gehr wrote:

On 16.05.2017 21:25, Steven Schveighoffer wrote:

I'm specifically asking if just removing the 'keyword-ness' of it is not
doable for some reason.


It's easy to do technically. (The bad thing about option 1 is that it's
the kind of thing that would probably not arise from an up-front
language design and requires history to explain.)


It's easy to explain. It looks better than just nothing between the two 
sets of braces :)


-Steve

Re: Snap packages for DMD and DUB

2017-05-16 Thread Joseph Rushton Wakeling via Digitalmars-d-announce

On Tuesday, 16 May 2017 at 19:56:56 UTC, Joseph Rushton Wakeling 
wrote:
With your patch in the repo, the packages should be 
automatically rebuilt and uploaded some time in the next hours.
 I'll follow up with an announcement here once that has 
happened.


Patches with Petar's PIC fix in them have now been uploaded to 
the store.  I've tested on Ubuntu 16.10 and 17.04 and they seem 
to work well.

Re: DIP 1003 Formal Review


On 16.05.2017 22:00, H. S. Teoh via Digitalmars-d wrote:

On Tue, May 16, 2017 at 09:48:07PM +0200, Timon Gehr via Digitalmars-d wrote:
[...]

I'm saying no to this:

...
{

}{

}

It doesn't have to be formatted that way. For example:

int foo()
in { assert(blah); }
{
// not so bad after all
}


IMO, this is just as bad. It's the same thing.


(Not to mention the IMO very ugly syntax clash with
do-loops, which will reduce code readability even more.)
...


Do you think your new syntax is significantly more readable? (Just
curious.)


It at least gets rid of the verbosity of the current syntax.  I don't
claim it's necessarily *significantly* more readable, but I'd consider
it to be one step closer.  Getting all the way there would be another
topic, and a very long, protracted one, given our track record.


But still: If we are going to break all usages of contracts, then why 
not just fix the entire syntax at once? It just seems to be a much 
better option than making it worse.

[Issue 15720] iota(long.max, long.min, step) does not work properly

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

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

   What|Removed |Added

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

--

[Issue 15720] iota(long.max, long.min, step) does not work properly

2017-05-16 Thread Joseph Rushton Wakeling via Digitalmars-d-announce

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

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

https://github.com/dlang/phobos/commit/49ee158a9e5887ad835dc0f04c0309adf22ff965
Fix Issue 15720 - iota(long.max, long.min, step) does not work properly

https://github.com/dlang/phobos/commit/138d9b91284bba8da3ceb9e5da2f52fea85db1c9
Merge pull request #5397 from andralex/15720

Fix Issue 15720 - iota(long.max, long.min, step) does not work properly
merged-on-behalf-of: Vladimir Panteleev 

--

Re: DIP 1003 Formal Review

2017-05-16 Thread H. S. Teoh via Digitalmars-d

On Tue, May 16, 2017 at 09:48:07PM +0200, Timon Gehr via Digitalmars-d wrote:
[...]
> I'm saying no to this:
> 
> ...
> {
> 
> }{
> 
> }

It doesn't have to be formatted that way. For example:

int foo()
in { assert(blah); }
{
// not so bad after all
}

[...]
> > int foo(T, U)(T t, U u)
> > if (sigConstraints!T && sigConstraints!U)
> > in (t > 0 && u < 10)
> > out(foo > 1 && foo < 5 )
> > {
> > // function body here
> > }
> > 
> > This is just tentative example syntax, of course.  We can argue over
> > its fine points later, but the point is that the current syntax is
> > far too verbose, and can easily be reduced to half the number of
> > lines.  Merely changing `body` to `do` does nothing to address this,
> > and seems to me to be just more useless churn, replacing one bit of
> > verbosity with another bit of verbosity.
> 
> It's a good option to have, but D is not an expression-based language,
> so this can be painful, as you cannot declare intermediate variables
> nor use statements.

Yes, I'm aware that one of the reasons for the current syntax was the
desire to allow arbitrary code inside contracts.  In practice, though, I
hardly ever encounter a use case that needed this, and even where it was
needed, the code was much better off being in a separate function so
that you could write, for example:

bool elementsWithinRange(T)(T[] data, T lower, T upper) {
foreach (e; data) {
if (e < lower || e >= upper) return false;
}
return true;
}

int foo(T)(T[] data)
in { assert(data.elementsWithinRange(0, 10); }
body // ugh
{
...
}

In the hypothetical new syntax, you could get rid of the assert
altogether for a much more concise expression of the in-contract.

IMO, if your contracts have become complex enough to require variables
and statements, then it's time to refactor them into properly-named
functions so that the person reading the code doesn't have to mentally
parse and execute the contract just to understand what requirements it's
trying to express.  D not being an expression-based language is not a
problem since contracts can call arbitrary functions. (In fact, I'd
argue it's an advantage, since it would require users to refactor their
contracts once it starts getting out-of-hand. The result should be
better readability.)

> > (Not to mention the IMO very ugly syntax clash with
> > do-loops, which will reduce code readability even more.)
> > ...
> 
> Do you think your new syntax is significantly more readable? (Just
> curious.)

It at least gets rid of the verbosity of the current syntax.  I don't
claim it's necessarily *significantly* more readable, but I'd consider
it to be one step closer.  Getting all the way there would be another
topic, and a very long, protracted one, given our track record.

T

-- 
"No, John.  I want formats that are actually useful, rather than over-featured 
megaliths that address all questions by piling on ridiculous internal links in 
forms which are hideously over-complex." -- Simon St. Laurent on xml-dev

Re: Snap packages for DMD and DUB

On Monday, 15 May 2017 at 21:07:05 UTC, Petar Kirov [ZombineDev] 
wrote:
This should fix it: 
https://github.com/dlang-snaps/dmd.snap/pull/7


Thanks ever so much for that.  It's really nice to have the first 
not-by-me patch in that repo, especially when it comes with such 
a nicely-written commit message :-)


It seems that you added PIC on the tools repo, instead of 
druntime.
I missed that too when debugging the snapcraft build myself. 
Looking
at the diff without expanding it on github 
(https://github.com/dlang-snaps/dmd.snap/commit/b82fb60cb33e6ed42534e36f8703f75702f2c9fb) can

be quite confusing. I came back to that file only after reading
the druntime, phobos and tools makefiles several times and
scratching my head for about an hour :D


D'oh!  Thanks again for taking that time.  I think I'm going to 
hold some of the shorter-term effects of DConf responsible for 
the misplaced PICs ... :-P


With your patch in the repo, the packages should be automatically 
rebuilt and uploaded some time in the next hours.  I'll follow up 
with an announcement here once that has happened.

Re: DIP 1003 Formal Review


On 16.05.2017 20:57, H. S. Teoh via Digitalmars-d wrote:

On Tue, May 16, 2017 at 08:43:01PM +0200, Timon Gehr via Digitalmars-d wrote:

On 16.05.2017 20:06, Andrei Alexandrescu wrote:

On 05/16/2017 01:59 PM, Random D user wrote:


int foo()
in
{
}
out
{
}
do
{
  bar();
}


Can't deny I like that. -- Andrei


Beats options 2 and 3.


To me, it's actually worse, because now you have a visual conflation
with do-loops.



It's worse than option 1, but not worse than options 2 and 3. I prefer a 
visual conflation with do loops over a visual conflation with any of the 
constructs having 'function' in it, and I'm saying no to this:


...
{

}{

}


Overall, what I don't like about contract syntax is that it is so
unbearably verbose.


It's quite verbose, but certainly not unbearably so.


It's not just the in and out blocks and the (IMO
redundant)  marking of the function body;


There are many redundant elements in the D grammar. It's not a bad thing 
per se.



it's also the repeated
'assert's that occur in the in and out blocks.

int foo(T, U)(T t, U u)
if (sigContraints!T && sigConstraints!U)
in
{
assert(t > 0 && u < 10);
}
out(val)
{
assert(val > 1 && val < 5);
}
body
{
// function body here
}

I understand this DIP is only to address the `body` part of this ugly
verbosity,


Actually, the goal of the DIP is to make 'body' not a keyword. Nothing more.


but imagine how much better it would be if we could write
something like this instead:

int foo(T, U)(T t, U u)
if (sigConstraints!T && sigConstraints!U)
in (t > 0 && u < 10)
out(foo > 1 && foo < 5 )
{
// function body here
}

This is just tentative example syntax, of course.  We can argue over its
fine points later, but the point is that the current syntax is far too
verbose, and can easily be reduced to half the number of lines.  Merely
changing `body` to `do` does nothing to address this, and seems to me to
be just more useless churn, replacing one bit of verbosity with another
bit of verbosity.


It's a good option to have, but D is not an expression-based language, 
so this can be painful, as you cannot declare intermediate variables nor 
use statements.



(Not to mention the IMO very ugly syntax clash with
do-loops, which will reduce code readability even more.)
...


Do you think your new syntax is significantly more readable? (Just curious.)

Re: DIP 1003 Formal Review


On 16.05.2017 21:25, Steven Schveighoffer wrote:

I'm specifically asking if just removing the 'keyword-ness' of it is not
doable for some reason.


It's easy to do technically. (The bad thing about option 1 is that it's 
the kind of thing that would probably not arise from an up-front 
language design and requires history to explain.)

Re: Low hanging fruit: dub git integration

2017-05-16 Thread Brad Anderson via Digitalmars-d


On Tuesday, 16 May 2017 at 18:10:52 UTC, Andre Pany wrote:

Hi,

While integrating the git protocol into dub is complex, there 
is a much much easier solution.


Github and bitbucket provides access to the source code, 
including releases, branches and commits as archive files using 
the http protocol.


Without counting the actual unzip/untar coding I assume more or 
less 100 lines of additional coding is needed in dub.


In dub.json in addition to the existing path attribute of the 
dependeny object a new attribute "url" has to be added. You can 
specify here an url to a zip/tar.gz. This file has to be 
downloaded and extracted. The extract path is then filled into 
the existing path attribute of the dependency object.


The only issue is the untar/unzip logic...

This little tweak would make dub a lot more flexible like npm.

Kind regards
André


This is actually exactly how dub fetches source code but the 
registry does it rather than dub itself (I'm not sure why)[1]. A 
bare URL dependency may be controversial though because it makes 
versioning more difficult to ensure.


1. 
https://github.com/dlang/dub-registry/blob/d825840770bb29356495f265480035ed7e3321b8/source/dubregistry/repositories/github.d#L89

Re: DIP 1003 Formal Review

On Tuesday, 16 May 2017 at 19:25:25 UTC, Steven Schveighoffer 
wrote:

On 5/16/17 2:48 PM, Eugene Wissner wrote:
On Tuesday, 16 May 2017 at 18:34:06 UTC, Steven Schveighoffer 
wrote:


1) Consistency with functions without contracts.


This only applies to the "naked" version which has ugly }{ in 
it. The other options people are asking about are replacing 
body with a keyword, which I think you agree would be bad for 
consistency?


Yeah, I think function or something else is a worse alternative. 
Better leave body as is than replace it with another word. I can 
name my variables body_ if I need.


2) I wouldn't like to have body optional because: it 
introduces an
additional style guide rule: there will be people who will 
omit it and

people who will say: explicitely is better, always use body.


Currently, body is required. It would still be required. Just 
not a keyword. I'm specifically asking if just removing the 
'keyword-ness' of it is not doable for some reason.


Note: body is optional for non-contract functions (yes, void 
foo() body { } is valid). I don't see a rash of people 
promoting having body there.



I wasn't aware of it. Mea culpa.

3) Syntax highlighting: Editors that work with regex will mark 
body in

all contexts as a keyword.


This is a solved problem. Create a C# file, then write 'get' or 
'set' somewhere that's not inside a property, and see if it's 
highlighted differently.


4) I know body isn't reserved anywhere, I can use it without 
thinking
abot the contexts (good for new comers who may think body is a 
reserved

keyword if it is used as such in some contexts).


I think maybe you misunderstand what I was asking.

-Steve


What I meant If I read a documentation on dlang.org that some 
identifier is reserved for some purpose I automatically think it 
can't be used as variable name. I don't want to check the list of 
reserved keywords every time I doubt. The same I never named my 
variables linux or Windows because they are used in version 
blocks. I have never tested if I can name my variable linux or 
Windows. Don't know if it makes sense.

Re: DIP 1003 Formal Review

2017-05-16 Thread Steven Schveighoffer via Digitalmars-d

On Tuesday, 16 May 2017 at 19:24:43 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 16 May 2017 at 19:23:28 UTC, Eugene Wissner wrote:
What about error messages. With asserts I get the line where 
the assert failed. Can I get an information which condition 
failed (sorry for the question, I don't know how it works in 
other languages)?


Use multiple requires/ensures clauses?


That makes sense.

Re: DIP 1003 Formal Review

On 5/16/17 2:48 PM, Eugene Wissner wrote:

On Tuesday, 16 May 2017 at 18:34:06 UTC, Steven Schveighoffer wrote:

On 5/12/17 12:17 PM, Mike Parker wrote:

The first stage of the formal review for DIP 1003 [1], "Remove body as a
Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
GMT on May 27), the community has the opportunity to provide last-minute
feedback. If you missed the preliminary review [2], this is your chance
to provide input.

At the end of the feedback period, I will submit the DIP to Walter and
Andrei for their final decision. Thanks in advance to those of you who
participate.

[1]
https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md

[2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvn...@forum.dlang.org

Before we go down endlessly debating which keywords would work best to
replace body here, can someone please inform the crowd why just having
body remain as it is now, but *not* be a keyword is unworkable?

The more I think about it, the more I think that option 1 is the far
far far superior option. Zero existing code breaks, and we now have
access to our own body symbols (and we don't even have to go through a
deprecation period). However, if there is a missing lynch pin that
shows why this cannot work, then it's better to take it off the table
now.

1) Consistency with functions without contracts.

This only applies to the "naked" version which has ugly }{ in it. The
other options people are asking about are replacing body with a keyword,
which I think you agree would be bad for consistency?

2) I wouldn't like to have body optional because: it introduces an
additional style guide rule: there will be people who will omit it and
people who will say: explicitely is better, always use body.

Currently, body is required. It would still be required. Just not a
keyword. I'm specifically asking if just removing the 'keyword-ness' of
it is not doable for some reason.

Note: body is optional for non-contract functions (yes, void foo() body
{ } is valid). I don't see a rash of people promoting having body there.

3) Syntax highlighting: Editors that work with regex will mark body in
all contexts as a keyword.

This is a solved problem. Create a C# file, then write 'get' or 'set'
somewhere that's not inside a property, and see if it's highlighted
differently.

4) I know body isn't reserved anywhere, I can use it without thinking
abot the contexts (good for new comers who may think body is a reserved
keyword if it is used as such in some contexts).

I think maybe you misunderstand what I was asking.

-Steve

Re: DIP 1003 Formal Review

2017-05-16 Thread Ola Fosheim Grøstad via Digitalmars-d


On Tuesday, 16 May 2017 at 19:23:28 UTC, Eugene Wissner wrote:
What about error messages. With asserts I get the line where 
the assert failed. Can I get an information which condition 
failed (sorry for the question, I don't know how it works in 
other languages)?


Use multiple requires/ensures clauses?

Re: DIP 1003 Formal Review

2017-05-16 Thread Ola Fosheim Grøstad via Digitalmars-d

On Tuesday, 16 May 2017 at 19:18:43 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 16 May 2017 at 18:57:37 UTC, H. S. Teoh wrote:
this ugly verbosity, but imagine how much better it would be 
if we could write something like this instead:


int foo(T, U)(T t, U u)
if (sigConstraints!T && sigConstraints!U)
in (t > 0 && u < 10)
out(foo > 1 && foo < 5 )
{
// function body here
}

This is just tentative example syntax, of course.


Why not just use the terminology the rest of the world has 
landed on?


int foo(T, U)(T t, U u)
if (sigConstraints!T && sigConstraints!U)
requires(t > 0 && u < 10)
ensures(foo > 1 && foo < 5 )
{
   // function body here
}

Or is there some value in being cryptic?


What about error messages. With asserts I get the line where the 
assert failed. Can I get an information which condition failed 
(sorry for the question, I don't know how it works in other 
languages)?

Re: DIP 1003 Formal Review


On Tuesday, 16 May 2017 at 18:57:37 UTC, H. S. Teoh wrote:
this ugly verbosity, but imagine how much better it would be if 
we could write something like this instead:


int foo(T, U)(T t, U u)
if (sigConstraints!T && sigConstraints!U)
in (t > 0 && u < 10)
out(foo > 1 && foo < 5 )
{
// function body here
}

This is just tentative example syntax, of course.


Why not just use the terminology the rest of the world has landed 
on?


int foo(T, U)(T t, U u)
if (sigConstraints!T && sigConstraints!U)
requires(t > 0 && u < 10)
ensures(foo > 1 && foo < 5 )
{
   // function body here
}

Or is there some value in being cryptic?

Re: On the subject of error messages

2017-05-16 Thread Steven Schveighoffer via Digitalmars-d


On 5/16/17 2:29 PM, Stanislav Blinov wrote:

On Tuesday, 16 May 2017 at 15:47:37 UTC, Steven Schveighoffer wrote:

On 5/16/17 9:54 AM, Stanislav Blinov wrote:

On Tuesday, 16 May 2017 at 12:27:30 UTC, Steven Schveighoffer wrote:



When I have a type like this:

struct S
{
   int foo;
}

and the hand-written error message says: "Your type must be a struct
that contains an integer property named 'foo'". How does that help me
figure out what I did wrong? We can spend all day arguing over how
nice this message is, but the truth is, what the constraint writer put
in the constraints, and how the compiler is interpreting it, may be 2
different things. This helps nobody.


It cannot be that way. Whoever wrote the constraint possesses knowledge
about it's semantics. If they put wrong message there, then that's a
bug, or they're a... well, not a very good person.


This is the only time I have issues. Most of the time, the constraint is 
straightforwardly simple and the problem is obvious just by looking at 
the constraint and the type.  When that's not the case, figuring out why 
the constraint doesn't seem to be doing what it says it's doing is the 
hard part.


This can be achieved any number of ways. The most straightforward and 
effective way is to have the compiler simply expose what it's doing.



That is why (static) asserts have an optional string argument: to
display a clean an readable error message, instead of just dumping some
code on the user. The same thing, in my opinion, is needed for
constraints.


If assert(x == 5) would just print "Error: x == 4" automatically, we
could eliminate most needs for a message.


You're taking overly simplified pieces of code and base your reasoning
on them, while you know full well it's almost never this simple.

assert(x.veryBadlyNamedFunction == obscureStateObtainedFromElsewhere);

"Error: x.veryBadlyNamedFunction == 42"

Very helpful message.


Not here to debate this "feature", but if it says what the return value 
was, and the name of the symbol it's checking against (and its value), 
then yes, combined with the usual stack trace it's incredibly useful. 
Most of the time, that's what I would normally write in the message, but 
that in itself isn't easy to do.



You could solve this with a message, but again, this is a huge task to
undertake on ALL code in existence, rather than fixing


I seem to be expressing myself poorly, as I find I must repeat it the
second time already: I never suggested to change any existing code. I
suggested an *optional* mechanism of reporting errors.


No, I mean having the optional mechanism fixes nothing. Someone then has 
to go through all existing code and determine what the existing 
constraints are testing for, and then determine the best way to write 
the messages. That's not a trivial amount of work.



it all to a "good enough" degree that we don't need the messages. And
it avoids the "human compiler" that is prone to error.


This again. No it does not. If there's a bug in the constraint, there is
a bug in the constraint. Messages or no, it's all the same. Either it
does what it's supposed to do, or it doesn't. Reporting the wrong
message is a bug, as is returning false for compliant type, or true for
malicious one.


There could be no bug in the constraint, but the message is misleading, 
wrong, or easy to misinterpret. It's adding another layer of potential 
issues.


-Steve

Re: DIP 1003 Formal Review

2017-05-16 Thread H. S. Teoh via Digitalmars-d

On Tue, May 16, 2017 at 08:43:01PM +0200, Timon Gehr via Digitalmars-d wrote:
> On 16.05.2017 20:06, Andrei Alexandrescu wrote:
> > On 05/16/2017 01:59 PM, Random D user wrote:
> > > 
> > > int foo()
> > > in
> > > {
> > > }
> > > out
> > > {
> > > }
> > > do
> > > {
> > >   bar();
> > > }
> > 
> > Can't deny I like that. -- Andrei
> 
> Beats options 2 and 3.

To me, it's actually worse, because now you have a visual conflation
with do-loops.

Overall, what I don't like about contract syntax is that it is so
unbearably verbose. It's not just the in and out blocks and the (IMO
redundant) marking of the function body; it's also the repeated
'assert's that occur in the in and out blocks.

int foo(T, U)(T t, U u)
if (sigContraints!T && sigConstraints!U)
in
{
assert(t > 0 && u < 10);
}
out(val)
{
assert(val > 1 && val < 5);
}
body
{
// function body here
}

I understand this DIP is only to address the `body` part of this ugly
verbosity, but imagine how much better it would be if we could write
something like this instead:

int foo(T, U)(T t, U u)
if (sigConstraints!T && sigConstraints!U)
in (t > 0 && u < 10)
out(foo > 1 && foo < 5 )
{
// function body here
}

This is just tentative example syntax, of course.  We can argue over its
fine points later, but the point is that the current syntax is far too
verbose, and can easily be reduced to half the number of lines.  Merely
changing `body` to `do` does nothing to address this, and seems to me to
be just more useless churn, replacing one bit of verbosity with another
bit of verbosity. (Not to mention the IMO very ugly syntax clash with
do-loops, which will reduce code readability even more.)

T

-- 
I think the conspiracy theorists are out to get us...

Re: DIP 1003 Formal Review

2017-05-16 Thread Random D user via Digitalmars-d-announce


On Tuesday, 16 May 2017 at 16:10:56 UTC, David Gileadi wrote:
One possible substitute for the `function` keyword in option 2 
could be `do`. I'm not convinced it's a good substitute, but I 
thought I'd throw it out there.


Looks weird for a C-style language imho.

Re: DMD now has colorized syntax highlighting in error messages


On Sunday, 14 May 2017 at 14:07:20 UTC, Walter Bright wrote:

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

It turned out to be unexpectedly easy to implement.


Nice.

But color highlighting should always be configurable (otherwise 
it's half done), because there are a lot of people who like 
colors, but can't distinguish between certain color combinations, 
because of a color disability. Or they might have poor displays 
or viewing conditions etc.


I guess this should be simple to add, just output the colors into 
an .ini file and read them back if the file exists.

Re: DIP 1003 Formal Review

On Tuesday, 16 May 2017 at 18:34:06 UTC, Steven Schveighoffer
wrote:

On 5/12/17 12:17 PM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a
Keyword", is now underway. From now until 11:59 PM ET on May
26 (3:59 AM
GMT on May 27), the community has the opportunity to provide
last-minute
feedback. If you missed the preliminary review [2], this is
your chance

to provide input.

At the end of the feedback period, I will submit the DIP to
Walter and
Andrei for their final decision. Thanks in advance to those of
you who

participate.

[1]
https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md

[2]
http://forum.dlang.org/thread/qgxvrbxrvkxtimzvn...@forum.dlang.org

Before we go down endlessly debating which keywords would work
best to replace body here, can someone please inform the crowd
why just having body remain as it is now, but *not* be a
keyword is unworkable?

The more I think about it, the more I think that option 1 is
the far far far superior option. Zero existing code breaks, and
we now have access to our own body symbols (and we don't even
have to go through a deprecation period). However, if there is
a missing lynch pin that shows why this cannot work, then it's
better to take it off the table now.

-Steve

1) Consistency with functions without contracts.
2) I wouldn't like to have body optional because: it introduces
an additional style guide rule: there will be people who will
omit it and people who will say: explicitely is better, always
use body.
3) Syntax highlighting: Editors that work with regex will mark
body in all contexts as a keyword.
4) I know body isn't reserved anywhere, I can use it without
thinking abot the contexts (good for new comers who may think
body is a reserved keyword if it is used as such in some
contexts).

Re: DIP 1003 Formal Review


On 16.05.2017 20:06, Andrei Alexandrescu wrote:

On 05/16/2017 01:59 PM, Random D user wrote:


int foo()
in
{
}
out
{
}
do
{
  bar();
}


Can't deny I like that. -- Andrei


Beats options 2 and 3.

Re: DIP 1003 Formal Review

2017-05-16 Thread Steven Schveighoffer via Digitalmars-d


On 16.05.2017 19:44, MysticZach wrote:

On Tuesday, 16 May 2017 at 17:42:11 UTC, MysticZach wrote:

On Tuesday, 16 May 2017 at 15:22:12 UTC, Timon Gehr wrote:

auto foo()in{
assert(true);
}out{
assert(true);
}{
return 3;
}

Are you really arguing for this?
I don't want to write code like this.


It's not any better than this:


I meant any worse.


Yes, it is actually worse.

Re: DIP 1003 Formal Review


On 5/12/17 12:17 PM, Mike Parker wrote:

The first stage of the formal review for DIP 1003 [1], "Remove body as a
Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
GMT on May 27), the community has the opportunity to provide last-minute
feedback. If you missed the preliminary review [2], this is your chance
to provide input.

At the end of the feedback period, I will submit the DIP to Walter and
Andrei for their final decision. Thanks in advance to those of you who
participate.

[1]
https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md


[2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvn...@forum.dlang.org


Before we go down endlessly debating which keywords would work best to 
replace body here, can someone please inform the crowd why just having 
body remain as it is now, but *not* be a keyword is unworkable?


The more I think about it, the more I think that option 1 is the far far 
far superior option. Zero existing code breaks, and we now have access 
to our own body symbols (and we don't even have to go through a 
deprecation period). However, if there is a missing lynch pin that shows 
why this cannot work, then it's better to take it off the table now.


-Steve

Re: On the subject of error messages

2017-05-16 Thread Stanislav Blinov via Digitalmars-d

On Tuesday, 16 May 2017 at 15:47:37 UTC, Steven Schveighoffer 
wrote:

On 5/16/17 9:54 AM, Stanislav Blinov wrote:
On Tuesday, 16 May 2017 at 12:27:30 UTC, Steven Schveighoffer 
wrote:


When we have tests using dummy lambdas, are we to expect 
users to
immediately extract the lambda body, parse it, and figure 
out what's

wrong?


This is what you have to do today. The task has already been 
tried by
the compiler, and the result is known by the compiler. Just 
have the

compiler tell you.


:) The compiler does not know what I'm checking for with that 
lambda. As
far as the compiler is concerned, I'm interested in whether it 
compiles
or not. It doesn't care what that means in the context of my 
constraint.

Neither should the user.


You seem to be not understanding that a hand-written message of 
"needs to have member x" or something conveys the same 
information as the compiler saying "Error in this line: auto 
test = T.x"


You are nitpicking again, or, at least, oversimplifying. I am 
understanding that perfectly. But we've both shown examples of 
constraints that are much more complex than just checking for one 
member. As in, the type needs to have these members and/or these 
properties. All of them. Or some of them. Or a set of 
combinations of them. With those specific traits, etc. It's not 
*just* "error in this line". It's "error in this line on this 
execution path with these conditions". And nowhere in sight is 
*what* all those checks are doing as a unit. Not individually, 
but in complex, all of them, in concert.
A fresh user of your code cannot know at a glance what all of 
them are doing, nor should they.


Sure, it's not proper English. It gets the job done, and I 
don't have to instrument all my functions and template 
constraint helpers. I don't need to explode compile times, or 
debug why my messages don't match what actually happens.


If your messages don't match what actually happens, there's a bug 
in your constraint, simple as that. Which you should catch with 
tests.


The compiler, and by extension your hand-written error 
checking,

cannot know the true intention of the user.




hand-written == hand-compiled. That is, I translated what I 
think this boolean condition means into a human-readable format 
by hand. I could have got it wrong. Then a nice message is 
useless.


Eh? You *wrote* the constraint. You *know* what all of those 
tests mean. You didn't translate what you *think* the condition 
means. You wrote the condition, you *know* what it means. If you 
don't, you shouldn't be writing this constraint. The only way for 
you to "get it wrong" is to write a bug in the constraint. Or in 
the compiler.
You know that if you've just did is(typeof((T t) @safe {})) and 
it returned false, T's destructor cannot be called in @safe code. 
It's obvious, isn't it? Every D user knows that for sure.
There are obscure checks, that's the way the language works. 
There are cases when those obscure checks need to be cleanly 
explained. That is *all* that I'm proposing.



When the
user violates the contract, I must inform them they did so, by 
reporting
*why* their argument does not satisfy me. Not by telling *how* 
I figured
that out (compiler output), but by telling *what* is wrong 
with the

argument (human-readable error message).


The constraint tells the user why it doesn't work. There is no 
extra effort required. It's human readable (I know what 
isInputRange!R means). I don't need a specialized full-sentence 
message to understand that.


*You* know what isInputRange means. This doesn't mean that all 
users do.
And do you know, beforehand, what all possible constraints in all 
possible libraries that you may use in the future mean, without 
looking at their code? No. No one does.


If the user does want to know how the constraint caught their 
mistake,

they're free to inspect what the compiler outputs.


And here is the problem. Your solution doesn't get us any 
closer to that. It's actually quite painful to do this today.


Of course it is painful, that's the whole point of my proposal.


When I have a type like this:

struct S
{
   int foo;
}

and the hand-written error message says: "Your type must be a 
struct that contains an integer property named 'foo'". How does 
that help me figure out what I did wrong? We can spend all day 
arguing over how nice this message is, but the truth is, what 
the constraint writer put in the constraints, and how the 
compiler is interpreting it, may be 2 different things. This 
helps nobody.


It cannot be that way. Whoever wrote the constraint possesses 
knowledge about it's semantics. If they put wrong message there, 
then that's a bug, or they're a... well, not a very good person.


That is why (static) asserts have an optional string argument: 
to
display a clean an readable error message, instead of just 
dumping some
code on the user. The same thing, in my opinion, is needed for 
constraints.


If assert(x == 5) would just print

Low hanging fruit: dub git integration

2017-05-16 Thread Andre Pany via Digitalmars-d


Hi,

While integrating the git protocol into dub is complex, there is 
a much much easier solution.


Github and bitbucket provides access to the source code, 
including releases, branches and commits as archive files using 
the http protocol.


Without counting the actual unzip/untar coding I assume more or 
less 100 lines of additional coding is needed in dub.


In dub.json in addition to the existing path attribute of the 
dependeny object a new attribute "url" has to be added. You can 
specify here an url to a zip/tar.gz. This file has to be 
downloaded and extracted. The extract path is then filled into 
the existing path attribute of the dependency object.


The only issue is the untar/unzip logic...

This little tweak would make dub a lot more flexible like npm.

Kind regards
André

Re: DIP 1003 Formal Review

2017-05-16 Thread Andrei Alexandrescu via Digitalmars-d


On 05/16/2017 01:59 PM, Random D user wrote:


int foo()
in
{
}
out
{
}
do
{
  bar();
}


Can't deny I like that. -- Andrei

Re: DIP 1003 Formal Review

2017-05-16 Thread Random D user via Digitalmars-d


On Sunday, 14 May 2017 at 15:39:12 UTC, Walter Bright wrote:

On 5/12/2017 9:17 AM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove 
body as a

Keyword", is now underway.


A combination of Options 1 and 2:

1. Introduce 'function' as an alternative to 'body'.


How about using some other keyword like, with, else, scope or do, 
for example.
Would they read better than 'function' (i.e. function with vs. 
function function vs. function body)? Let's experiment a bit.


int foo()
in
{
}
out
{
}
with
{
  bar();
}

-- or

int foo()
in
{
}
out
{
}
else  // I guess this could be too confusing with template 
constraint? See below.

{
  bar();
}

int foo(T)() if(cond)
in
{
}
out
{
}
else
{
}

-- or

int foo()
in
{
}
out
{
}
scope
{
  bar();
}

-- or

int foo()
in
{
}
out
{
}
do
{
  bar();
}

Re: Fantastic exchange from DConf

2017-05-16 Thread Walter Bright via Digitalmars-d


On 5/16/2017 10:29 AM, Steven Schveighoffer wrote:

1 week later: WanaCry.  Both Walter and WanaCry start with W. Hm


No need to breed mosquitos to promote a cure for malaria :-)

Re: Cheetah: Keeping track of multiple connected clients

2017-05-16 Thread bauss via Digitalmars-d-learn


On Tuesday, 16 May 2017 at 16:01:49 UTC, aberba wrote:
Does anyone know how to keep track of multiple clients in 
Cheetah socket lib such that one can directly message a client 
or broadcast to all connected clients.



Something like:

onMessage(... e)
{
...
   // send to all
   e.clients.broadcast (message);

...OR...
   // target a client
e.clients[clientID].send(message);
}

Or any D lib with similar function.


I have now added an internal client-storage to the project.

The server will have a getClientById(size_t) and a getClients() 
which can be used.


Ex.

foreach (client; e.server.getClients())  {
// ... Broadcast to each client here
}

...

e.server.getClientById(clientId).send(...);

Each client will be attached to a clientId when they connect.

The client id is a property of the SocketClient class.

To enable the internal storage you must set storeClients to true 
on the server when initializing it, otherwise the storage won't 
be used.


Ex.

server.storeClients = true;

If you don't want to get latest version of it, then you can just 
make your own storage ex. an associative array and then add each 
client to it when they connect.


Right now dub doesn't seem to be able to trigger a manual update 
on the package, so you might have to fetch the updates manually 
from the Github repository.


https://github.com/bausshf/cheetah/commit/9646fd407d274a94c37dc1b0297541963aeb3e6d

Re: DIP 1003 Formal Review

2017-05-16 Thread MysticZach via Digitalmars-d


On Tuesday, 16 May 2017 at 17:42:11 UTC, MysticZach wrote:

On Tuesday, 16 May 2017 at 15:22:12 UTC, Timon Gehr wrote:

auto foo()in{
assert(true);
}out{
assert(true);
}{
return 3;
}

Are you really arguing for this?
I don't want to write code like this.


It's not any better than this:


I meant any worse.

Re: DIP 1003 Formal Review

2017-05-16 Thread MysticZach via Digitalmars-d


On Tuesday, 16 May 2017 at 15:22:12 UTC, Timon Gehr wrote:

auto foo()in{
assert(true);
}out{
assert(true);
}{
return 3;
}

Are you really arguing for this?
I don't want to write code like this.


It's not any better than this:

auto foo()in{
assert(true);
}out{
assert(true);
}body{
return 3;
}

They are both bad, but not because of the presence or absence of 
the `body` keyword, in my opinion.

[Issue 17403] -main switch doesn't run correctly in unittest builds when linking separately

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

Atila Neves  changed:

   What|Removed |Added

   Severity|enhancement |normal

--

[Issue 17403] New: -main switch doesn't run correctly in unittest builds when linking separately

2017-05-16 Thread Steven Schveighoffer via Digitalmars-d

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

  Issue ID: 17403
   Summary: -main switch doesn't run correctly in unittest builds
when linking separately
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: atila.ne...@gmail.com

foo.d:

unittest { assert(false); }

$ dmd -main -unittest foo.d
$ ./foo
core.exception.AssertError@foo.d(1): unittest failure
# fails as expected

$ dmd -offoo.o -c -main -unittest foo.d
$ dmd foo.o
$ ./foo  # no error
$

If I change foo.d to include a main function manually:

unittest { assert(false); }
void main() {
import core.runtime: Runtime;
Runtime.moduleUnitTester;
}

Then the 2nd example above fails as expected.

$ dmd -offoo.o -c -unittest foo.d
$ dmd foo.o
$ ./foo
core.exception.AssertError@foo.d(1): unittest failure

--

Re: Fantastic exchange from DConf


On 5/16/17 11:19 AM, Walter Bright wrote:

On 5/5/2017 11:26 PM, Joakim wrote:

Walter: I believe memory safety will kill C.


I can't find any definitive explanation of what the Wannacry exploit is.
One person told me it was an overflow bug, another that it was
truncation from converting 32 to 16 bits.

Anyhow, the Wannacry disaster looks to be a very expensive lesson in
using memory unsafe languages for critical software. I know Microsoft
has worked for years to use their own C which is memory safer,
apparently it is not enough.

https://blogs.msdn.microsoft.com/martynl/2005/10/10/annotations-yet-more-help-finding-buffer-overflows/



Scott: "I am skeptical of the claim that memory safety is going to kill 
[C] off because it has been known that this is not a memory safe 
language for decades."


Dylan: "Do you think that maybe Walter and Andrei planted the memory 
safety topic just to try to kill C?"


Scott: "You know that would be like them..."

1 week later: WanaCry.  Both Walter and WanaCry start with W. Hm

-Steve

[Issue 15720] iota(long.max, long.min, step) does not work properly

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #3 from Andrei Alexandrescu  ---
https://github.com/dlang/phobos/pull/5396/

--

[Issue 17402] dirEntries iterator crashes in conjunction with readText

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

--- Comment #3 from Andrei Alexandrescu  ---
More info: the code only crashes when invoked from inside a dmd unittest.

--

[Issue 17402] dirEntries iterator crashes in conjunction with readText

2017-05-16 Thread Walter Bright via Digitalmars-d-announce

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #2 from Vladimir Panteleev  ---
Wow, that's a segfault inside libpthread (which for some reason gets called
from glibc's readdir).

If you can reproduce this reliably, can you get debug symbols for libc and
libpthread and get a detailed stack trace?

--

Re: Weak Eco System?

2017-05-16 Thread Basile B. via Digitalmars-d


On Tuesday, 16 May 2017 at 14:51:29 UTC, Benro wrote:


Then found out it requires Dub, DCD, Dscanner, DFmt ..

And here the "work" begins. It already requires GIT to be 
installed on the host system.


Then it require knowledge how to clone the projects and 
building them. Several of the projects have out of date 
information.


DCD required:
"dub build --build=release --config=client --force"
"dub build --build=release --config=server --force"

Forced was needed or compilation failed on different versions 
on 3th party packages.


Dfmt required:
"git submodule update --init --recursive" and then build.bat

Dscanner:
Needed dub to build. Its build.bat was out of date and gave 
errors.


If you have problems with Hackerpilot's programs don't forget to 
report an issue.
His tools are now maintained by an organization people 
(https://github.com/dlang-community) and fix are merged fast.


For example the build.bat fix could have been made and merged in 
10 min. if you would have took the time to report it!

Re: Andrei's "Design by Introspection" talk now on Hacker News


On 5/16/2017 8:24 AM, Walter Bright wrote:

Look under the [new] tab. It appeared at about 8:00AM PST.


and reddit:

https://www.reddit.com/r/programming/comments/6bhnss/andrei_alexandrescu_design_by_introspection_talk/

Re: Weak Eco System?

2017-05-16 Thread WebFreak001 via Digitalmars-d


On Tuesday, 16 May 2017 at 14:51:29 UTC, Benro wrote:

**Visual Studio Code code-d:**

* Installed.

* Gave warning to install Workspaces-d. Auto installed 
Workspaces-d. Restarted.
* Gave warning for DUB, DCD, etc ... Auto installed all 
dependances.


Again issues. Code formatting etc worked but no code hinting or 
any advanced features. Looks more or less like a colored editor 
with formatting. Looked for solution, nothing found.


Usability: 2/10 ( Color Syntax, Code formatting worked )

4 Hours work. Discouraged and gave up after this.


Sorry to hear that, usually the issue is directly logged to the 
developer tools (Ctrl-Shift-P -> Toggle Developer Tools) which 
you can just send in as issue on https://github.com/Pure-D/code-d 
if it is broken. It should always have basic auto completion for 
the current file and project auto completion for dub projects 
(but not sub packages) as well as linting the file when saving 
and even showing build errors when using dub. If it can't find 
the D import directory (std, core) then it should also show a 
warning to you so I don't really know what went wrong without the 
log. In the next big version update the log will be easier to 
access by the output tab in vscode.

Re: Fantastic exchange from DConf

2017-05-16 Thread Joakim via Digitalmars-d


On Tuesday, 16 May 2017 at 15:19:54 UTC, Walter Bright wrote:

On 5/5/2017 11:26 PM, Joakim wrote:

Walter: I believe memory safety will kill C.


I can't find any definitive explanation of what the Wannacry 
exploit is. One person told me it was an overflow bug, another 
that it was truncation from converting 32 to 16 bits.


Anyhow, the Wannacry disaster looks to be a very expensive 
lesson in using memory unsafe languages for critical software. 
I know Microsoft has worked for years to use their own C which 
is memory safer, apparently it is not enough.


https://blogs.msdn.microsoft.com/martynl/2005/10/10/annotations-yet-more-help-finding-buffer-overflows/


I happened to be reading this blog post concerning the issue 
today:


https://www.troyhunt.com/dont-tell-people-to-turn-off-windows-update-just-dont/

It links to this official MS page from a couple months ago, which 
lists several CVE entries, which explicitly say they're different 
exploits:


https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

Googling for that security update turns up this script, which 
claims a buffer overflow, but that could be just one of the holes:


https://github.com/RiskSense-Ops/MS17-010/blob/master/exploits/eternalblue/ms17_010_eternalblue.rb

I don't believe MS has disclosed the exact exploits, so it would 
depend on someone reversing the updates and since there are so 
many, they're likely different types.


For those like Scott who say C has survived this long, I say it 
isn't unprecedented for tech with fairly well-known design flaws 
to last much longer than it should, until a crisis springing from 
those flaws finally kills it off.  People usually ignore the 
potential problems until it blows up in front of their face.


I agree that this current constant security crisis, now that 
everything's on the internet, will kill off a lot of old tech, 
including C.  It is one of the reasons IoT is currently 
stillborn.  It is the biggest flaw in Android, where you're 
selling a billion+ mobile devices a year, and almost none of them 
get any security updates:


https://arstechnica.com/gadgets/2017/05/op-ed-google-should-take-full-control-of-androids-security-updates/

It will get a lot worse before it gets better, because it has 
been neglected for so long. :|

Re: DIP 1003 Formal Review

2017-05-16 Thread Adam D. Ruppe via Digitalmars-d-announce


On 16.05.2017 17:47, Jonathan M Davis via Digitalmars-d wrote:

...

And having to
have body (or function whatever other keyword we might put there) just makes
contracts that much more verbose


That's seriously exaggerated.


- as well as being inconsistent with how
functions bodies are declared when there are no contracts.

Honestly, as nice as it would be to get the body keyword back as an
identifier, I care _way_ more about not having a redundant keyword for the
function body.


It's not redundant. Removing it makes the code look bad. There is a 
reason why Walter added it to the language.



I'd be all for removing it from contracts even if we never
got it back as an identifier. I've always found needing to add body to be
very annoying, and I frequently forget it,


Impossible. You "almost never use" contracts.


because it's not there normally.


It's always there if you write a function with contracts.


It's just making contracts longer without adding extra information, and
contracts are _way_ too verbose even without the extra keyword there, let
alone with it.


I'm not against adding less verbose options, but just removing 'body' is 
not a good way to do it. All that does is to go from verbose to verbose 
and ugly. That does not justify a change that breaks all D code that 
uses contracts.





IMHO, if we remove body as a keyword but replace it with something else in
contracts, we've lost out on a big opportunity for some language cleanup.

- Jonathan M Davis



I disagree that changing contract syntax in the way you suggest 
constitutes a cleanup. I agree that changing 'body' to 'function' is a 
similarly bad option though.

Re: DIP 1003 Formal Review

2017-05-16 Thread David Gileadi via Digitalmars-d


On 5/12/17 9:17 AM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove body as a 
Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM 
GMT on May 27), the community has the opportunity to provide last-minute 
feedback. If you missed the preliminary review [2], this is your chance 
to provide input.


At the end of the feedback period, I will submit the DIP to Walter and 
Andrei for their final decision. Thanks in advance to those of you who 
participate.


[1] 
https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md 



[2] http://forum.dlang.org/thread/qgxvrbxrvkxtimzvn...@forum.dlang.org


One possible substitute for the `function` keyword in option 2 could be 
`do`. I'm not convinced it's a good substitute, but I thought I'd throw 
it out there.

Re: DMD now has colorized syntax highlighting in error messages


On Tuesday, 16 May 2017 at 15:38:53 UTC, Walter Bright wrote:

It includes DOS and Windows consoles.


Only under specific circumstances. On the VGA hardware, underline 
shares a bit with blue and needs a register tweaked to make it 
visible (the default 16 color VGA text mode does NOT display the 
underline), and only worked on CJK multibyte output on Windows 
2000 through Windows 10.


Only recently, with the one of the updates to windows 10, was 
console underlining added to Windows for English text, as part of 
their Linux terminal compatibility flag (see: 
ENABLE_VIRTUAL_TERMINAL_PROCESSING).


Then yours is a unique snowflake, as it's standard for VT-100 
emulation (xterm).


It isn't really unique, rxvt treats it as bold and xterm can have 
it compiled out. I do recognize the sequence and even set the bit 
(see: 
https://github.com/adamdruppe/terminal-emulator/blob/master/terminalemulator.d#L1724 ) but then ignore it on the drawing side since blinking is a pointless distraction.


In practice, basic color support is pretty broad and reliable, 
given you remember that there's a human reading it who can't see 
poor contrast easily and a large percentage of them cannot 
reliably tell all colors apart. Underline, however, is not 
broadly supported by the computer console apis.

Cheetah: Keeping track of multiple connected clients

2017-05-16 Thread aberba via Digitalmars-d-learn

Does anyone know how to keep track of multiple clients in Cheetah 
socket lib such that one can directly message a client or 
broadcast to all connected clients.



Something like:

onMessage(... e)
{
...
   // send to all
   e.clients.broadcast (message);

...OR...
   // target a client
e.clients[clientID].send(message);
}

Or any D lib with similar function.

Re: Weak Eco System?

2017-05-16 Thread aberba via Digitalmars-d


On Tuesday, 16 May 2017 at 14:51:29 UTC, Benro wrote:
A quick summary trying to get D and a some IDEs running on a 
Windows environment.


[...]


I just install sublime text editor and that all the tooling I 
ever needed. Sublime has a Dkit plugin too. I agree to bundling 
the tools together though.

Re: On the subject of error messages

2017-05-16 Thread Steven Schveighoffer via Digitalmars-d


On 5/16/17 9:54 AM, Stanislav Blinov wrote:

On Tuesday, 16 May 2017 at 12:27:30 UTC, Steven Schveighoffer wrote:


When we have tests using dummy lambdas, are we to expect users to
immediately extract the lambda body, parse it, and figure out what's
wrong?


This is what you have to do today. The task has already been tried by
the compiler, and the result is known by the compiler. Just have the
compiler tell you.


:) The compiler does not know what I'm checking for with that lambda. As
far as the compiler is concerned, I'm interested in whether it compiles
or not. It doesn't care what that means in the context of my constraint.
Neither should the user.


You seem to be not understanding that a hand-written message of "needs 
to have member x" or something conveys the same information as the 
compiler saying "Error in this line: auto test = T.x"


Sure, it's not proper English. It gets the job done, and I don't have to 
instrument all my functions and template constraint helpers. I don't 
need to explode compile times, or debug why my messages don't match what 
actually happens.



The compiler, and by extension your hand-written error checking,
cannot know the true intention of the user.


The constraint *is* hand-written error checking. What I'm talking about
is hand-written human-readable error messages :) It's not about knowing
user intentions, it's about informing them why they made a mistake.


hand-written == hand-compiled. That is, I translated what I think this 
boolean condition means into a human-readable format by hand. I could 
have got it wrong. Then a nice message is useless.



All it knows is you tried to do something that isn't supported. You
have to figure out what is wrong and fix it. If that takes several
iterations, that's what it takes. There is no solution that will give
you all the answers.


Hold on a second, I think there's a mixup in terminology here. A user
(caller) of move() is not supposed to be interested in what particular
evaluation chain caused the constraint to be false. I, as an author,
declare a contract (constraint). I am not interested in user's
intentions. I am interested that I'm being called correctly. When the
user violates the contract, I must inform them they did so, by reporting
*why* their argument does not satisfy me. Not by telling *how* I figured
that out (compiler output), but by telling *what* is wrong with the
argument (human-readable error message).


The constraint tells the user why it doesn't work. There is no extra 
effort required. It's human readable (I know what isInputRange!R means). 
I don't need a specialized full-sentence message to understand that.



If the user does want to know how the constraint caught their mistake,
they're free to inspect what the compiler outputs.


And here is the problem. Your solution doesn't get us any closer to 
that. It's actually quite painful to do this today. When I have a type 
like this:


struct S
{
   int foo;
}

and the hand-written error message says: "Your type must be a struct 
that contains an integer property named 'foo'". How does that help me 
figure out what I did wrong? We can spend all day arguing over how nice 
this message is, but the truth is, what the constraint writer put in the 
constraints, and how the compiler is interpreting it, may be 2 different 
things. This helps nobody.



That is why (static) asserts have an optional string argument: to
display a clean an readable error message, instead of just dumping some
code on the user. The same thing, in my opinion, is needed for constraints.


If assert(x == 5) would just print "Error: x == 4" automatically, we 
could eliminate most needs for a message.


You could solve this with a message, but again, this is a huge task to 
undertake on ALL code in existence, rather than fixing it all to a "good 
enough" degree that we don't need the messages. And it avoids the "human 
compiler" that is prone to error.



In your example, the compiler would point at isMovable!S as the issue.
Not super-informative, but is all it gives to prevent huge outputs.
Then you tell it to print more information, and it would say that
false was returned when the m member of type T is being checked, at
which point you could get a stack trace of what values were at each
level of recursion. Everywhere a boolean evaluated to true in order to
get to the point where false is returned would be colored green, every
time it was false, it would be colored red, and every time a short
circuit happened, it wouldn't be colored.


Or the user could just read a string "This overload cannot be called,
because argument 1 (struct S) has a destructor and non-statically
initialized const members". No "then", no printing more information, no
stack traces. User is informed their type is wrong and *why* it is
wrong. If they disagree, if they think there's a bug in the constraint,
or if they're interested in how the constraint works, they're free to go
through all the hoops you

Re: DIP 1003 Formal Review

2017-05-16 Thread Jonathan M Davis via Digitalmars-d

On Tuesday, May 16, 2017 17:22:12 Timon Gehr via Digitalmars-d wrote:
> On 15.05.2017 03:18, Jonathan M Davis via Digitalmars-d wrote:
> > So, while I do like the idea of getting the word body back as an
> > identifier, what really appeals to me here is getting rid of the need
> > for it with contracts.
>
> auto foo()in{
>  assert(true);
> }out{
>  assert(true);
> }{
>  return 3;
> }
>
> Are you really arguing for this?
> I don't want to write code like this.

Well, I can't say that I like the formatting, but most definietly I am
arguing for that. Right now, just because you add contracts, you suddenly
have to add an extra keyword that is unnecessary when there are no contracts
and which is redundant. You go from having something like

auto foo(T param)
{
...
}

to something like

auto foo(T param)
in
{
assert(...);
}
out(result)
{
assert(...);
}
body
{
...
}

or

auto foo(T param)
in { assert(...); }
out(result) { assert(...); }
body
{
...
}

or however you want to format it. But the last set of braces is always the
function body just like it is when there are no contracts. And having to
have body (or function whatever other keyword we might put there) just makes
contracts that much more verbose - as well as being inconsistent with how
functions bodies are declared when there are no contracts.

Honestly, as nice as it would be to get the body keyword back as an
identifier, I care _way_ more about not having a redundant keyword for the
function body. I'd be all for removing it from contracts even if we never
got it back as an identifier. I've always found needing to add body to be
very annoying, and I frequently forget it, because it's not there normally.
It's just making contracts longer without adding extra information, and
contracts are _way_ too verbose even without the extra keyword there, let
alone with it.

IMHO, if we remove body as a keyword but replace it with something else in
contracts, we've lost out on a big opportunity for some language cleanup.

- Jonathan M Davis

rdub V2 released

2017-05-16 Thread JamesD via Digitalmars-d-announce


V2 accepts multiple files and wildcard *.d on the command line.
https://code.dlang.org/packages/rdub

RDUB is a front end for DUB, a D language build tool. It's 
designed to build source files specified on the command line, 
without having to edit the dub files: dub.json, dub.sdl, 
src/app.d, source/app.d


This tool is great for running examples and building/testing 
small projects! It's used in my other projects, dlang-beginners 
and dwtlib.


$ rdmd rdub -h

rdub is a front end for DUB, a D language build tool

rdub [-h] [path/foo.d ... path/fooN.d] | [path/*.d] [dub args]

-h --help This help information

rdub = run dub with defaults ./src/app.d or ./source/app.d

rdub path/foo.d = run dub as follows:

1. If first run, copy src to srcbak, and source to sourcebak
2. Delete src/ and source/ to avoid more than one main() file
3. Copy path/foo.d to ./src/foo.d
4. Run dub to build and run ./src/foo.d
5. Pass all [dub args] to dub, except: -h

Re: DMD now has colorized syntax highlighting in error messages

2017-05-16 Thread Walter Bright via Digitalmars-d-announce


On 5/16/2017 8:25 AM, Adam D. Ruppe wrote:

It's also possible to use underlining.


Yeah, on some systems, but not really on Windows or even all linux terminals.
Color has broader support, though you do want to be careful not to *depend* on
color either.


I've never met an ASCII console that didn't support underlining. This includes 
the ones I used back in the 1970's, and includes the tty I designed and built 
myself for a class project. It includes DOS and Windows consoles.


Underlining enjoys much broader support than color does. Color became fairly 
ubiquitous rather late, in 1990 or so. The VT-100 control sequences have 
effectively replaced all the other ones.


> my terminal emulator doesn't support blinking

Then yours is a unique snowflake, as it's standard for VT-100 emulation (xterm).

Re: DMD now has colorized syntax highlighting in error messages

2017-05-16 Thread Jonathan M Davis via Digitalmars-d-announce

On Tuesday, May 16, 2017 08:11:21 Walter Bright via Digitalmars-d-announce 
wrote:
> On 5/16/2017 7:17 AM, Adam D. Ruppe wrote:
> > So again it is NOT color that bothers me. It is OVERUSE of color for
> > stuff that isn't important to read the message which dilutes the
> > meaning of color. It isn't special anymore.
>
> Perhaps. I know I have some trouble distinguishing code from explanatory
> text in error messages, particularly when the code looks like english, as
> in:
>
>  error: undefined identifier maybe
>
> Colorizing code distinguishes it from text.
>
> The initial color choices I picked are garish on purpose, it's to try
> things out. I expect to change it to more muted ones (turn off the
> intensity bit at least). It's also possible to use underlining.
>
> I'm working on the next PR that will auto-detect if Adam is running the
> compiler, and will highlight code with blinking text.

LOL. Or you could have it just say:

"I'm sorry, Adam. I'm afraid I can't do that."

:)

https://www.youtube.com/watch?v=OEu4Iq5KL-Q

- Jonathan M Davis

Re: DMD now has colorized syntax highlighting in error messages

2017-05-16 Thread Adam D. Ruppe via Digitalmars-d-announce


On Tuesday, 16 May 2017 at 15:11:21 UTC, Walter Bright wrote:

error: undefined identifier maybe

Colorizing code distinguishes it from text.


What's important there? The generic syntax that you get from a 
syntax highlighter or the fact that it is the user input?


Drawing attention to `maybe` there is a good idea! But that's not 
because it is syntax highlighted, it is because that's the most 
important word in the message.


(btw I think it already has attention because of its placement, 
it doesn't need additional color. but the case I keep going back 
to, function overloading, puts important stuff in the middle of 
the message and that would be nice to stand out, as long as 
what's important - the mismatched arguments - are what stand out)



It's also possible to use underlining.


Yeah, on some systems, but not really on Windows or even all 
linux terminals. Color has broader support, though you do want to 
be careful not to *depend* on color either.


I'm working on the next PR that will auto-detect if Adam is 
running the compiler, and will highlight code with blinking 
text.


I'm afraid that won't work, my terminal emulator doesn't support 
blinking.


But if it detected it was me and outputted XML error messages, oh 
boy, I'd be excited about that! I honestly very much would love 
xml error messages.

Re: DIP 1003 Formal Review

2017-05-16 Thread Jonathan M Davis via Digitalmars-d-learn


On 15.05.2017 03:18, Jonathan M Davis via Digitalmars-d wrote:

So, while I do like the idea of getting the word body back as an identifier,
what really appeals to me here is getting rid of the need for it with
contracts.


auto foo()in{
assert(true);
}out{
assert(true);
}{
return 3;
}

Are you really arguing for this?
I don't want to write code like this.

Re: No tempFile() in std.file

On Tuesday, May 16, 2017 08:06:13 H. S. Teoh via Digitalmars-d-learn wrote:
> On Tue, May 16, 2017 at 06:56:57AM -0700, Jonathan M Davis via 
Digitalmars-d-learn wrote:
> > On Tuesday, May 16, 2017 11:19:14 bachmeier via Digitalmars-d-learn 
wrote:
> > > On Monday, 15 May 2017 at 22:38:15 UTC, Jonathan M Davis wrote:
> > > > I suppose that we could add a tempFile that did what
> > > > std.stdio.File.scratchFile did but create an empty file and return
> > > > its path rather than returning a File, though that would be a bit
> > > > annoying, since you'd then have to open it to operate on it
> > > > instead of just writing to it. Maybe it would be worth doing
> > > > though given the stupidity blocking std.stdio.File.scratchFile.
>
> [...]
>
> Don't forget that there are security concerns related to this.  Most
> modern OS APIs tend to prefer a temp file creation call that atomically
> (1) generates a unique filename and (2) creates a file with said
> filename with permissions set such that it can only be exclusively used
> by the calling process.
>
> The reason for this is that there is a race condition between the
> generation of the filename and the creation of the file.
[...]

Yes, which is why you use the system call that fails if the file already
exists when you open it. std.stdio.File.scratchFile dealt with all of that
(and AFAIK, did so correctly, though I could have missed something). And
we'd have it in Phobos still if it weren't for the complaints about hello
world's excecutable size. But all of the subtleties around that mess is why
we don't have a std.file.tempFile which simply returns a suggested file
name. You'd _think_ that it would be a simple issue, but unfortunately, it's
not.

- Jonathan M Davis

Re: DMD now has colorized syntax highlighting in error messages

2017-05-16 Thread H. S. Teoh via Digitalmars-d-announce

On Tue, May 16, 2017 at 08:11:21AM -0700, Walter Bright via 
Digitalmars-d-announce wrote:
> On 5/16/2017 7:17 AM, Adam D. Ruppe wrote:
> > So again it is NOT color that bothers me. It is OVERUSE of color for
> > stuff that isn't important to read the message which dilutes the
> > meaning of color. It isn't special anymore.
> 
> Perhaps. I know I have some trouble distinguishing code from
> explanatory text in error messages, particularly when the code looks
> like english, as in:
> 
> error: undefined identifier maybe
> 
> Colorizing code distinguishes it from text.
[...]

Simpler solution: print the identifier in quotes, e.g.:

 error: undefined identifier 'maybe'

There: instantly clear without needing any colors.


T

-- 
LINUX = Lousy Interface for Nefarious Unix Xenophobes.

Re: Fantastic exchange from DConf

2017-05-16 Thread Walter Bright via Digitalmars-d


On 5/5/2017 11:26 PM, Joakim wrote:

Walter: I believe memory safety will kill C.


I can't find any definitive explanation of what the Wannacry exploit is. One 
person told me it was an overflow bug, another that it was truncation from 
converting 32 to 16 bits.


Anyhow, the Wannacry disaster looks to be a very expensive lesson in using 
memory unsafe languages for critical software. I know Microsoft has worked for 
years to use their own C which is memory safer, apparently it is not enough.


https://blogs.msdn.microsoft.com/martynl/2005/10/10/annotations-yet-more-help-finding-buffer-overflows/

[Issue 17356] [Reg 2.075] __simd_sto no longer executed

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

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

https://github.com/dlang/dmd/commit/894d9950f4ff996e1342242e7e51953ac718fc01
fix Issue 17356 - [Reg 2.075] __simd_sto no longer executed

https://github.com/dlang/dmd/commit/1d29b792fe7fd2694d25544179021976e2e81184
Merge pull request #6763 from WalterBright/fix17356

fix Issue 17356 - [Reg 2.075] __simd_sto no longer executed
merged-on-behalf-of: Martin Nowak 

--

Re: Weak Eco System?

2017-05-16 Thread burber via Digitalmars-d


On Tuesday, 16 May 2017 at 14:51:29 UTC, Benro wrote:
A quick summary trying to get D and a some IDEs running on a 
Windows environment.


[...]


I've tried many different IDEs, some are alright but most don't 
have what I personally think they should have. I think if this 
language had a solid IDE similar to IntelliJ and/or Eclipse, it 
would be great. I can't blame anyone for the plugins being 
outdated or buggy because it's community ran, there isn't much 
more you can expect. I'm one of those people who depend on a good 
IDE (used Vim and Emacs maybe once or twice) and I think that D 
could get really popular if it had better IDE support.

[Issue 17356] [Reg 2.075] __simd_sto no longer executed