date:20170628

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

  Issue ID: 17571
   Summary: Cannot create alias of __traits(getMember
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: shac...@weka.io

Consider the following program:
import unistd = core.sys.posix.unistd;

alias func = __traits(getMember, unistd, "write");

When trying to compile:
test.d(3): Error: basic type expected, not __traits
test.d(3): Error: semicolon expected to close alias declaration
test.d(3): Error: declaration expected, not '__traits'

Since unistd.write is a function, there is no reason for me not to be able to
create an alias of it.

The only reason I'm marking this as a minor issue is because there is a
workaround:
import unistd = core.sys.posix.unistd;
import std.meta;

alias func = Alias!(__traits(getMember, unistd, "write"));

This, however, goes outside the definition of what std.meta.Alias was meant
for. It was meant for aliasing non-aliasable objects, not for aliasing
functions (which is what is happening in this case).

--

Re: dmd debian installation conflicts with debian-goodies

2017-06-28 Thread Seb via Digitalmars-d


On Wednesday, 28 June 2017 at 10:09:06 UTC, Ralph Amissah wrote:
Installing dmd if debian-goodies is installed fails. Both try 
to write a file named '/usr/bin/dman'


Debian Stretch is out, the freeze is over, perhaps now dmd will 
soon be
available as a package in Debian? Ldc2 does a great job but for 
testing
purposes and convenience it would be good to have the reference 
compiler.
Is there likely to be D related activity at DebCamp and DebConf 
2017, Montreal?


You probably want to join efforts and forces with Matthias Klump.

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

Though due to missing contributors not much has been packaged:

https://qa.debian.org/developer.php?login=pkg-d-devel%40lists.alioth.debian.org

However, of course there are more D packages in Debian that are 
maintained by other groups, e.g.


https://packages.debian.org/sid/libbiod-dev
https://packages.debian.org/sid/gdc
...

[Issue 17570] New: Misleading error message illegal conditional function definition

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

  Issue ID: 17570
   Summary: Misleading error message illegal conditional function
definition
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: shac...@weka.io

Consider the following program:
import std.traits;

struct S(T) {
void func() if(isIntegral!T) {
}
}

Currently, it produces the following error message:
test.d(4): Error: semicolon expected following function declaration
test.d(4): Error: declaration expected, not 'if'
test.d(7): Error: } expected following members in struct declaration at
test.d(3)

The error message it should be producing is:
test.d(4): Error: cannot use conditional definition for non-template functions.
Use "static if" instead.

--

[Issue 3031] scoped static var conflicts

2017-06-28 Thread Nick Sabalausky (Abscissa) via Digitalmars-d

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

feklushkin.de...@gmail.com changed:

   What|Removed |Added

 CC||feklushkin.de...@gmail.com

--

Re: Beta 2.075.0-b1

2017-06-28 Thread H. S. Teoh via Digitalmars-d-announce

On Wed, Jun 28, 2017 at 06:44:10PM -0700, Walter Bright via 
Digitalmars-d-announce wrote:
> On 6/27/2017 12:51 AM, Dsby wrote:
> > what about DIP1000? Is it default?
> 
> No.

I've been seeing occasional linker errors when compiling with -dip1000
that go away when I drop -dip1000. However, I haven't had the time to
reduce the code sufficiently to file a bug.  Is this a known issue, or
should I schedule some time to reduce my code and file a bug?

T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at 
it. -- Pete Bleackley

Re: Beta 2.075.0-b1

2017-06-28 Thread Dsby via Digitalmars-d-announce


On Thursday, 29 June 2017 at 01:44:10 UTC, Walter Bright wrote:

On 6/27/2017 12:51 AM, Dsby wrote:

what about DIP1000? Is it default?


No.


When will it be default? 2.076 or 2.077?

Re: Let's paint those bikesheds^Werror messages!


On 06/27/2017 10:32 AM, Vladimir Panteleev wrote:
As has been announced, DMD now has colorized syntax highlighting in 
error messages:


http://forum.dlang.org/post/of9oao$230j$1...@digitalmars.com

With 2.075's release near, now would be a good time to decide on a nice 
color palette that looks fine on most terminals. So, please vote:




Hasn't DMD already been coloring error messages for about the past year? 
Or is it DUB that's been doing that to DMD's output? Or are we talking 
about something different then what was already there?

Re: dmd debian installation conflicts with debian-goodies

2017-06-28 Thread Nick Sabalausky (Abscissa) via Digitalmars-d


On 06/28/2017 06:09 AM, Ralph Amissah via Digitalmars-d wrote:

Installing dmd if debian-goodies is installed fails. Both try to write a file
named '/usr/bin/dman'

Debian Stretch is out, the freeze is over,


Which one is "stretch"?

Re: Checked vs unchecked exceptions

2017-06-28 Thread Nick Sabalausky (Abscissa) via Digitalmars-d


On 06/25/2017 01:38 PM, mckoder wrote:

I am disappointed that D doesn't have checked exceptions.



Huh? Is it April 1st?

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

2017-06-28 Thread H. S. Teoh via Digitalmars-d

On Thu, Jun 29, 2017 at 01:22:31AM +, Mark via Digitalmars-d wrote:
[...]
> So basically, I'd like the ability to implement fairly simple
> contracts (with a similar level of sophistication to the above
> examples) that the compiler can check for me. I don't know, maybe this
> is easier to implement using UDAs...

One idea I have is that the compiler could recognize certain
straightforward contracts (like int < value) and use VRP (value range
propagation) to detect cases where it's clear that the contract would be
violated.

However, this can only be done in a very rudimentary fashion, because:

(1) DbC contracts pertain to *runtime* argument values, so while
checking for simple cases at compile-time is nice, it isn't really in
the charter of (D's implementation of) DbC.

(2) VRP in the compiler currently only works within a very limited
scope, IIRC within a single expression. So while it may detect the
`foo(bar())` case, it probably won't detect the `x=bar(); foo(x);` case.
Ostensibly the scope of VRP ought to be expanded, however:

(3) In the past Walter has shown some reluctance in adding features that
hurt compilation time; if a more sophisticated implementation of VRP is
required and it's deemed too expensive in terms of compilation time,
Walter may veto it.

(4) Arbitrarily complex boolean conditions are undecidable in general,
so unless you have a way to solve the halting problem, a general
solution is intractible.  Of course, the kind of conditions you find in
contracts generally ought to be nowhere near the halting problem in
complexity, but it's not clear how far one can go without running the
risk of (3).  My guess is that something based on VRP is the most likely
to materialize in the foreseeable future.

T

-- 
First Rule of History: History doesn't repeat itself -- historians merely 
repeat each other.

Re: Beta 2.075.0-b1

2017-06-28 Thread Walter Bright via Digitalmars-d-announce


On 6/27/2017 12:51 AM, Dsby wrote:

what about DIP1000? Is it default?


No.

GDUB v1

2017-06-28 Thread JamesD via Digitalmars-d-dwt


GDUB is a DWT GUI front end for DUB, a D language build tool.

It's designed to build source file(s) 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 - for example, the DWT Snippets!


Tested on Windows and Posix (Ubuntu).

Screen shots here:

https://code.dlang.org/packages/gdub

[Issue 17352] [REG 2.075a] Internal error: ddmd/backend/elfobj.c 1739 on duplicate definition

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

--- Comment #6 from Martin Nowak  ---
cat > bug.d << CODE
void bug(Args...)()
{
}

void test(bool coin)
{
if (coin)
{
string foobar;
bug!foobar();
}
else
{
string foobar;
bug!foobar();
}
}
CODE

dmd -c bug.d

Internal error: ddmd/backend/elfobj.c 1739


This is a real instance of this bug caused by ambiguous mangling of local
variables (see issue 14831).

Interestingly enough `void bug(alias var)()` only outputs a single template
instance :o.

--

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

2017-06-28 Thread Mark via Digitalmars-d


On Tuesday, 27 June 2017 at 23:17:15 UTC, Moritz Maxeiner wrote:
Considering that code is read a lot more than written those two 
are *critically* important.
What more do you expect? It could eventually be optimized to 
inject the in contract check at the caller's side (before 
entering the function), but the point of contracts is that they 
*aren't* violated. If they are, well, your program[1] is broken 
and needs to die.


[1] abstract: computational task; implementation barring safe 
thread/fiber killing: process


Sure, but it would be even better if it hadn't compiled in the 
first place. For instance, the "pure" attribute is a sort of 
contract, and if a function designated "pure" modifies global 
state then my code *does not compile*. Furthermore, if a pure 
function foo() contains a call to a function bar() not designated 
"pure", then it doesn't compile either, even though bar() may in 
fact be pure. So the compiler's behavior is "I can't guarentee 
that this function is pure, therefore I refuse to compile". In 
other words, I get useful error-checking from the compiler at the 
cost of having to "help" him a bit from time to time (like 
designating bar() as pure in this example).


The above behavior is unreasonable for validating a completely 
general contract - the compiler won't be able to guarentee much 
without excessive effort on the part of the programmer, supplying 
it with informative preconditions and postconditions. 
Nevertheless, as attributes like pure, const, safe and nogc 
demonstrate, the compiler can be of great help in writing correct 
code. Detecting violations of these function attributes in 
run-time is trivial but far less useful.


So basically, I'd like the ability to implement fairly simple 
contracts (with a similar level of sophistication to the above 
examples) that the compiler can check for me. I don't know, maybe 
this is easier to implement using UDAs...

Re: Force usage of double (instead of higher precision)

2017-06-28 Thread kinke via Digitalmars-d-learn


On Wednesday, 28 June 2017 at 22:16:48 UTC, Simon Bürger wrote:

I am currently using LDC on 64-bit-Linux if that is relevant.


It is, as LDC on Windows/MSVC would use 64-bit compile-time 
reals. ;)


Changing it to double on other platforms is trivial if you 
compile LDC yourself. You'll want to use this alias: 
https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.d#L19, https://github.com/ldc-developers/ldc/blob/master/ddmd/root/ctfloat.h#L19

Re: Force usage of double (instead of higher precision)

2017-06-28 Thread Stefan Koch via Digitalmars-d-learn


On Wednesday, 28 June 2017 at 23:56:42 UTC, Stefan Koch wrote:


As for your problems they can be worked around.
by assigning every temporary to a variable.
Which will enforce the discarding of precision.


Sorry for the misinformation!
I was using the newCTFE fork which fixes this.
Indeed you'll have no way to get rid of the excess precision 
except for creating a function per sub-expression.

Re: Force usage of double (instead of higher precision)

2017-06-28 Thread Stefan Koch via Digitalmars-d-learn


On Wednesday, 28 June 2017 at 22:16:48 UTC, Simon Bürger wrote:

(If you are interested in the "double double" type, take a look 
here:

https://github.com/BrianSwift/MetalQD
which includes a double-double and even quad-double 
implementation in C/C++/Fortran)


Nice work can you re or dual license under the boost license ?
I'd like to incorporate the qd type into newCTFE.

As for your problems they can be worked around.
by assigning every temporary to a variable.
Which will enforce the discarding of precision.

Re: Always false float comparisons

2017-06-28 Thread Timon Gehr via Digitalmars-d


On 14.05.2016 02:49, Timon Gehr wrote:

On 13.05.2016 23:35, Walter Bright wrote:

On 5/13/2016 12:48 PM, Timon Gehr wrote:

IMO the compiler should never be allowed to use a precision different
from the one specified.


I take it you've never been bitten by accumulated errors :-)
...


If that was the case it would be because I explicitly ask for high 
precision if I need it.


If the compiler using or not using a higher precision magically fixes an 
actual issue with accumulated errors, that means the correctness of the 
code is dependent on something hidden, that you are not aware of, and 
that could break any time, for example at a time when you really don't 
have time to track it down.



Reduced precision is only useful for storage formats and increasing
speed.  If a less accurate result is desired, your algorithm is wrong.


Nonsense. That might be true for your use cases. Others might actually 
depend on IEE 754 semantics in non-trivial ways. Higher precision for 
temporaries does not imply higher accuracy for the overall computation.


E.g., correctness of double-double arithmetic is crucially dependent on 
correct rounding semantics for double:

https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic


We finally have someone on D.learn who is running into this exact problem:

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

[Issue 17559] [REG2.073.0] Wrong line number in stack trace

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

--- Comment #6 from Vladimir Panteleev  ---
How do you define a regression? If something worked and now it doesn't work
then it's a regression from the user's perspective. When latent bugs are
exposed by some change or another, it doesn't matter how long said bugs were
there.

--

[Issue 17559] [REG2.073.0] Wrong line number in stack trace

2017-06-28 Thread Sönke Ludwig via Digitalmars-d-announce

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #5 from Walter Bright  ---
This is not a regression. The code deleted by
https://github.com/dlang/dmd/pull/6947 has been there for 30 years.

--

Force usage of double (instead of higher precision)

2017-06-28 Thread Simon Bürger via Digitalmars-d-learn

According to the standard (http://dlang.org/spec/float.html), the 
compiler is allowed to compute any floating-point statement in a 
higher precision than specified. Is there a way to deactivate 
this behaviour?


Context (reason why I need this): I am building a "double double" 
type, which essentially takes two 64-bit double-precision numbers 
to emulate a (nearly) quadruple-precision number. A simplified 
version looks something like this:


struct ddouble
{
double high;
double low;

invariant
{
assert(high + low == high);
}

// ...implemententations of arithmetic operations...
}

Everything works fine at run-time, but if I declare a 
compile-time constant like


enum pi = ddouble(3.141592653589793116e+00, 
1.224646799147353207e-16);


the invariant fails because it is evaluated using 80-bit 
"extended precision" during CTFE. All arithmetic operations rely 
on IEEE-conform double-precision, so everything breaks down if 
the compiler decides to replace them with higher precision. I am 
currently using LDC on 64-bit-Linux if that is relevant.


(If you are interested in the "double double" type, take a look 
here:

https://github.com/BrianSwift/MetalQD
which includes a double-double and even quad-double 
implementation in C/C++/Fortran)

Release candidates vibe.d 0.8.0-rc.3 and vibe-core 1.0.0-rc.3

Building on DMD 2.075.0-b1, as well as 
https://github.com/rejectedsoftware/vibe.d/issues/1757 have been fixed 
and the third release candidate has been tagged. The new release date is 
Wednesday the 5th of July.

[Issue 17523] Sporadic ICEs with inline asm

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

--- Comment #18 from Vladimir Panteleev  ---
(In reply to Vladimir Panteleev from comment #15)
> I'm going to bisect what caused the behaviour change, just to ensure that
> the bug disappeared because of a codegen fix, and not because some random
> change made it no longer manifest for that test case.

Done. Bisecting the version to bootstrap DMD really put Digger to the test, and
I needed to make some upgrades :)

The bug was fixed in this PR:

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

It does seem to be a fix in the backend, but it fixes an ICE, not resulting
codegen. Does that make sense to you?

--

Re: dub seems to have forgotten my versions


On Wednesday, 28 June 2017 at 20:18:20 UTC, jmh530 wrote:

On Wednesday, 28 June 2017 at 19:54:01 UTC, jmh530 wrote:

[snip]


Does not seem to be a problem for another project using dub 
with dmd and similar dependencies...


After spending some time looking through the dub issues, I found 
that you can use
the option --nodeps effectively as an offline mode. The code 
compiles with --nodeps, but still fails without it.

Re: Let's paint those bikesheds^Werror messages!

2017-06-28 Thread Mike Wey via Digitalmars-d


On 28-06-17 01:34, Moritz Maxeiner wrote:


All these can even do true colors on Windows:
- 
https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-bit-color-in-the-windows-console/ 



On Windows 10, and in that case you can even use the vt100 escape 
sequences: 
https://msdn.microsoft.com/en-us/library/windows/desktop/mt638032(v=vs.85).aspx



--
Mike Wey

Re: dub seems to have forgotten my versions


On Wednesday, 28 June 2017 at 19:54:01 UTC, jmh530 wrote:

[snip]


Does not seem to be a problem for another project using dub with 
dmd and similar dependencies...

Re: My simple implementation of PHP strip_tags()

On Wednesday, 28 June 2017 at 19:58:31 UTC, Vladimir Panteleev 
wrote:

On Wednesday, 28 June 2017 at 19:50:44 UTC, aberba wrote:
Please read this ASAP: 
https://en.wikipedia.org/wiki/Cross-site_scripting


Ha ha. I will strip out

Re: Phobos PR in need of review/merge

2017-06-28 Thread Walter Bright via Digitalmars-d


On 6/27/2017 2:39 PM, Dukc wrote:

On Tuesday, 27 June 2017 at 19:40:52 UTC, Brad Roberts wrote:
There's a very good reason to leave requests open:  a closed request is gone, 
never to be seen again.


Well explained. So I quess that next time I should just leave a post there that 
I'm abandoning it. After many pings and a notification at forum of course.
Abandoning it is fine. But please don't close good work! Brad is right. The time 
may not be right for it yet, but closing it means it will never be looked at again.

Re: My simple implementation of PHP strip_tags()

2017-06-28 Thread Vladimir Panteleev via Digitalmars-d


On Wednesday, 28 June 2017 at 19:50:44 UTC, aberba wrote:
Please read this ASAP: 
https://en.wikipedia.org/wiki/Cross-site_scripting


Ha ha. I will strip out

[Issue 17567] make shared methods callable on unshared objects (and covariant)

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
(In reply to Martin Nowak from comment #2)
> It already seemed too simple to work out :).

We worked out the rules for implicit conversions (used for
covariance/contravariance) back when we came up with const/shared/etc. It's
best to derive these in isolation, and then apply them without needing to work
it out again.

(It's a lot like using the chain rule for derivatives. Derive the chain rule,
prove it's correct, then just apply it as a given.)

I've gone through the same process with scope conversions. I kept confusing
myself until I finally sat down and worked up a chart with the rules, convinced
myself that that was correct, and then just applied them without worrying about
it.

--

Re: My simple implementation of PHP strip_tags()

On Wednesday, 28 June 2017 at 19:21:35 UTC, Vladimir Panteleev 
wrote:

On Wednesday, 28 June 2017 at 19:14:19 UTC, aberba wrote:
I'm already using prepared statements thoroughly. strip_tags() 
has its own uses beside making it safe for db storage.


Nothing to do with DB storage! XSS and SQL injections are two 
very distinct classes of vulnerabilities.


Please read this ASAP: 
https://en.wikipedia.org/wiki/Cross-site_scripting


Ha ha. I will strip out

dub seems to have forgotten my versions

I am behind a corporate firewall at work so I have to manually 
install dub packages. This requires setting the version manually, 
otherwise master is inferred. This was working great until I had 
ended a dub run command early. Now dub seems to have forgotten 
that the versions are in there. It's weird because dub list has 
them.




C:\ProgrammingFiles\DFiles\testing\testing_mir_glas>dub list
Packages present in the system and known to dub:
  nlopt 0.1.0: C:\ProgrammingFiles\DFiles\nlopt\
  mir-algorithm 0.6.6: 
C:\ProgrammingFiles\DFiles\dubFolder\mir-algorithm-0.6.6\


  lubeck 0.0.3: C:\ProgrammingFiles\DFiles\dubFolder\lubeck-0.0.3\
  [snip]

and the local-packages.json has entries like

{
"name": "nlopt",
"version": "0.1.0",
"path": "C:\\ProgrammingFiles\\DFiles\\nlopt\\"
},

but trying to build it cannot determine the version and assumes 
master (below). My sense is that I need to remove dub and 
local.packages.json and re-install everything. This process would 
be faster if dub weren't spending all this time trying and 
failing to download files. I wish I could tell it not to bother 
going online.


C:\ProgrammingFiles\DFiles\testing\testing_mir_glas>dub build 
--compiler=ldmd2 -

-verbose
Using dub registry url 'http://code.dlang.org/'
Refreshing local packages (refresh existing: true)...
Looking for local package map at 
C:\ProgramData\dub\packages\local-packages.json


Looking for local package map at 
C:\Users\[user]\AppData\Roaming\dub\packages\l

ocal-packages.json
Try to load local package map at 
C:\Users\[user]\AppData\Roaming\dub\packages\l

ocal-packages.json
Note: Failed to determine version of package mir-algorithm at .. 
Assuming ~maste

r.
Note: Failed to determine version of package lubeck at .. 
Assuming ~master.
Note: Failed to determine version of package mir-cpuid at .. 
Assuming ~master.
Note: Failed to determine version of package mir-glas at .. 
Assuming ~master.
Note: Failed to determine version of package mir-lapack at .. 
Assuming ~master.
Note: Failed to determine version of package mir-random at .. 
Assuming ~master.
Note: Failed to determine version of package scid at .. Assuming 
~master.
Note: Failed to determine version of package cblas at .. Assuming 
~master.
Note: Failed to determine version of package lapack at .. 
Assuming ~master.
Note: Failed to determine version of package numir at .. Assuming 
~master.
Note: Failed to determine version of package drepl at .. Assuming 
~master.
Note: Failed to determine version of package colorize at .. 
Assuming ~master.
Note: Failed to determine version of package libdparse at .. 
Assuming ~master.
Note: Failed to determine version of package linenoise at .. 
Assuming ~master.
Note: Failed to determine version of package drepl at .. Assuming 
~master.
Note: Failed to determine version of package mir-blas at .. 
Assuming ~master.
Note: Failed to determine version of package rdub at .. Assuming 
~master.
Note: Failed to determine version of package testing_mir_glas at 
.. Assuming ~ma

ster.
The determined compiler type "ldc" doesn't match the expected 
type "dmd". This w

ill probably result in build errors.
Refreshing local packages (refresh existing: false)...
Looking for local package map at 
C:\ProgramData\dub\packages\local-packages.json


Looking for local package map at 
C:\Users\[user]\AppData\Roaming\dub\packages\l

ocal-packages.json
Try to load local package map at 
C:\Users\[user]\AppData\Roaming\dub\packages\l

ocal-packages.json
Note: Failed to determine version of package mir-algorithm at .. 
Assuming ~maste

r.
Note: Failed to determine version of package lubeck at .. 
Assuming ~master.
Note: Failed to determine version of package mir-cpuid at .. 
Assuming ~master.
Note: Failed to determine version of package mir-glas at .. 
Assuming ~master.
Note: Failed to determine version of package mir-lapack at .. 
Assuming ~master.
Note: Failed to determine version of package mir-random at .. 
Assuming ~master.
Note: Failed to determine version of package scid at .. Assuming 
~master.
Note: Failed to determine version of package cblas at .. Assuming 
~master.
Note: Failed to determine version of package lapack at .. 
Assuming ~master.
Note: Failed to determine version of package numir at .. Assuming 
~master.
Note: Failed to determine version of package drepl at .. Assuming 
~master.
Note: Failed to determine version of package colorize at .. 
Assuming ~master.
Note: Failed to determine version of package libdparse at .. 
Assuming ~master.
Note: Failed to determine version of package linenoise at .. 
Assuming ~master.
Note: Failed to determine version of package drepl at .. Assuming 
~master.
Note: Failed to determine version of package mir-blas at .. 
Assuming ~master.
Note: Failed to determine version of package rdub at .. Assuming 
~master.
Note: Failed to determine version of package testing_mir_glas at 
.. Assuming ~ma

ster.
  Found dependency

Re: Relative lflag paths in dub on Windows


On Wednesday, 28 June 2017 at 00:22:56 UTC, Mike Parker wrote:

On Wednesday, 28 June 2017 at 00:16:23 UTC, Mike Parker wrote:

On Tuesday, 27 June 2017 at 19:07:49 UTC,

You have to specify the appropriate linker option, e.g. 
-L-option. For gcc, that happens to -L, so you get -L-L. For 
optlink it's +something and for the MS linker it's /something. 
I'm on my phone else I'd look it up.


Optlink instructions at [1]: -L+path\
MS linker [2]: -L/LIBPATH:path

[1] 
https://wiki.dlang.org/Compiling_and_linking_with_DMD_on_Windows


[2] 
https://docs.microsoft.com/en-us/cpp/build/reference/libpath-additional-libpath


I appreciate you posting this. I had found the /LIBPATH, but dub 
randomly crapped out on me before I was about to test it, so I'm 
going to start another thread just on that...

[Issue 17224] Foreach documentation still refers to TypeTuples, rather than AliasSequences

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

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

https://github.com/dlang/phobos/commit/f381477bdcc647a739d16d3cbf5bf9c417526320
Issue 17224 - Foreach documentation still refers to TypeTuples, rather than
AliasSequences

https://github.com/dlang/phobos/commit/32b53346ff1930ac600fabc6c70352e861d28838
Merge pull request #5484 from wilzbach/fix-17224

Issue 17224 - Foreach documentation still refers to TypeTuples, rather than
AliasSequences
merged-on-behalf-of: Jack Stouffer 

--

Re: My simple implementation of PHP strip_tags()

2017-06-28 Thread Vladimir Panteleev via Digitalmars-d


On Wednesday, 28 June 2017 at 19:14:19 UTC, aberba wrote:
I'm already using prepared statements thoroughly. strip_tags() 
has its own uses beside making it safe for db storage.


Nothing to do with DB storage! XSS and SQL injections are two 
very distinct classes of vulnerabilities.


Please read this ASAP: 
https://en.wikipedia.org/wiki/Cross-site_scripting

Re: My simple implementation of PHP strip_tags()

2017-06-28 Thread Adam D. Ruppe via Digitalmars-d


On Wednesday, 28 June 2017 at 19:14:19 UTC, aberba wrote:
I'm already using prepared statements thoroughly. strip_tags() 
has its own uses beside making it safe for db storage.


prepared statements fight sql injection at save time. HTML 
encoding is about fighting XSS when displaying stuff to the 
browser.


XSS is when some user inserts a script on your site that another 
user then sees and executes as them.


Personally, I'd never use a strip_tags function. I'd actually 
parse the html, work on a dom level, then reoutput it with proper 
encoding for whatever context it is being used in.

Re: My simple implementation of PHP strip_tags()

On Wednesday, 28 June 2017 at 18:51:41 UTC, Vladimir Panteleev 
wrote:

On Wednesday, 28 June 2017 at 18:08:12 UTC, aberba wrote:

I wanted strip_tags() for sanitization


Careful. If you don't implement this correctly (and it may be 
surprisingly difficult to), you may expose your site to XSS 
attacks.


Instead of stripping tags, you may want to encode HTML entities 
instead ('<' -> "" etc.)



auto regex = ctRegex!(``);


This will not capture

Re: My simple implementation of PHP strip_tags()

2017-06-28 Thread Vladimir Panteleev via Digitalmars-d


On Wednesday, 28 June 2017 at 18:08:12 UTC, aberba wrote:

I wanted strip_tags() for sanitization


Careful. If you don't implement this correctly (and it may be 
surprisingly difficult to), you may expose your site to XSS 
attacks.


Instead of stripping tags, you may want to encode HTML entities 
instead ('<' -> "" etc.)



auto regex = ctRegex!(``);


This will not capture

My simple implementation of PHP strip_tags()

I wanted strip_tags() for sanitization in vibe.d and I set out 
for algorithms on how to do it and came across this JavaScript 
library at 
https://github.com/ericnorris/striptags/blob/master/src/striptags.js which is quite popular judging by the number of likes and forks. As a looked through, I didn't like the cumbersome approach it used so I tried to implement it in my own way. This is what I lazily did. It turns out to be so simple that I thought I could use some opinion. Notice I didn't add `tag_replacement` param but that's just like one line of code.


string stripTags(string input, in string[] allowedTags = [])
{
import std.regex: Captures, replaceAll, ctRegex;

auto regex = ctRegex!(``);

string regexHandler(Captures!(string) match)
{
string insertSlash(in string tag)
in
{
		assert(tag.length, "Argument must contain one or more 
characters");

}
body
{
return tag[0..1] ~ "/" ~ tag[1..$];
}

bool allowed = false;
foreach (tag; allowedTags)
{
if (tag == match.hit || insertSlash(tag) == match.hit)
{
allowed = true;
break;
}
}
return allowed ? match.hit : "";
}

return input.replaceAll!(regexHandler)(regex);
}

unittest
{
assert(stripTags("bold") == "bold");
	assert(stripTags("bold", [""]) == 
"bold");

}



I'm not sure the tags matching regex I used is the best though.

Re: dmd debian installation conflicts with debian-goodies

2017-06-28 Thread H. S. Teoh via Digitalmars-d

On Wed, Jun 28, 2017 at 06:09:06AM -0400, Ralph Amissah via Digitalmars-d wrote:
> Installing dmd if debian-goodies is installed fails. Both try to write a file
> named '/usr/bin/dman'
[...]

I filed a bug for you:

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

(Next time, please file a bug directly at https://issues.dlang.org/, as
problems reported on the forum may get overlooked / forgotten.)

This is a pretty major issue IMO, because this gratuitous conflict with
an unfortunately-named, marginal utility can be a big turnoff for Debian
users who may be wanting to try out D for the first time.  The last
thing we need is for something I doubt anyone (other than certain D
devs) actually uses to become a reason to turn away from D, just because
by random chance he also has the debian-goodies package installed.

T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry

[Issue 17569] New: Rename dman in the Debian .deb package to prevent conflict with Debian package debian-goodies

2017-06-28 Thread Paolo Invernizzi via Digitalmars-d-announce

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

  Issue ID: 17569
   Summary: Rename dman in the Debian .deb package to prevent
conflict with Debian package debian-goodies
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

This was reported on the forum:


Installing dmd if debian-goodies is installed fails. Both try to write a file
named '/usr/bin/dman'

[...snip...]

sudo dpkg -i dmd_2.074.1-0_amd64.1.deb
(Reading database ... 224610 files and directories currently installed.)
Preparing to unpack dmd_2.074.1-0_amd64.1.deb ...
Unpacking dmd (2.074.1-0) ...
dpkg: error processing archive dmd_2.074.1-0_amd64.1.deb (--install):
 trying to overwrite '/usr/bin/dman', which is also in package debian-goodies
0.74
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

sudo dpkg -i dmd_2.075.0~b1-0_amd64.deb
(Reading database ... 224610 files and directories currently installed.)
Preparing to unpack dmd_2.075.0~b1-0_amd64.deb ...
Unpacking dmd (2.075.0~b1-0) ...
dpkg: error processing archive dmd_2.075.0~b1-0_amd64.deb (--install):
 trying to overwrite '/usr/bin/dman', which is also in package debian-goodies
0.74
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)


The package debian-goodies also ships a binary named `dman`, with this
description:

-
  dman   - Fetch manpages from online manpages.debian.org service
-

Since this is something shipped with Debian itself, I recommend either (1)
renaming our dman utility to something less ambiguous, or (2) excluding it from
the .deb package for dmd altogether.

And on that note, just in case, I highly recommend *against* putting a
Conflicts: line in the debian/control file, because there is no good reason why
the debian-goodies package should be excluded by the dmd package. If anything,
we should be the ones to give up the dman utility (I have never found a need
for it, and I question whether anyone actually uses it besides the D
developers).

I'm marking this as a major bug, because the conflict means that any Debian
user who wants to try out D for the first time may get immediately turned away
by the installation failure due to some silly marginal utility being
unfortunately named, just because he happens to have the debian-goodies package
installed.

--

dmd debian installation conflicts with debian-goodies

2017-06-28 Thread Ralph Amissah via Digitalmars-d

Installing dmd if debian-goodies is installed fails. Both try to write a file
named '/usr/bin/dman'

Debian Stretch is out, the freeze is over, perhaps now dmd will soon be
available as a package in Debian? Ldc2 does a great job but for testing
purposes and convenience it would be good to have the reference compiler.
Is there likely to be D related activity at DebCamp and DebConf 2017, Montreal?

* failed attempt to install dmd with debian-goodies installed

sudo dpkg -i dmd_2.074.1-0_amd64.1.deb
(Reading database ... 224610 files and directories currently installed.)
Preparing to unpack dmd_2.074.1-0_amd64.1.deb ...
Unpacking dmd (2.074.1-0) ...
dpkg: error processing archive dmd_2.074.1-0_amd64.1.deb (--install):
 trying to overwrite '/usr/bin/dman', which is also in package debian-goodies 
0.74
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

sudo dpkg -i dmd_2.075.0~b1-0_amd64.deb
(Reading database ... 224610 files and directories currently installed.)
Preparing to unpack dmd_2.075.0~b1-0_amd64.deb ...
Unpacking dmd (2.075.0~b1-0) ...
dpkg: error processing archive dmd_2.075.0~b1-0_amd64.deb (--install):
 trying to overwrite '/usr/bin/dman', which is also in package debian-goodies 
0.74
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

* debian-goodies

information on debian-goodies (the package dmd conflicts with):

apt show debian-goodies
Package: debian-goodies
Version: 0.74
Priority: optional
Section: utils
Maintainer: Javier Fernández-Sanguino Peña 
Installed-Size: 199 kB
Depends: curl, dctrl-tools | grep-dctrl, perl, python3, whiptail | dialog
Recommends: lsof
Suggests: lsb-release, popularity-contest, xdg-utils, zenity
Conflicts: debget
Replaces: debget
Tag: implemented-in::python, interface::commandline, role::program,
 scope::utility, suite::debian, use::searching, works-with::bugs,
 works-with::software:package
Download-Size: 73.4 kB
APT-Manual-Installed: yes
APT-Sources: http://ftp.ch.debian.org/debian unstable/main amd64 Packages
Description: Small toolbox-style utilities for Debian systems
 These programs are designed to integrate with standard shell tools,
 extending them to operate on the Debian packaging system.
 .
  dgrep  - Search all files in specified packages for a regex
  dglob  - Generate a list of package names which match a pattern
 .
 These are also included, because they are useful and don't justify
 their own packages:
 .
  debget - Fetch a .deb for a package in APT's database
  dpigs  - Show which installed packages occupy the most space
  debman - Easily view man pages from a binary .deb without
   extracting
  debmany- Select manpages of installed or uninstalled packages
  dman   - Fetch manpages from online manpages.debian.org service
  checkrestart   - Help to find and restart processes which are using old
   versions of upgraded files (such as libraries)
  popbugs- Display a customized release-critical bug list based
   on packages you use (using popularity-contest data)
  which-pkg-broke- find which package might have broken another
  check-enhancements - find packages which enhance installed packages

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

2017-06-28 Thread MysticZach via Digitalmars-d


On Wednesday, 28 June 2017 at 14:33:52 UTC, Moritz Maxeiner wrote:
The DIP is still at pre-preliminary review round 1 (since it 
hasn't finished yet).
The current syntax proposal is effectively emergent through H. 
S. Teoh's general proposal [1], Solomon E's out enhancement 
[2], and Timon Gehr's implementation of the former two [3].
You can see in Timon's examples [4] how it looks (and contracts 
are part of a function's signature).


Yes, this thread has been incredibly productive, and has resulted 
in a complete metamorphosis of my original proposal, into a 
proposal that I think is very strong. I have to rewrite the 
existing DIP to reflect that.

Re: CTFE Status 2

2017-06-28 Thread H. S. Teoh via Digitalmars-d

On Wed, Jun 28, 2017 at 04:19:02PM +, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
> 
> Hi There,
> 
> I just wrote the first parts of the ctfe debugger.
> Ctfe-Breakpoints are working :)
> 
> It looks like we will be able to have greatly enhanced debugging
> experience soon.
> (okay soonish ... since there are still a few tricky details to work out.)

Awesome!


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.

Re: CTFE Status 2

2017-06-28 Thread Stefan Koch via Digitalmars-d


On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:

[ ... ]


Hi There,

I just wrote the first parts of the ctfe debugger.
Ctfe-Breakpoints are working :)

It looks like we will be able to have greatly enhanced debugging 
experience soon.
(okay soonish ... since there are still a few tricky details to 
work out.)

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

2017-06-28 Thread John Burton via Digitalmars-d-learn


On Tuesday, 27 June 2017 at 09:54:19 UTC, John Burton wrote:
I'm coming from a C++ background so I'm not too used to garbage 
collection and it's implications. I have a function that 
creates a std.socket.Socket using new and connects to a tcp 
server, and writes some stuff to it. I then explicitly close 
the socket, and the socket object goes out of scope.





Am I doing this right? Or is there a better way to do this in D?

Thanks.



For my use case here, I'm increasingly thinking that just calling 
the underlying 'C' socket and send calls is better. No need for 
anything complicated at all for my actual program :)

Re: Release candidates vibe.d 0.8.0-rc.2 and vibe-core 1.0.0-rc.2


On Wednesday, 28 June 2017 at 08:37:40 UTC, Andre Pany wrote:

On Tuesday, 27 June 2017 at 09:20:40 UTC, Sönke Ludwig wrote:

Am 22.06.2017 um 10:55 schrieb Sönke Ludwig:
There have been some minor fixes and vibe.d 0.8.0-rc.2 and 
vibe-core 1.0.0-rc.2 have been tagged. The final release is 
rescheduled for Monday, July the 3rd.




Still not able to use it for this [1] ...
Works fine in Vibe 0.7.31 with libevent ...

/Paolo

[1] https://github.com/rejectedsoftware/vibe.d/issues/1757

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

2017-06-28 Thread jmh530 via Digitalmars-d


On Wednesday, 28 June 2017 at 14:09:40 UTC, Enamex wrote:


It has the already used `typeof(return)` going for it, though.



That's why I had suggested it above. However, I think the point 
they raised about parsing in response was a good one.

[Issue 17568] [scope] addresses to fields can be escaped from scope method

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||safe
 CC||ag0ae...@gmail.com

--

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

2017-06-28 Thread Moritz Maxeiner via Digitalmars-d


On Wednesday, 28 June 2017 at 14:09:40 UTC, Enamex wrote:
On Wednesday, 28 June 2017 at 12:34:59 UTC, Moritz Maxeiner 
wrote:

On Wednesday, 28 June 2017 at 12:17:36 UTC, Enamex wrote:

R foo(Args...)(Args args) {
out(return > bar && ensured(return), "foo() fudged its 
return");


Contracts inside function bodies should not be allowed imho.


I was going with the current 'Proposal' syntax in the DIP's 
document. There a more recent proposal here?


The DIP is still at pre-preliminary review round 1 (since it 
hasn't finished yet).
The current syntax proposal is effectively emergent through H. S. 
Teoh's general proposal [1], Solomon E's out enhancement [2], and 
Timon Gehr's implementation of the former two [3].
You can see in Timon's examples [4] how it looks (and contracts 
are part of a function's signature).


[1] 
http://forum.dlang.org/post/mailman.3511.1497981037.31550.digitalmar...@puremagic.com
[2] 
http://forum.dlang.org/post/xtimtynqeuzmgaych...@forum.dlang.org

[3] http://forum.dlang.org/post/oijl5f$20fv$1...@digitalmars.com
[4] 
https://github.com/dlang/dmd/compare/master...tgehr:contract-syntax#diff-0630cf91becfdb077688ebd1ef400c5a

[Issue 17568] [scope] addresses to fields can be escaped from scope method

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

Martin Nowak  changed:

   What|Removed |Added

   Priority|P1  |P2
   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|enhancement |normal

--

[Issue 17568] New: [scope] addresses to fields can be escaped from scope method

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

  Issue ID: 17568
   Summary: [scope] addresses to fields can be escaped from scope
method
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
int* p;
struct T
{
int a;
void escape() @safe scope
{
p = 
}
}

void escape() @safe
{
{
T t;
t.escape;
}
auto bug = *p;
}
CODE
dmd -c -dip1000 bug

Tested with v2.075.0-b1

--

Re: Win10 defender still sees dmd.exe and rdmd.exe as malicious

2017-06-28 Thread Mike Parker via Digitalmars-d


On Monday, 26 June 2017 at 02:55:17 UTC, Matt wrote:
Which version of the compiler? Which version of Windows? I'm 
on Windows 10 with 2.074.1 currently and never seen it with 
any version of DMD.


DMD is 2.074.1, windows10 pro (10.0.14393)


Is it the same issue as the one reported at [1]? If so, please 
add a comment there specifying which download you used (the 
installer or the zip). If not, please file a new issue.


[1] https://issues.dlang.org/show_bug.cgi?id=16405

[Issue 17567] make shared methods callable on unshared objects (and covariant)

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

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Martin Nowak  ---
(In reply to Andrei Alexandrescu from comment #1)
> At this point we have threads getting shared access to x, but the current
> thread believes x is unshared.

It already seemed too simple to work out :).
So this would only work with some inout flavor of shared which likely wouldn't
be worth the trouble.

--

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

2017-06-28 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 28 June 2017 at 13:19:37 UTC, Guillaume Piolat 
wrote:



https://forum.dlang.org/post/pmulowxpikjjffkrs...@forum.dlang.org

Not an issue with DerelictUtil, an issue with the strategy of 
closing resources in GC with this case.


Derelict loaders work-around this by not unloading shared 
libraries so the GC won't unload shared libs before the 
resources related to the shared library are freed.


https://github.com/DerelictOrg/DerelictAL/blob/master/source/derelict/openal/dynload.d#L366


Yeah, the loaders all used to needlessly unload the shared 
libraries in a static destructor. The fact that they don't 
anymore isn't to avoid any GC/destructor issues, but because 
there's no point in unloading the libraries when the system is 
going to do it anyway.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

2017-06-28 Thread Enamex via Digitalmars-d


On Wednesday, 28 June 2017 at 12:34:59 UTC, Moritz Maxeiner wrote:

On Wednesday, 28 June 2017 at 12:17:36 UTC, Enamex wrote:

`out(return > 0, "message")`?


Yes, see [1]


It has the already used `typeof(return)` going for it, though.

A big point against it IMO would be its moving further from 
`return`'s
signal that a function scope is exited at that line (instead it 
could
be a variable assignment which is meh (usage in a contract check 
is OK

since we're already outside the function)).


`out(someCond($), "message")`?


Overloading symbols with context dependent meaning is one more 
step into obfuscation.


True.

So using either `out` or `return` or `$` or whatever to always 
refer to the return value of the function. Just something 
that's already relevant and used instead of `__result`.


Well, `__result` is already implemented and usable, so I would 
argue it is thus relevant.


It's not used in the wild yet though :T


R foo(Args...)(Args args) {
out(return > bar && ensured(return), "foo() fudged its 
return");


Contracts inside function bodies should not be allowed imho.

[1] http://forum.dlang.org/post/oihbot$134s$1...@digitalmars.com


I was going with the current 'Proposal' syntax in the DIP's 
document. There

a more recent proposal here?

[Issue 17567] make shared methods callable on unshared objects (and covariant)

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #1 from Andrei Alexandrescu  ---
This is not possible. Thanks Timon Gehr for explaining this to me. Consider:

shared int* p;

struct S
{
  int x;
  void func() shared { p =  }
}

void bug()
{
auto p = new S;
p.func;
++p.x;
}

At this point we have threads getting shared access to x, but the current
thread believes x is unshared.

--

[Issue 17560] Enhancement: view and copy full code example for offline compile/play

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

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

https://github.com/dlang/dlang.org/commit/72f109646392dd412e77dc6db1a2cbe34285c9a2
Add 'Open in editor' button for runnable code examples

Fix Issue 17560 - Enhancement: view and copy full code example for offline
compile/play

--

[Issue 17567] New: make shared methods callable on unshared objects (and covariant)

2017-06-28 Thread Moritz Maxeiner via Digitalmars-d-learn

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

  Issue ID: 17567
   Summary: make shared methods callable on unshared objects (and
covariant)
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
struct S
{
  void func() shared {}
}

void bug()
{
S s;
s.func;
}
dmd -c bug

bug.d(9): Error: shared method bug.S.func is not callable using a non-shared
object

cat > bug2.d << CODE
interface I
{
void func();
}
class C : I
{
void func() shared {}
}
CODE
dmd -c bug

bug.d(5): Error: class bug.C interface function 'void func()' is not
implemented


Both of these use-cases should be supported. Shared on a methods guarantees
thread-safety which is compatible with being used in an unshared manner.
Therefor shared methods should be fully covariant to unshared methods.

This does not touch shared as type qualifier, `shared(T)` means the type is
shared between threads, and hence is obviously not convertible to `T`.

Looks like this would be the first storage class where we'd support covariance
and real overloading.
While overloading, e.g. `nothrow` and non-`nothrow` methods is not an error,
the compiler always prefers `nothrow`, `pure`, `@safe`, or `@nogc` methods.
But overloading should prefer unshared methods over `shared` ones, e.g. because
the methods might avoid using a mutex.

--

Re: Win10 defender still sees dmd.exe and rdmd.exe as malicious

2017-06-28 Thread Ecstatic Coder via Digitalmars-d


On Monday, 26 June 2017 at 01:55:56 UTC, Matt wrote:

Hey guys,

New user here. I know the first 5 minutes experience is 
important, just to note that rdmd.exe and executables created 
with dmd.exe are flagged as malicious by windows defender. It's 
easy to create an exception in the windows defender settings, 
but I thought I would let you know.


And on my Windows system, Panda Antivirus automatically removes 
one of the Coedit files and puts it in quarantine...

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

On Wednesday, 28 June 2017 at 12:33:24 UTC, Guillaume Piolat
wrote:
On Wednesday, 28 June 2017 at 11:34:17 UTC, Moritz Maxeiner
wrote:

Requirement: Do not allocate using the GC
Option 1) Use structs with `@disable this`, `@disable
this(this)`, and a destructor that checks whether the resource
reference is != invalid resource reference before trying to
release.
Option 2) Use classes with simple constructor/destructor
layout.
If you want to integrate a check that the requirement holds
(with either class or struct), put `if (gc_inFinalizer) throw
SomeError` into the class/struct destructor

I don't get it.

You asked for a "_simple_ story about resource release" and the
above two options provide that IMHO.

It's completely possible to use the full power of GC and be
deterministic.

Sure, but it's not "simple". With D's GC as the memory allocator
you can currently have
(1) non-deterministic memory management and non-deterministic
object lifetimes:
Use `new` or
`std.experimental.allocator.make!(std.experimental.allocator.gc_allocator.GCAllocator)` for allocation
The GC will finalize objects with no pointers to them
non-deterministically and deallocate the memory after their
respective finalization.
(2) non-deterministic memory management and deterministic object
lifetimes:
Construct the objects as with (1), but destruct them by
calling `destroy` on them outside of a collection cycle (i.e.
when they, and all their members are still considered "live" by
the GC).
The GC will collect the memory non-deterministically after
there are no more pointers to it.
Warning: You are responsible for ensuring that the GC will
never see an undestroyed object in the collection cycle, because
it might try to finalize (call its `~this`) it.
You can protect yourself against such finalization
attempts by putting `if (gc_inFinalizer) throw Error("Bug! I
forgot to destruct!")` in the objects' respective destructors.
(3) deterministic memory management and deterministic object
lifetimes:
Construct the objects as with (1), but destruct
them by calling
`std.experimental.allocator.dispose!(std.experimental.allocator.gc_allocator.GCAllocator)`on them outside of a collection cycle.

The GC will not do anything for those objects.
Same warning as (2) applies.

I'm out of this very _confused_ discussion.

I'm honestly not sure what's confusing about it.

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

2017-06-28 Thread Guillaume Piolat via Digitalmars-d-learn


On Wednesday, 28 June 2017 at 13:02:04 UTC, Mike Parker wrote:
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat 
wrote:




So far everyone is ignoring my example when A needs B to be 
destroyed. This happens as soon as you use DerelictUtil for 
example.


What's the issue with DerelictUtil?


https://forum.dlang.org/post/pmulowxpikjjffkrs...@forum.dlang.org

Not an issue with DerelictUtil, an issue with the strategy of 
closing resources in GC with this case.


Derelict loaders work-around this by not unloading shared 
libraries so the GC won't unload shared libs before the resources 
related to the shared library are freed.


https://github.com/DerelictOrg/DerelictAL/blob/master/source/derelict/openal/dynload.d#L366

Re: Checked vs unchecked exceptions

2017-06-28 Thread Ola Fosheim Grøstad via Digitalmars-d


On Tuesday, 27 June 2017 at 16:54:08 UTC, Sebastien Alaiwan wrote:
adorned with a do-try block, or a try!, or a try?. There is no 
way, in this language, to silently throw an exception all the 
way to the top level; without paving a super-hiway for it up 
through the entire calling tree."


I don't think this is the best argument, if the programmer wants 
to reduce the number of exceptions that are propagated then the 
exception should be recast to a more abstract exception between 
module boundaries.


So the "super highway" issue is more a result of the programmer 
not being interested in structuring error-handling, but rather 
view errors as something that never should happen. Which may make 
sense in some applications, but not in all.

Re: Diet template is crush

2017-06-28 Thread Suliman via Digitalmars-d-learn


It's look like issue in another part of code...

[Issue 17561] @safe code can write beyond Fiber's stack, despite guard page

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

--- Comment #2 from ag0ae...@gmail.com ---
Same issue applies to the main stack. Filed separately: issue 17566.

--

[Issue 17566] New: can use void initialization in @safe code to break out of stack

2017-06-28 Thread Moritz Maxeiner via Digitalmars-d-learn

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

  Issue ID: 17566
   Summary: can use void initialization in @safe code to break out
of stack
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: safe
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

This is basically issue 17561 but without `Fiber`s. A fix for this is likely to
also fix issue 17561, so 17561 could be considered a duplicate of this. I'm
leaving it open for now, because it might be solvable by working around the
more general issue somehow.

Related links:
* https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
* https://github.com/dlang/druntime/pull/1698

Memory corrupting code:


import core.sys.posix.sys.mman;
import std.conv: text;

enum pageSize = 1024 * 4; // 4 KiB
enum stackSize = 1024 * 1024 * 3; // 3 MiB

void main()
{
/* Allocate memory near the stack. */
ubyte foo;
auto stackTop =  + pageSize - cast(size_t)  % pageSize;
auto stackBottom = stackTop - stackSize;
auto sz = pageSize;
void* dst = stackBottom - sz;
void* p = mmap(dst, sz, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON,
-1, 0);
assert(p == dst, "failed to allocate page");

/* Set it up with zeroes. */
auto mem = cast(ubyte[]) p[0 .. sz];
mem[] = 0;
foreach (x; mem) assert(x == 0, text(x)); /* passes */

/* Break out of the stack and wreak havoc. */
wreak_havoc();

/* Look at the mess. */
foreach (x; mem) assert(x == 0, text(x)); /* fails; prints "13" */
}

void wreak_havoc() @safe
{
ubyte[stackSize] x = void;
x[0] = 13;
}


Like in issue 17561, the surrounding code is not @safe, but is actually safe
(as far as I can tell). It's the void initialized static array that breaks
safety.

In a 32-bit program it's also possible to get there with `malloc` instead of a
targeted `mmap`:


/* WARNING: This fails quickly for me in a 32-bit Ubuntu VM, but it can
potentially consume all memory. */

import core.stdc.stdlib: malloc;
import std.conv: text;

enum pageSize = 1024 * 4; // 4 KiB
enum stackSize = 1024 * 1024 * 3; // 3 MiB

void main()
{
ubyte foo;
auto stackTop =  + pageSize - cast(size_t)  % pageSize;
auto stackBottom = stackTop - stackSize;
assert(cast(size_t) stackBottom % pageSize == 0);

while (true)
{
/* Allocate memory. */
auto sz = 1024 * 1024; // 1 MiB
auto p = malloc(sz);
assert(p !is null, "malloc failed");
assert(stackBottom > p);

/* See if it's near the stack. */
size_t distance = stackBottom - p;
if (distance <= sz)
{
/* Set it up with zeroes. */
auto mem = cast(ubyte[]) p[0 .. sz];
mem[] = 0;
foreach (x; mem) assert(x == 0, text(x)); /* passes */

/* Break out of the stack and wreak havoc. */
wreak_havoc();

/* Look at the mess. */
foreach (x; mem) assert(x == 0, text(x)); /* fails; prints "13" */

break;
}
}
}

void wreak_havoc() @safe
{
ubyte[stackSize] x = void;
x[0] = 13;
}


--

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

2017-06-28 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat 
wrote:




So far everyone is ignoring my example when A needs B to be 
destroyed. This happens as soon as you use DerelictUtil for 
example.


What's the issue with DerelictUtil?

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

On Wednesday, 28 June 2017 at 12:28:28 UTC, Guillaume Piolat 
wrote:
On Wednesday, 28 June 2017 at 11:21:07 UTC, Moritz Maxeiner 
wrote:
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat 
wrote:
So far everyone is ignoring my example when A needs B to be 
destroyed. This happens as soon as you use DerelictUtil for 
example.


I thought I had (implicitly): B needs to be `@disable 
finalize`.


So in the current language, doesn't exist?


I thought that was the premise of the discussion?
That the GC *currently* invokes the "destructors" as finalizers 
and that *currently* the only way to avoid that is calling 
`destroy` on them manually beforehand (since destructors won't be 
called twice on a single object).

[Issue 17565] New: Rename theAllocator to threadAllocator

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

  Issue ID: 17565
   Summary: Rename theAllocator to threadAllocator
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: slud...@outerproduct.org

The current name doesn't convey the message that this is a thread-local
allocator. The relation to processAllocator also isn't quite clear. The private
variable that backs theAllocator is already named _threadAllocator and doing
the same for the accessor property is arguably the most logical choice.

--

[Issue 17564] New: std.experimental.allocator.theAllocator is null within shared static this

2017-06-28 Thread Guillaume Piolat via Digitalmars-d-learn

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

  Issue ID: 17564
   Summary: std.experimental.allocator.theAllocator is null within
shared static this
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: slud...@outerproduct.org

vibe.d needs to use "shared static this" for initialization to support the
original initialization scheme for applications that it still in wide use. With
2.075.0-b1, since processAllocator now returns an ISharedAllocator, it had to
switch to theAllocator where possible. However, since this returns null during
the "shared static this" phase, this causes a crash on startup. Setting
theAllocator to something else also doesn't work, because of an assertion in
std.experimental.allocator.

Proposed change is to make initialization lazy, just as for processAllocator.

--

Re: Let's paint those bikesheds^Werror messages!

2017-06-28 Thread Moritz Maxeiner via Digitalmars-d


On Tuesday, 27 June 2017 at 23:38:23 UTC, Sönke Ludwig wrote:

Am 28.06.2017 um 01:24 schrieb Vladimir Panteleev:

And Windows?


Good point, I forgot about that and it can definitely not be 
ignored. A separate 16-color theme just on Windows, however, 
could still be an option.


Windows can do true colors [1]

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

Diet template is crush

2017-06-28 Thread Suliman via Digitalmars-d-learn


I can't understand why follow code is crushing:

string error = "503 Server error!";
int error_code = 503;
res.render!("error.dt", error, error_code);

on res string (last in code above) I am getting error:
CoreTaskFiber was terminated unexpectedly: Access Violation

error.dt http://paste.code123.org/91ea2dc1-7396

If delete part:
div.errorPageText #{error}
div.errorPageImg
- if (error_code == 404)
img(src='img/error_404.png')
- else
img(src='img/error_503.png')

All work fine. It's seems that something wrong with args `error, 
error_code`.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

2017-06-28 Thread Moritz Maxeiner via Digitalmars-d


On Wednesday, 28 June 2017 at 12:17:36 UTC, Enamex wrote:

Why do we need to name the result at all?

Any conflicts with using
`out(out > 0, "message")`


No conflict AFAICT. I personally don't like it, though.


`out(return > 0, "message")`?


Yes, see [1]


`out(someCond($), "message")`?


Overloading symbols with context dependent meaning is one more 
step into obfuscation.


So using either `out` or `return` or `$` or whatever to always 
refer to the return value of the function. Just something 
that's already relevant and used instead of `__result`.


Well, `__result` is already implemented and usable, so I would 
argue it is thus relevant.



R foo(Args...)(Args args) {
out(return > bar && ensured(return), "foo() fudged its 
return");


Contracts inside function bodies should not be allowed imho.

[1] http://forum.dlang.org/post/oihbot$134s$1...@digitalmars.com

Re: Advice wanted on garbage collection of sockets for c++ programmer using D


On Wednesday, 28 June 2017 at 11:34:17 UTC, Moritz Maxeiner wrote:

Requirement: Do not allocate using the GC
Option 1) Use structs with `@disable this`, `@disable 
this(this)`, and a destructor that checks whether the resource 
reference is != invalid resource reference before trying to 
release.

Option 2) Use classes with simple constructor/destructor layout.
If you want to integrate a check that the requirement holds 
(with either class or struct), put `if (gc_inFinalizer) throw 
SomeError` into the class/struct destructor


I don't get it.
It's completely possible to use the full power of GC and be 
deterministic.

I'm out of this very _confused_ discussion.

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

2017-06-28 Thread Guillaume Piolat via Digitalmars-d-learn


On Wednesday, 28 June 2017 at 11:21:07 UTC, Moritz Maxeiner wrote:
On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat 
wrote:
So far everyone is ignoring my example when A needs B to be 
destroyed. This happens as soon as you use DerelictUtil for 
example.


I thought I had (implicitly): B needs to be `@disable finalize`.


So in the current language, doesn't exist?

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

2017-06-28 Thread Enamex via Digitalmars-d


On Sunday, 25 June 2017 at 17:20:51 UTC, Timon Gehr wrote:

On 25.06.2017 17:46, Petar Kirov [ZombineDev] wrote:

On Sunday, 25 June 2017 at 12:10:02 UTC, Timon Gehr wrote:

On 25.06.2017 13:37, Andrei Alexandrescu wrote:
out(result){ assert(result > 0); } // exists

out result => assert(result > 0) // more of the same

out(result; result > 0) // better


out result => result > 0 // not much worse


out(result; result > 0, "worse enough")

Also, what Guillaume said.


Why do we need to name the result at all?

Any conflicts with using
`out(out > 0, "message")`
or
`out(return > 0, "message")`?
Or even
`out(someCond($), "message")`?

So using either `out` or `return` or `$` or whatever to always 
refer to the return value of the function. Just something that's 
already relevant and used instead of `__result`.


This could even be naturally extended to having an implicitly 
declared 'result' variable for functions (which could help in 
optimizations maybe? Something like always having NRVO possible) 
called `out` or `return`.


R foo(Args...)(Args args) {
out(return > bar && ensured(return), "foo() fudged its 
return");

// ...
return = blah;
// ...
return.quux(var);
static assert(is(typeof(return) == R)); // of course; this's 
old syntax

}

Re: Overloading funtion templates.

2017-06-28 Thread vit via Digitalmars-d-learn

On Wednesday, 28 June 2017 at 11:49:57 UTC, Balagopal Komarath 
wrote:
Shouldn't the compiler be able to resolve foo!g(3) to the first 
template foo?


import std.stdio;
import std.algorithm;
import std.range;

auto foo(F, T)(T x)
{
return x.foo(F);
}

auto foo(F, T)(T x, F f)
{
return f(x);
}

int g(int x) { return x; }

void main()
{
foo(3, ); // 2nd foo
foo!g(3);   // error
}

I get the error message.

onlineapp.d(20): Error: template onlineapp.foo cannot deduce 
function from argument types !(g)(int), candidates are:

onlineapp.d(5): onlineapp.foo(F, T)(T x)
onlineapp.d(10):onlineapp.foo(F, T)(T x, F f)


symbol 'g' isn't type.

auto foo(alias F, T)(T x)
{
return x.foo();
}

Overloading funtion templates.

2017-06-28 Thread Balagopal Komarath via Digitalmars-d-learn

Shouldn't the compiler be able to resolve foo!g(3) to the first 
template foo?


import std.stdio;
import std.algorithm;
import std.range;

auto foo(F, T)(T x)
{
return x.foo(F);
}

auto foo(F, T)(T x, F f)
{
return f(x);
}

int g(int x) { return x; }

void main()
{
foo(3, ); // 2nd foo
foo!g(3);   // error
}

I get the error message.

onlineapp.d(20): Error: template onlineapp.foo cannot deduce 
function from argument types !(g)(int), candidates are:

onlineapp.d(5): onlineapp.foo(F, T)(T x)
onlineapp.d(10):onlineapp.foo(F, T)(T x, F f)

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

2017-06-28 Thread Moritz Maxeiner via Digitalmars-d-learn

On Wednesday, 28 June 2017 at 09:22:07 UTC, Guillaume Piolat 
wrote:
Deterministic destruction is a _solved_ problem in C++, and a 
number of users to convert are now coming from C++.


It is also in D, as long as you don't use the GC (which is 
inherently non-deterministic).


  3. Suggest a systematic, always working, workaround (or 
language change such as "GC doesn't call ~this). C++ users have 
no difficulty having an object graph with detailed ownership 
schemes, that's what they do day in day out.


It's important to have a _simple_ story about resource release, 
else we will talk about "GC" every day, and hearing about "GC" 
is bad for marketing.


Requirement: Do not allocate using the GC
Option 1) Use structs with `@disable this`, `@disable 
this(this)`, and a destructor that checks whether the resource 
reference is != invalid resource reference before trying to 
release.

Option 2) Use classes with simple constructor/destructor layout.
If you want to integrate a check that the requirement holds (with 
either class or struct), put `if (gc_inFinalizer) throw 
SomeError` into the class/struct destructor

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

2017-06-28 Thread Moritz Maxeiner via Digitalmars-d-learn

On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat 
wrote:
So far everyone is ignoring my example when A needs B to be 
destroyed. This happens as soon as you use DerelictUtil for 
example.


I thought I had (implicitly): B needs to be `@disable finalize`.

Re: Checked vs unchecked exceptions

2017-06-28 Thread Moritz Maxeiner via Digitalmars-d


On Wednesday, 28 June 2017 at 06:31:40 UTC, Biotronic wrote:

On Monday, 26 June 2017 at 19:31:53 UTC, Moritz Maxeiner wrote:

the good *way* to achieve this result would be the following:
- When visiting `startFoo`, the compiler automatically 
aggregates all different exceptions it may throw and stores 
the resulting set
- If `startFoo` is going to be part of a (binary) library and 
its symbol is exported, also export its exception set
- Improve the compiler's nothrow analysis such that if 
startFoo is called in scope S, but all of the exceptions in 
its exception set are caught (i.e. can't break out of scope 
S), it is treated as nothrow in S.

- Enclose the call to `startFoo` in B in a nothrow scope.


So I have this .dll. How do I specify which exceptions it 
throws?


- Static/Dynamic linking: As said in bullet point two above, the 
exception set would have to be exported (more precise: in such a 
way that it can be loaded again at compile time); there are 
several ways to go about that: Add the exception set (e.g. via 
attributes) to the function declarations in a .di file (which 
could indeed look like checked exception, except that it's auto 
generated), use a separate (binary) file with mangled functions 
names to exception set mapping, etc.

- Dynamic loading: Won't work

One could also make an exception for bodyless functions and allow 
specification of the exception set *only* there, e.g.


---
// Allow "checked exceptions" for stubs only
void foo() throws AException throws BException;
---

Re: dlang website design

2017-06-28 Thread Sönke Ludwig via Digitalmars-d


Am 25.06.2017 um 01:12 schrieb Timon Gehr:

On 25.06.2017 01:09, Adam D. Ruppe wrote:

On Saturday, 24 June 2017 at 23:00:59 UTC, Timon Gehr wrote:

Failed to listen on :::80


Listening on port 80 requires root anyway. That's why like my cgi.d 
uses 8085 - anything over 1024 can be listened by any user (and is 
less likely to have an existing program on it)




Thanks! I guessed as much, but I don't have a setup where root can build 
the code. (And I don't see why it should.)


Usually I'd use 8080 for examples, but the original example used port 
80, so I just followed along. HTTPServerSettings has a .port field that 
can be used to change the default.

[Issue 12555] Incorrect error ungagging for speculatively instantiated class

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #5 from Vladimir Panteleev  ---
*** Issue 11195 has been marked as a duplicate of this issue. ***

--

[Issue 11195] Error messages not suppressed in __traits(compiles,...) for template instantiation nested in aggregate

2017-06-28 Thread Guillaume Piolat via Digitalmars-d-learn

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|FIXED   |DUPLICATE

--- Comment #4 from Vladimir Panteleev  ---
(In reply to Simen Kjaeraas from comment #3)
> This has apparently been solved some time in the last 4 years.

Fixed in 2.066.0 by https://github.com/dlang/dmd/pull/3514

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

--

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat 
wrote:
On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis 
wrote:
There are definitely cases where finalizers make sense. Case 
in point: if you have a socket class, it makes perfect sense 
for it to have a finalizer. Yes, it's better to close it 
manually, but it will work just fine for the GC to close it 
when finalizing the class object so long as you don't use so 
many sockets that you run out before the GC collects them. So, 
having a finalizer is a good backup to ensure that the socket 
resource doesn't leak.


- Jonathan M Davis


So far everyone is ignoring my example when A needs B to be 
destroyed. This happens as soon as you use DerelictUtil for 
example.


And I'm gonna rant a little bit more.

Deterministic destruction is a _solved_ problem in C++, and a 
number of users to convert are now coming from C++.


We should:
  1. be honest and tell things as they are: it's more complicated 
than in C++, but also liberating when you know to juggle between 
GC and deterministic
  2. Avoid making bogus suggestions which don't always work, such 
as close() methods, releasing resource with GC, . They only work 
for _some_ resources.
  3. Suggest a systematic, always working, workaround (or 
language change such as "GC doesn't call ~this). C++ users have 
no difficulty having an object graph with detailed ownership 
schemes, that's what they do day in day out.


It's important to have a _simple_ story about resource release, 
else we will talk about "GC" every day, and hearing about "GC" is 
bad for marketing.

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

2017-06-28 Thread Guillaume Piolat via Digitalmars-d-learn

On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis 
wrote:
There are definitely cases where finalizers make sense. Case in 
point: if you have a socket class, it makes perfect sense for 
it to have a finalizer. Yes, it's better to close it manually, 
but it will work just fine for the GC to close it when 
finalizing the class object so long as you don't use so many 
sockets that you run out before the GC collects them. So, 
having a finalizer is a good backup to ensure that the socket 
resource doesn't leak.


- Jonathan M Davis


So far everyone is ignoring my example when A needs B to be 
destroyed. This happens as soon as you use DerelictUtil for 
example.

[Issue 2372] Template parameter types given as template parameter inhibits template instantiation + missing line number

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

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Simen Kjaeraas  ---
Jonathan Marler's code does indeed exhibit the same issue, and gives a small
demonstration of why this will never work in the general case. For a more
explicit demonstration:

void foo(T)(Bar!T value) {}

template Bar(T) {
alias Bar = string;
}

foo("test"); // What is T?

Clearly, in this case T cannot be determined. Real life examples could be
significantly more complex, and even involve CTFE and string mixins. There's
simply no way to make this work in the language.

--

[Issue 1997] Better type inference for templated types

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

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Simen Kjaeraas  ---
This issue is not fixable in the general case - constructor arguments do not
necessarily line up with type arguments. As pointed out above, the correct fix
is to use a factory function.

--

What is best way to link DlangUI widget and program logic?

2017-06-28 Thread Murzistor via Digitalmars-d-learn

I want to call a method of the certain instance of "MyClass" from 
certain widget.

Each widget should know its corresponding instance of "MyClass".
As far as I understood, delegates cannot do it.

Re: Release candidates vibe.d 0.8.0-rc.2 and vibe-core 1.0.0-rc.2

2017-06-28 Thread Andre Pany via Digitalmars-d-announce


On Tuesday, 27 June 2017 at 09:20:40 UTC, Sönke Ludwig wrote:

Am 22.06.2017 um 10:55 schrieb Sönke Ludwig:
There have been some minor fixes and vibe.d 0.8.0-rc.2 and 
vibe-core 1.0.0-rc.2 have been tagged. The final release is 
rescheduled for Monday, July the 3rd.


It seems there is an issue with the dmd 2.075.0-b1 and rc.2

vibe-d:utils 0.8.0-rc.2: building configuration "library"...
..\..\..\..\Users\D041451\AppData\Roaming\dub\packages\vibe-d-0.8.0-rc.2\vibe-d\utils\vibe\utils\hashmap.d(258,45):
 Error: function vibe.utils.hashmap.HashMap!(void*, uint, 
DefaultHashMapTraits!(void*)).HashMap.AW (IAllocator a) is not callable using 
argument types (shared(ISharedAllocator))
..\..\..\..\Users\D041451\AppData\Roaming\dub\packages\vibe-d-0.8.0-rc.2\vibe-d\utils\vibe\internal\memory_legacy.d(199,21):
 Error: template instance vibe.utils.hashmap.HashMap!(void*, uint, 
DefaultHashMapTraits!(void*)).HashMap.opIndexAssign!uint error instantiating
..\..\..\..\Users\D041451\AppData\Roaming\dub\packages\vibe-d-0.8.0-rc.2\vibe-d\utils\vibe\internal\memory_legacy.d(199,21):
 Error: function 'vibe.utils.hashmap.HashMap!(void*, uint, 
DefaultHashMapTraits!(void*)).HashMap.opIndexAssign!uint.opIndexAssign' is not 
nothrow
..\..\..\..\Users\D041451\AppData\Roaming\dub\packages\vibe-d-0.8.0-rc.2\vibe-d\utils\vibe\internal\memory_legacy.d(194,9):
 Error: nothrow function 'vibe.internal.memory_legacy.DebugAllocator.alloc' may 
throw
..\..\..\..\Users\D041451\AppData\Roaming\dub\packages\vibe-d-0.8.0-rc.2\vibe-d\utils\vibe\internal\memory_legacy.d(218,21):
 Error: function 'vibe.utils.hashmap.HashMap!(void*, uint, 
DefaultHashMapTraits!(void*)).HashMap.opIndexAssign!uint.opIndexAssign' is not 
nothrow
..\..\..\..\Users\D041451\AppData\Roaming\dub\packages\vibe-d-0.8.0-rc.2\vibe-d\utils\vibe\internal\memory_legacy.d(208,9):
 Error: nothrow function 'vibe.internal.memory_legacy.DebugAllocator.realloc' 
may throw
dmd failed with exit code 1.

Does not occur with 2.074.

Kind regards
André

[Issue 11195] Error messages not suppressed in __traits(compiles,...) for template instantiation nested in aggregate