[Issue 16008] New: FreeList should implement deallocateAll, as SharedFreeList does

[via Digitalmars-d-bugs]

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

  Issue ID: 16008
   Summary: FreeList should implement deallocateAll, as
SharedFreeList does
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: ASSIGNED
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: b2.t...@gmx.com
  Reporter: b2.t...@gmx.com

THis can be necessary.

An example that was posted on SO ([1]), if one embeds a FreeList in an
aggregate, it's very probable that the FreeList has to be cleared in the
aggregate __ctor, which is not possible now.

[1]:
http://stackoverflow.com/questions/36719532/how-can-i-free-all-the-items-of-a-freelist

--

Re: Battle-plan for CTFE

[Andrei Alexandrescu via Digitalmars-d-announce]

On 5/9/16 7:57 PM, Stefan Koch wrote:

Hi Guys,

I have been looking into the DMD now to see what I can do about CTFE.
Unfortunately It is a pretty big mess to untangle.
Code responsible for CTFE is in at least 3 files.
[dinterpret.d, ctfeexpr.d, constfold.d]
I was shocked to discover that the PowExpression actually depends on
phobos! (depending on the exact codePath it may or may not compile...)
which let to me prematurely stating that it worked at ctfe
[http://forum.dlang.org/thread/ukcoibejffinknrbz...@forum.dlang.org]

My Plan is as follows.

Add a new file for my ctfe-interpreter and update it gradually to take
more and more of the cases the code in the files mentioned above was
used for.

Do Dataflow analysis on the code that is to be ctfe'd so we can tell
beforehand if we need to store state in the ctfe stack or not.

Or baring proper data-flow analysis: RefCouting the variables on the
ctfe-stack could also be a solution.

I will post more details as soon as I dive deeper into the code.


Thanks Stefan, that's a good start! (This is probably better for the 
general forum.) -- Andrei

What is up with building DMD (et al.) on Windows?

[Jeremy DeHaan via Digitalmars-d-learn]

I went to build DMD on Windows for the first time tonight and I 
have to say that it was a terrible experience when compared with 
Linux.


First issue I ran into was having HOST_DC not being set. I'm not 
sure if the DMD installer is supposed to do this or if I needed 
to take care of it, but it wasn't mentioned anywhere I could 
find. I finally just set it myself.


Then it builds DMD, but gets placed in dmd/src/ instead of its 
own directory.


After DMD is built, other things keep getting built by DMC. I get 
more than a few errors due to having an eof character on the 
first line of some .h files, or something like that.


I also built druntime, but instead of trying to use a freshly 
built dmd.exe in the neighboring DMD source directory, it went 
for the one in PATH. I haven't bothered to build Phobos on 
Windows yet.


Building DMD, Phobos, and druntime on Linux is so easy and 
straight forward. It all works as expected. What's up with 
building DMD on Windows?

Re: dmd not building with dmd

[Lionello Lunesu via Digitalmars-d]

On 9/5/2016 20:19, John Colvin wrote:

On Monday, 9 May 2016 at 07:57:33 UTC, Lionello Lunesu wrote:

On 8/5/2016 14:43, Steven Schveighoffer wrote:

[...]


I ran into this as well. It's a bug in the package from brew: it
shipped with the wrong phobos. You can build your own DMD:

$ make -f posix.mak AUTO_BOOTSTRAP=1


In what way do you mean "shipped with the wrong phobos"?


Well, it's either wrong phobos or wrong dmd. I assumed phobos was 
mismatched, but perhaps DMD was mismatched? Installing with brew suggest 
it's installing 2.071.0, but DMD appears to be 2.070:


$ brew install dmd
==> Downloading 
https://homebrew.bintray.com/bottles/dmd-2.071.0.el_capitan.bottle.tar.gz
Already downloaded: 
/Library/Caches/Homebrew/dmd-2.071.0.el_capitan.bottle.tar.gz

==> Pouring dmd-2.071.0.el_capitan.bottle.tar.gz
  /usr/local/Cellar/dmd/2.071.0: 561 files, 65.0M

$ /usr/local/bin/dmd --version
DMD64 D Compiler v2.070
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright

Re: How are you enjoying DConf? And where to go next?

[Daniel Kozak via Digitalmars-d]

Dne 9.5.2016 v 19:45 jmh530 via Digitalmars-d napsal(a):


On Monday, 9 May 2016 at 15:12:25 UTC, krzaq wrote:


It's not just the distance, but also the overall personal cost of 
attending the conference. Berlin is, all things considered, a fairly 
cheap city. London is a big NO in this regard, can't speak about the 
other suggestions.



I don't know what Berlin's like, but I just visited London for a long 
weekend and it wasn't so bad compared to where I live (NYC). I used 
AirBnB and my room was like $90 a night.
But for people like me $90 per night is too much. I live in Czech 
Republic which is a really beautifull country in middle of europe (it is 
called heart of europe). And even in Prague which is capital city of 
Czech Republic I am able to get room per $10. And it is not only 
accomodation but other things are really cheap here. For example beer 
price is only about $1 (btw czech beer is the best beer on the word). 
Public transport in Prague for 3 days cost just only $15 and so on.


Even dconf in Berlin (just 400km from me) is expensive for me (one month 
salary including transport and accommodation).

Re: Follow-up post explaining research rationale

[Joe Duarte via Digitalmars-d]

On Monday, 9 May 2016 at 20:17:40 UTC, ag0aep6g wrote:

Am 09.05.2016 um 21:09 schrieb Joe Duarte:
4. We switch the person or voice from an imperative "do this" 
as in
printf, to some sort of narrator third-person voice with 
"gets".


"gets" is still imperative. It's short for "get string". Not 
saying that this is obvious, or that it's a good name.


Ah, I forgot about that! I think puts has the same abbreviation 
structure right? put string... I think knowing/remembering that 
it's an abbreviation would make it less distracting. My calling 
it a shift in voice is incorrect assuming people remember what it 
stands for.


JD

Re: Always false float comparisons

[Xinok via Digitalmars-d]

On Monday, 9 May 2016 at 20:14:36 UTC, Walter Bright wrote:

On 5/9/2016 11:37 AM, Xinok wrote:
All of these scenarios are capable of producing "incorrect" 
results, are a
source of discrete bugs (often corner cases that we failed to 
consider and
test), and can be hard to detect. It's about time we stopped 
being stubborn and
flagged these things as warnings. Even if they require a 
special compiler flag

and are disabled by default, that's better than nothing.


I've used a B+D language that does as you suggest (Wirth 
Pascal). It was highly unpleasant to use, as the code became 
littered with casts. Casts introduce their own set of bugs.


Maybe it's a bad idea to enable these warnings by default but 
what's wrong with providing a compiler flag to perform these 
checks anyways? For example, GCC has a compiler flag to yield 
warnings for signed+unsigned comparisons but it's not even 
enabled with the -Wall flag, only by specifying -Wextra or 
-Wsign-compare.

Re: Follow-up post explaining research rationale

[Bill Hicks via Digitalmars-d]

On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:


...



You're not addressing the root cause.

America was founded on genocide, racism, sexism, and classism.  
That should be the starting point of such research, but nobody 
goes there because people, specially those who benefit from the 
current system, are not serious about changing anything.


The idea that syntax has anything to do with women and minorities 
being underrepresented in the industry, or that it's some kind of 
deterrent, is the stupidest thing any one could come up with.  
It's like saying that the reason why more blacks do not have 
university degrees is because notebooks contain white sheets of 
paper instead of gray sheets of paper, or that #2 pencils lack 
blings.  Idiot!  Instead of saying shit like "PL syntax ... 
disproportionately deters qualified women", did you consider the 
possibility that maybe, just maybe, the current PL syntax 
disproportionately encourages white men to behave in sexist and 
racist manners?  You see how retarded that sounds?


So, you are completely ignoring the cultural, historical, and 
societal forces that have created the problems in the first 
place.  Basically, not only is your hypotheses sexist in its own 
right, but you've completely shifted the blame of this injustice 
onto something completely artificial that has nothing to do with 
the problem.

[Issue 16007] Some Win32 API structs has wrong definitions

[via Digitalmars-d-bugs]

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

j...@red.email.ne.jp changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from j...@red.email.ne.jp ---
https://github.com/dlang/druntime/pull/1570

--

Re: ggplotd - curve colour

[brocolis via Digitalmars-d-learn]

On Monday, 9 May 2016 at 06:24:22 UTC, Edwin van Leeuwen wrote:

On Monday, 9 May 2016 at 02:29:47 UTC, brocolis wrote:

Is this correct usage?
auto gg = GGPlotD().put( geomLine( Aes!(typeof(xs), "x", 
typeof(ysfit), "y", string, "colour")( xs, ysfit, "red") ) );


The output is a blank png file.

Full source:
import ggplotd.ggplotd;
import ggplotd.geom;
import ggplotd.aes;
import ggplotd.axes;

void main()
{
import std.array : array;
import std.algorithm : map;
import std.range : iota;
import ggplotd.colour;

auto f = (double x) { return x; };
auto xs = iota(-5, 5, 0.1 ).array;
auto ysfit = xs.map!((x) => f(x)).array;
auto gg = GGPlotD().put( geomLine( Aes!(typeof(xs), "x", 
typeof(ysfit), "y", string, "colour")( xs, ysfit, "red") ) );


gg.put( xaxisOffset( 0) ).put( yaxisOffset( 0) );
gg.save( "axes.png", 500, 300 );
}


The problem there is that colour also needs to be an 
InputRange. This is so that different points can have a 
different colours associated with it, which is particularly 
useful if you want to plot some data and have different types 
of data plotted as different colours.


In your example you can either do:

```
auto colour = "red".repeat( xs.length );
auto gg = GGPlotD().put( geomLine( Aes!(typeof(xs), "x",
 typeof(ysfit), "y", typeof(colour), "colour")( xs, ysfit, 
colour) ) );

```

Or use the mergeRange function mentioned before, which will 
automatically repeat if one argument is a single element.


```
auto aes = Tuple!( string, "colour" )( "red" ).mergeRange( 
Aes!(typeof(xs), "x",

 typeof(ysfit), "y" )( xs, ysfit ) );
```


OK! Thank you.

[Issue 16007] New: Some Win32 API structs has wrong definitions

[via Digitalmars-d-bugs]

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

  Issue ID: 16007
   Summary: Some Win32 API structs has wrong definitions
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: j...@red.email.ne.jp

I'm verifying the sizes of the structs in Win32 headers.
This is the first PR of problems I found.

For instance:
- Simply missing fileds or structs
- Unions has orphan structs which do not get instances
- Asymmetric pairs for x86/x64
- Asymmetric pair for ANSI/Unicode

--

Re: Battle-plan for CTFE

[Walter Bright via Digitalmars-d-announce]

On 5/9/2016 2:32 PM, Andrej Mitrovic via Digitalmars-d-announce wrote:

On 5/9/16, Stefan Koch via Digitalmars-d-announce
 wrote:

I was shocked to discover that the PowExpression actually depends
on phobos!


I seem to remember having to implement diagnostics in DMD asking for
the user to import std.math. I'm fairly confident it had something to
do with power expressions.

Yah, it's a mess. :)



The pow stuff should just be done in dmd without reference to the library.

Re: How are you enjoying DConf? And where to go next?

[Mike Parker via Digitalmars-d]

On Monday, 9 May 2016 at 17:45:24 UTC, jmh530 wrote:

On Monday, 9 May 2016 at 15:12:25 UTC, krzaq wrote:


It's not just the distance, but also the overall personal cost 
of attending the conference. Berlin is, all things considered, 
a fairly cheap city. London is a big NO in this regard, can't 
speak about the other suggestions.



I don't know what Berlin's like, but I just visited London for 
a long weekend and it wasn't so bad compared to where I live 
(NYC). I used AirBnB and my room was like $90 a night.


I came to London from the conference and have found it fairly 
reasonable. Back to Seoul and Real Life tomorrow, unfortunately. 
I'd happily fly back here for the next conf if need be. I'd 
really love to see it in Japan, though.

[Issue 15974] Spurious error: argument to mixin must be a string, not (expression()) of type string

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/ceff80f4df0d65e7e5023278420418d5e975f44b
fix Issue 15974 - Spurious error: argument to mixin must be a string, not
(expression()) of type string

https://github.com/dlang/dmd/commit/7085fca5112bbfa018b15739e4b5c624d4ac4771
Merge pull request #5753 from 9rnsr/fix15974

Issue 15974 - Spurious error: argument to mixin must be a string, not
(expression()) of type string

--

[Issue 15974] Spurious error: argument to mixin must be a string, not (expression()) of type string

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Always false float comparisons

[Joe Duarte via Digitalmars-d]

On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote:

Don Clugston pointed out in his DConf 2016 talk that:

float f = 1.30;
assert(f == 1.30);

will always be false since 1.30 is not representable as a 
float. However,


float f = 1.30;
assert(f == cast(float)1.30);

will be true.

So, should the compiler emit a warning for the former case?


I think it really depends on what the warning actually says. I 
think people have different expectations for what that warning 
would be.


When you say 1.30 is not representable as a float, when is the 
"not representable" enforced? Because it looks like the 
programmer just represented it in the assignment of the literal – 
but that's not where the warning would be right? I mean I assume 
so because people need nonrational literals all the time, and 
this is the only way they can do it, which means it's a hole in 
the type system right? There should be a decimal type to cover 
all these cases, like some databases have.


Would the warning say that you can't compare 1.30 to a float 
because 1.30 is not representable as a float? Or would it say 
that f was rounded upon assignment and is no longer 1.30?


Short of a decimal type, I think it would be nice to have a 
"float equality" operator that covered this whole class of cases, 
where floats that started their lives as nonrational literals and 
floats that have been rounded with loss of precision can be 
treated as equal if they're within something like .001% of 
each other (well a  percentage that can actually be represented 
as a float...) Basically equality that covers the known 
mutational properties of fp arithmetic.


There's no way to do this right now without ranges right? I know 
that ~ is for concat. I saw ~= is an operator. What does that do? 
The Unicode ≈ would be nice for this.


I assume IEEE 754 or ISO 10967 don't cover this? I was just 
reading the latter (zip here: 
http://standards.iso.org/ittf/PubliclyAvailableStandards/c051317_ISO_IEC_10967-1_2012.zip)

Re: Battle-plan for CTFE

[Jonathan M Davis via Digitalmars-d-announce]

On Monday, May 09, 2016 13:24:56 Walter Bright via Digitalmars-d-announce 
wrote:
> On 5/9/2016 9:57 AM, Stefan Koch wrote:
> >[...]
>
> The memory consumption problem, at least, can be resolved by using stack
> temporaries instead of allocating new nodes. This was already done in
> constfold.d, but not in the rest of the interpreter.
>
> Doing that will (I predict) also double its speed right there.

Previously, Don stated that he thought that simply making it so that CTFE
didn't allocate a new integer every time it mutated it would be a _huge_
speed-up by itself (which presumably is what you're talking about with
regards to allocating new nodes). Unfortunately, he got too busy to actually
do that work and no one else stepped in to do. But if Stefan is going to
step up and improve CTFE, that's fantastic. It's one of D's best features,
but it's also one of its most problematic. Fixng that would be huge.

- Jonathan M Davis

[Issue 15974] Spurious error: argument to mixin must be a string, not (expression()) of type string

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||diagnostic, pull
   Hardware|x86 |All
 OS|Mac OS X|All

--- Comment #2 from Kenji Hara  ---
https://github.com/dlang/dmd/pull/5753

--

[Issue 16006] New: Investigate adding fork() to std.process

[via Digitalmars-d-bugs]

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

  Issue ID: 16006
   Summary: Investigate adding fork() to std.process
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com
CC: c...@dawg.eu

I wonder how far we can go with providing a safe-ish fork() in std.process.

Most importantly, what needs to be done:

- Making sure we don't fork() during a GC cycle
- Unregistering all threads from the runtime in the child

Locks held by other threads will remain held, but this would be an application
bug and fairly easy to diagnose.

Anything else?

--

[Issue 15511] fork: Invalid memory operation

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
Duplicate of issue 14003?

--

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Monday, 9 May 2016 at 20:24:56 UTC, Walter Bright wrote:

On 5/9/2016 9:57 AM, Stefan Koch wrote:

[...]


The memory consumption problem, at least, can be resolved by 
using stack temporaries instead of allocating new nodes. This 
was already done in constfold.d, but not in the rest of the 
interpreter.


Doing that will (I predict) also double its speed right there.


Thanks, your advice is most helpful and a good first stop-gap.

Still the current state of CTFE is almost not maintainable
 and I would really prefer a clean-slate approach.

SDC benefits extremely from the extra level of indirection, 
however I do understand that SDC and DMD have diffrent goals 
regarding compile-speed.


Also I feel that good code has found it's most beautiful shape 
when it's simplicity makes it inevitable, at least the 
Ctfe-Mechanism has not reached this point yet, imo.

[Issue 6846] std.concurrency and fork/execv

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||thecybersha...@gmail.com
 Resolution|--- |INVALID

--- Comment #2 from Vladimir Panteleev  ---
You are mixing threads with forking. This is a bad idea in any language.

What happens is that a thread from the main process forks, but it doesn't take
along with it the other threads. One of those threads is running the GC, which
holds a lock. As the GC thread is not duplicated during the fork, the lock will
never be freed, thus the forked process will deadlock.

--

[Issue 8719] spawnvp() (POSIX) throws exception in fork()ed child process

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||thecybersha...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #1 from Vladimir Panteleev  ---
spawnvp is deprecated, use spawnProcess.

--

Re: Chaining opIndex

[John Colvin via Digitalmars-d-learn]

On Monday, 9 May 2016 at 20:14:25 UTC, deed wrote:

struct Foo {
Bars bars;
...
}

struct Foos {
Foo[] arr;
Foo opIndex (size_t idx) { return arr[idx]; }
...
}

struct Bar {
// No Car[] cars;
...
}

struct Bars {
Bar[] arr;
Bar opIndex (size_t idx) { return arr[idx]; }
...
}

struct Car {
...
}

Foos foos;
Foo foo = foos[1];  // Works
Bar bar = foos[1].bars[2];  // Works
Car car = foos[1].bars[2].cars[3];  // Desired abstraction.

For any Bar there are some Cars, but Bar doesn't hold any Cars. 
In other words, there could be a function Car cars (Bar bar, 
size_t idx) { ... }, but that would be called with parens;


Car car = foos[i].bars[j].cars(k);

which would be inconsistent and confusing. Defining

struct Cars {
Car opIndex (Bar bar, size_t idx) {}
}

and

struct Bar {
Cars cars;
...
}

doesn't enable chaining and then would have to be used like 
this, AFAIK:


Car car = cars[foos[i].bars[j], k];

Which is out of the question. Any suggestions to achieve the 
desired abstraction in a clean manner?


There are lots of ways to approach this. Here's one possibility:

auto cars(Bar bar)
{
static struct Res
{
Bar bar;
Car opIndex(size_t i)
{
return /* e.g. getCar(bar, i); */
}
}
return Res(bar);
}

Re: powExpressions work at ctfe

[Jonathan M Davis via Digitalmars-d]

On Monday, May 09, 2016 13:02:50 Stefan Koch via Digitalmars-d wrote:
> that would also
> prevent issues with cross-compiled binarys that have ctfe in them.

That's going to be pretty critical in the long run, especially now that the
compiler frontend is in D.

- Jonathan M Davis

[Issue 11229] std.string.toLower is slow

[via Digitalmars-d-bugs]

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

--- Comment #10 from Jon Degenhardt  ---
(In reply to Jon Degenhardt from comment #9)

> The version I wrote (and the single character version of toLower it
> calls) do "simple case folding", where the character length may expand.
>
Sorry, that should have read:
   "simple case folding", where the character length may *not* expand.

--

[Issue 11229] std.string.toLower is slow

[via Digitalmars-d-bugs]

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

--- Comment #9 from Jon Degenhardt  ---
(In reply to Jack Stouffer from comment #8)
> (In reply to Jon Degenhardt from comment #7)
> > auto mapAsLowerCase(Range)(Range str)
> > if (isInputRange!Range && isSomeChar!(ElementEncodingType!Range) &&
> > !isConvertibleToString!Range)
> > {
> > static if (ElementEncodingType!Range.sizeof < dchar.sizeof)
> > {
> > import std.utf : byDchar;
> > return str.byDchar.mapAsLowerCase;
> > }
> > else
> > {
> > import std.algorithm : map;
> > import std.uni : toLower;
> > 
> > return str.map!(x => x.toLower);
> > }
> > }
> 
> I attempted to replace asLowerCase with this, but it's blocked by
> https://issues.dlang.org/show_bug.cgi?id=16005

The version I wrote was reasonable for performance analysis, but it is not
fully consistent functionally with the current version of asLowerCase. The
current version of asLowerCase does "full case folding", which means the
character length may expand. The version I wrote (and the single character
version of toLower it calls) do "simple case folding", where the character
length may expand. An example is "Latin Capital Letter I With Dot Above" (İ,
u+130). In simple case folding, it becomes "Latin small letter I" (the ascii
lower case letter I, u+0069). In full case folding, it becomes the character
sequence [0069 0307] (lower case I followed by 'combining dot above).

Both case folding approaches have valid uses. In retrospect, what my analysis
did not do is differentiate the cost of the ascii check from the cost of
full-case folding. 

One reasonable question is if the ascii check can be incorporated into
std.uni.toCaser. If so, that would preserve the current full case-folding
functionality. There still might be value to having a simple-case folding
version as well, but that could be treated as a separate topic.

--

Re: Battle-plan for CTFE

[Andrej Mitrovic via Digitalmars-d-announce]

On 5/9/16, Stefan Koch via Digitalmars-d-announce
 wrote:
> I was shocked to discover that the PowExpression actually depends
> on phobos!

I seem to remember having to implement diagnostics in DMD asking for
the user to import std.math. I'm fairly confident it had something to
do with power expressions.

Yah, it's a mess. :)

Re: Always false float comparisons

[tsbockman via Digitalmars-d]

On Monday, 9 May 2016 at 20:16:59 UTC, Walter Bright wrote:
(4) is already planned; it's just taking *a lot* longer than 
anticipated to

actually implement it:
https://issues.dlang.org/show_bug.cgi?id=259
https://github.com/dlang/dmd/pull/1913
https://github.com/dlang/dmd/pull/5229


I oppose this change. You'd be better off not having unsigned 
types at all than this mess, which was Java's choice. But then 
there are more problems created.


One other thing - according to the bug report discussion, the 
proposed solution was pre-approved both by Andrei Alexandrescu 
and by *YOU*.


Proposing a solution, letting various people work on implementing 
it for three years, and then suddenly announcing that you "oppose 
this change" and calling the solution a "mess" with no 
explanation is a fantastic way to destroy all motivation for 
outside contributors.

Re: Always false float comparisons

[John Colvin via Digitalmars-d]

On Monday, 9 May 2016 at 20:20:00 UTC, Walter Bright wrote:

On 5/9/2016 12:39 PM, tsbockman wrote:
Educating programmers who've never studied how to write 
correct FP code is too
complex of a task to implement via compiler warnings. The 
warnings should be
limited to cases that are either obviously wrong, or where the 
warning is likely

to be a net positive even for FP experts.


I've seen a lot of proposals which try to hide the reality of 
how FP works. The cure is worse than the disease. The same goes 
for hiding signed/unsigned, and the autodecode mistake of 
pretending that code units aren't there.


I completely agree that complexity that cannot be properly hidden 
should not be hidden. The underlying mechanisms of floating point 
is complexity that we shouldn't paper over. However, the 
peculiarities of language conventions w.r.t. floating point 
expressions doesn't quite fit that category.

Re: Always false float comparisons

[tsbockman via Digitalmars-d]

On Monday, 9 May 2016 at 20:16:59 UTC, Walter Bright wrote:

On 5/9/2016 11:51 AM, tsbockman wrote:
(4) is already planned; it's just taking *a lot* longer than 
anticipated to

actually implement it:
https://issues.dlang.org/show_bug.cgi?id=259
https://github.com/dlang/dmd/pull/1913
https://github.com/dlang/dmd/pull/5229


I oppose this change. You'd be better off not having unsigned 
types at all than this mess, which was Java's choice. But then 
there are more problems created.


What mess? The actual fix for issue 259 is simple, elegant, and 
shouldn't require much code in the wild to be changed.


The difficulties and delays have all been associated with the 
necessary improvements to VRP and constant folding, which are 
worthwhile in their own right, since they help the compiler 
generate faster code.

Re: Always false float comparisons

[Steven Schveighoffer via Digitalmars-d]

On 5/9/16 4:22 PM, Walter Bright wrote:

On 5/9/2016 6:46 AM, Steven Schveighoffer wrote:

I know this is a bit band-aid-ish, but if one is comparing literals to
a float,
why not treat the literal as the type being compared against? In other
words,
imply the 1.3f. This isn't integer-land where promotions do not change
the outcome.


Because it's yet another special case, and we know where those lead. For
example, what if the 1.30 was the result of CTFE?



This is true, it's a contrived example.

-Steve

Re: Always false float comparisons

[Marco Leise via Digitalmars-d]

Am Mon, 09 May 2016 15:56:21 +
schrieb Nordlöw :

> On Monday, 9 May 2016 at 12:28:04 UTC, Walter Bright wrote:
> > On 5/9/2016 4:38 AM, Nordlöw wrote:  
> >> Would that include comparison of variables only aswell?  
> > No.  
> 
> Why?

Because the float would be converted to double without loss of
precision just like uint == ulong is a valid comparison which
can yield 'true' in 2^32 cases.
float == 1.30 on the other hand is false in any case.
You'd have to warn on _every_ comparison with a widening
conversion to be consistent!

-- 
Marco

Re: Follow-up post explaining research rationale

[Joe Duarte via Digitalmars-d]

On Monday, 9 May 2016 at 20:29:12 UTC, Joe Duarte wrote:

On Monday, 9 May 2016 at 20:09:35 UTC, Adam D. Ruppe wrote:

I'd also be surprised if you find an empirical gender gap 
after controlling for programming language syntax, too. Even 
if we grant that PL syntax is suboptimal, why would that 
result in a gender bias? But, hey, you never really know until 
you actually collect the data...


I forgot to mention the math. You can run the model in your 
head. If group W has more career options than group M, W will 
be underrepresented in career domain A. The effect will be 
larger if A is less appealing than W's other options, ceteris 
paribus and with some starting assumptions. (But it doesn't 
need to be, if W has more options than M.)


If aspects of career domain A are *equally frustrating* for 
members of groups W and M, W will still be underrepresented 
(and M overrepresented) if people in W have more options. So we 
don't even need it to be the case that bizarre programming 
language design disproportionately annoys women for bizarre 
programming language design to result in the 
underrepresentation of women.


JD


(Assuming A is included in the set of options for both groups, 
and is equally available to them.)

Re: Always false float comparisons

[Marco Leise via Digitalmars-d]

Am Mon, 9 May 2016 02:10:19 -0700
schrieb Walter Bright :

> Don Clugston pointed out in his DConf 2016 talk that:
> 
>  float f = 1.30;
>  assert(f == 1.30);
> 
> will always be false since 1.30 is not representable as a float. However,
> 
>  float f = 1.30;
>  assert(f == cast(float)1.30);
> 
> will be true.
> 
> So, should the compiler emit a warning for the former case?

I'd say yes, but exclude the case where it can be statically
verified, that the comparison can yield true, because the
constant can be losslessly converted to the type of 'f'.

By example, don't warn for these:
f == 1.0, f == -0.5, f == 3.625, f == 2UL^^60

But do warn for:
f == 1.30, f == 2UL^^60+1

As an extension of the existing "comparison is always
false/true" check it could read "Comparison is always false:
literal 1.30 is not representable as 'float'".

There is a whole bunch in this warning category:
  byte b;
  if (b == 1000) {}
"Comparison is always false: literal 1000 is not representable
as 'byte'"

-- 
Marco

Re: Follow-up post explaining research rationale

[Joe Duarte via Digitalmars-d]

On Monday, 9 May 2016 at 20:09:35 UTC, Adam D. Ruppe wrote:

I'd also be surprised if you find an empirical gender gap after 
controlling for programming language syntax, too. Even if we 
grant that PL syntax is suboptimal, why would that result in a 
gender bias? But, hey, you never really know until you actually 
collect the data...


I forgot to mention the math. You can run the model in your head. 
If group W has more career options than group M, W will be 
underrepresented in career domain A. The effect will be larger if 
A is less appealing than W's other options, ceteris paribus and 
with some starting assumptions. (But it doesn't need to be, if W 
has more options than M.)


If aspects of career domain A are *equally frustrating* for 
members of groups W and M, W will still be underrepresented (and 
M overrepresented) if people in W have more options. So we don't 
even need it to be the case that bizarre programming language 
design disproportionately annoys women for bizarre programming 
language design to result in the underrepresentation of women.


JD

Re: Always false float comparisons

[Walter Bright via Digitalmars-d]

On 5/9/2016 6:46 AM, Steven Schveighoffer wrote:

I know this is a bit band-aid-ish, but if one is comparing literals to a float,
why not treat the literal as the type being compared against? In other words,
imply the 1.3f. This isn't integer-land where promotions do not change the 
outcome.


Because it's yet another special case, and we know where those lead. For 
example, what if the 1.30 was the result of CTFE?

Re: Always false float comparisons

[Walter Bright via Digitalmars-d]

On 5/9/2016 12:39 PM, tsbockman wrote:

Educating programmers who've never studied how to write correct FP code is too
complex of a task to implement via compiler warnings. The warnings should be
limited to cases that are either obviously wrong, or where the warning is likely
to be a net positive even for FP experts.


I've seen a lot of proposals which try to hide the reality of how FP works. The 
cure is worse than the disease. The same goes for hiding signed/unsigned, and 
the autodecode mistake of pretending that code units aren't there.

Re: Follow-up post explaining research rationale

[ag0aep6g via Digitalmars-d]

Am 09.05.2016 um 21:09 schrieb Joe Duarte:

4. We switch the person or voice from an imperative "do this" as in
printf, to some sort of narrator third-person voice with "gets".


"gets" is still imperative. It's short for "get string". Not saying that 
this is obvious, or that it's a good name.

Re: Always false float comparisons

[Walter Bright via Digitalmars-d]

On 5/9/2016 11:51 AM, tsbockman wrote:

On Monday, 9 May 2016 at 18:37:10 UTC, Xinok wrote:

(4) While we're at it, let's also emit a warning when comparing signed and
unsigned types.


(4) is already planned; it's just taking *a lot* longer than anticipated to
actually implement it:
https://issues.dlang.org/show_bug.cgi?id=259
https://github.com/dlang/dmd/pull/1913
https://github.com/dlang/dmd/pull/5229


I oppose this change. You'd be better off not having unsigned types at all than 
this mess, which was Java's choice. But then there are more problems created.

Chaining opIndex

[deed via Digitalmars-d-learn]

struct Foo {
Bars bars;
...
}

struct Foos {
Foo[] arr;
Foo opIndex (size_t idx) { return arr[idx]; }
...
}

struct Bar {
// No Car[] cars;
...
}

struct Bars {
Bar[] arr;
Bar opIndex (size_t idx) { return arr[idx]; }
...
}

struct Car {
...
}

Foos foos;
Foo foo = foos[1];  // Works
Bar bar = foos[1].bars[2];  // Works
Car car = foos[1].bars[2].cars[3];  // Desired abstraction.

For any Bar there are some Cars, but Bar doesn't hold any Cars. 
In other words, there could be a function Car cars (Bar bar, 
size_t idx) { ... }, but that would be called with parens;


Car car = foos[i].bars[j].cars(k);

which would be inconsistent and confusing. Defining

struct Cars {
Car opIndex (Bar bar, size_t idx) {}
}

and

struct Bar {
Cars cars;
...
}

doesn't enable chaining and then would have to be used like this, 
AFAIK:


Car car = cars[foos[i].bars[j], k];

Which is out of the question. Any suggestions to achieve the 
desired abstraction in a clean manner?

Re: Always false float comparisons

[Walter Bright via Digitalmars-d]

On 5/9/2016 11:37 AM, Xinok wrote:

All of these scenarios are capable of producing "incorrect" results, are a
source of discrete bugs (often corner cases that we failed to consider and
test), and can be hard to detect. It's about time we stopped being stubborn and
flagged these things as warnings. Even if they require a special compiler flag
and are disabled by default, that's better than nothing.


I've used a B+D language that does as you suggest (Wirth Pascal). It was highly 
unpleasant to use, as the code became littered with casts. Casts introduce their 
own set of bugs.

[Issue 879] support for --gc-sections

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #24 from Walter Bright  ---
DMD on Linux/Elf/OSX now uses Dwarf exception handling info, so the deh
sections are no longer an issue.

--

Re: File size of exe: DMD vs LDC

[Walter Bright via Digitalmars-d]

On 5/9/2016 11:48 AM, David Nadlinger wrote:

AFAIR, because of how ModuleInfo/TypeInfo is emitted which makes linker never
collect sections because they are referenced at least from there. LDC was
intentionally modified to change code gen in that regard to make --gc-sections
work - David will surely tell more :)


It's something along those lines. What is certainly true is that I spent quite
some time trying to work around "interesting" linker behaviour to make this
work. You can find more details on my solution at
https://issues.dlang.org/show_bug.cgi?id=879.

I haven't looked at DMD's related codegen in a while, so I don't know what
exactly remains to be done there.

 — David


Thanks. At least the deh sections are a non-issue now that DMD generates Dwarf 
exception handling tables.

Re: Follow-up post explaining research rationale

[Adam D. Ruppe via Digitalmars-d]

On Monday, 9 May 2016 at 19:09:35 UTC, Joe Duarte wrote:
One D-specific question I do have: Have any women ever posted 
here?


Yes, I can think of three off the top of my head, and there's 
probably more that I just don't remember. Of course, I can name 
twenty male regular posters here without even thinking about it, 
so a skew is evident. I don't want to name any names though.


The vast majority people who are introduced to programming do 
not pursue it (likely true of many fields, but programming may 
see a smaller grab than most – this point requires a lot more 
context).


I'd be surprised if that point survives scrutiny, though I guess 
you need to define "introduced" and "pursue" to say more.


I'd also be surprised if you find an empirical gender gap after 
controlling for programming language syntax, too. Even if we 
grant that PL syntax is suboptimal, why would that result in a 
gender bias? But, hey, you never really know until you actually 
collect the data...

Re: How are you enjoying DConf? And where to go next?

[Iain Buclaw via Digitalmars-d]

On 9 May 2016 at 17:32, wobbles via Digitalmars-d
 wrote:
> On Monday, 9 May 2016 at 15:12:25 UTC, krzaq wrote:
>>
>> On Monday, 9 May 2016 at 09:58:32 UTC, Mark Isaacson wrote:
>>>
>>> Full recognition that there was way less demand for another US DConf...
>>> so perhaps somewhere easier to fly to?
>>>
>>> Reykjavik?
>>> Dublin?
>>> Oslo?
>>> Stockholm?
>>> Barcelona?
>>> London?
>>>
>>> Those are pretty good hubs and have solid airfare from the US... and all
>>> over. London and Barcelona in particular have a truly impressive number of
>>> flights in and out. They're all also really wonderful places to go
>>> exploring. Not a huge fan of Berlin as a city... that said the venue was
>>> pretty nice (a larger screen would've been better) and the food was
>>> definitely a step up from Utah.
>>
>>
>> It's not just the distance, but also the overall personal cost of
>> attending the conference. Berlin is, all things considered, a fairly cheap
>> city. London is a big NO in this regard, can't speak about the other
>> suggestions.
>
>
> I also think it should not only be in a decently cheap location, but also in
> a location where there is, by default, a high concentration of D users.
>
> Berlin fits that.
> Facebook fits that.
> Where's the other high concentration of D users?

Europe is fairly accessible for many people, if this year is anything
to go by.  I wouldn't mind going to another capital. Paris? Bucharest?
 If it must be the US, then I'd pick Boston. :-)

[Issue 16005] std.uni.toUpper returns wrong value for U+1FE2

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

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

--

[Issue 16005] std.uni.toUpper returns wrong value for U+1FE2

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
An excerpt from :

> # ; ; ; ; (;)? # 
[...]
> 1FE2; 1FE2; 03A5 0308 0300; 03A5 0308 0300; # GREEK SMALL LETTER UPSILON WITH 
> DIALYTIKA AND VARIA

That means, the correct uppercase of '\u1FE2' is "\u03A5\u0308\u0300". That's
three code points.

`"\u1FE2".toUpper` correctly returns that. `'\u1FE2'.toUpper` must return a
single dchar, so it cannot return the correct string. The documentation of
toUpper mentions this.

--

Re: Always false float comparisons

[tsbockman via Digitalmars-d]

On Monday, 9 May 2016 at 19:15:20 UTC, Xinok wrote:
It's a complex issue because there isn't necessarily right or 
wrong behavior, only things that *might* be wrong. But if we 
want to truly detect all possible cases of incorrect behavior, 
then we have to be exhaustive in our checks.


We absolutely, emphatically, DO NOT want to "detect all possible 
cases of incorrect behavior". Given the limited information 
available to the compiler and the intractability of the Halting 
Problem, the correct algorithm for doing so is this:


foreach(line; sourceCode)
warning("This line could not be proven correct.");

Only warnings with a reasonably high signal-to-noise ratio should 
be implemented.


Not necessarily. Reusing 1.3 from the original case, the 
following assertion passes:


float f = 1.3;
assert(f < 1.3);

And considering we also have <= and >=, we may as well check 
all of the comparison operators.


Because of the inevitability of rounding errors, FP code 
generally cannot be allowed to depend upon precise equality 
comparisons to any value other than zero (even implicit ones as 
in your example).


Warning about this makes sense:

float f = 1.3;
assert(f == 1.3);

Because the `==` makes it clear that the programmer's intent was 
to test for equality, and that will fail unexpectedly.


On the other hand, with `<`, `>`, `<=`, and `>=`, the compiler 
should generally assume that they are being used correctly, in a 
way that is tolerant of small rounding errors. Doing otherwise 
would cause tons of false positives in competently written FP 
code.


Educating programmers who've never studied how to write correct 
FP code is too complex of a task to implement via compiler 
warnings. The warnings should be limited to cases that are either 
obviously wrong, or where the warning is likely to be a net 
positive even for FP experts.

[Issue 15939] GC.collect causes deadlock in multi-threaded environment

[via Digitalmars-d-bugs]

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

--- Comment #12 from Aleksei Preobrazhenskii  ---
(In reply to Martin Nowak from comment #11)
> Did you have gdb attached while the signal was send? That sometime causes
> issues w/ signal delivery.

No, I didn't. I attached gdb to investigate deadlock which already happened at
that point.

> Are there any other reasons for switching to real-time signals?

I read that traditional signals are internally mapped to real-time signals. If
that's true I see no reason to stick with inferior emulated entity with weaker
guarantees.

> Which real-time signals are usually not used for other purposes?

Basically all real-time signals from range SIGRTMIN .. SIGRTMAX are intended
for custom use (SIGRTMIN might vary from platform to platform though, because
of things like NPTL and LinuxThreads).

--

Re: Always false float comparisons

[Xinok via Digitalmars-d]

On Monday, 9 May 2016 at 18:51:58 UTC, tsbockman wrote:

On Monday, 9 May 2016 at 18:37:10 UTC, Xinok wrote:

...
(3) Generalize it to all comparisons as well, including < and 
...
(3) Makes no sense though; inequalities with mixed 
floating-point types are perfectly safe. (Well, as safe as any 
floating-point code can be, anyway.)

...


Not necessarily. Reusing 1.3 from the original case, the 
following assertion passes:


float f = 1.3;
assert(f < 1.3);

And considering we also have <= and >=, we may as well check all 
of the comparison operators. It's a complex issue because there 
isn't necessarily right or wrong behavior, only things that 
*might* be wrong. But if we want to truly detect all possible 
cases of incorrect behavior, then we have to be exhaustive in our 
checks.

Follow-up post explaining research rationale

[Joe Duarte via Digitalmars-d]

Hi all,

As I mentioned on the other thread where I asked about D syntax, 
I'm a social scientist about to launch some studies of the 
effects of PL syntax on learnability, motivation to pursue 
programming, and differential gender effects on these factors. 
This is a long post – some of you wanted to know more about my 
research goals and rationale, and I also said I would post 
separately on the gender issue, so here we go...


As you know, women are starkly underrepresented in software 
engineering roles. I'm interested in zooming back to the 
decisions people are making when they're 16 or 19 re: programming 
as a career. I'm interested in people's *first encounters* with 
programming, in high school or college, how men and women might 
differentially assess programming as a career option, and why.


Let me note a few things: Someone on the other thread thought 
that my hypothesis was that women don't become programmers 
because of the semicolons and curly braces in PL syntax. That's 
not one of my hypotheses. I do think PL syntax is a large 
problem, and I have some hypotheses about how it 
disproportionately deters qualified women, but the issues I see 
go much deeper than what I've called the "punctuation noise" of 
semicolons and curly braces. (I definitely don't have any 
hypotheses about female perceptions of the aesthetics of curly 
braces, which some posters had inferred – none of this is about 
female aesthetic preferences.)


Also, I don't think D is particularly problematic – it has 
cleaner and clearer syntax than its contemporaries (well, we'll 
need careful research to know if it truly is clearer to a 
targeted population). I plan to use D as a presumptive *clearer 
syntax* condition in some studies – we'll see how it goes. 
Lastly, I'm not approaching the gender issue from an ideological 
or PC Principal perspective. My work will focus mostly on 
cognitive science and pedagogical factors – as you'll see below, 
I'm interested in diversity issues from lots of angles, but I 
don't subscribe to the diversity ideology that is fashionable in 
American academia.


One D-specific question I do have: Have any women ever posted 
here? I scoured a bunch of threads here recently and couldn't 
find a female poster. By this I mean a poster whose supplied name 
was female, where a proper name was supplied (some people just 
have usernames). Of course we don't really know who is posting, 
and there could be some George Eliot situations, but the 
presence/absence of self-identified women is useful enough. Women 
are underrepresented in programming, but the skew in online 
programming communities is even more extreme – we're seeing 
near-zero percent in lots of boards. This is not a D-specific 
problem. Does anyone know of occasions where women posted here? 
Links?


Getting back to the research, recent studies have argued that one 
reason women are underrepresented in certain STEM fields is that 
smart women have more options than smart men. So think of the 
right tail of the bell curve, the men and women in that region on 
the relevant aptitudes for STEM fields. There's some evidence 
that smart women have a broader set of skills -- *on average* -- 
than equivalently smart men, perhaps including better social 
skills (or more interest in social interaction). This probably 
fits with stereotypes and intuitions a lot of people already held 
(lots of stereotypes are accurate, as probability distributions 
and so forth).


I'm interested in monocultures and diversity issues in a number 
of domains. I've done some recent work on the lack of 
philosophical and political diversity in social science, 
particularly in social psychology, and how this has undermined 
the quality and validity of our research (here's a recent paper 
by me and my colleagues in Behavioral and Brain Sciences: 
http://dx.doi.org/10.1017/S0140525X14000430). My interest in the 
lack of gender diversity in programming is an entirely different 
research area, but there isn't much rigorous social science and 
cognitive psychology research on this topic, which surprised me. 
I think it's an important and interesting issue. I also think a 
lot of the diversity efforts that are salient in tech right now 
are acting far too late in the cycle, sort of just waiting for 
women and minorities to show up. The skew starts long before 
people graduate with a CS degree, and I think Google, Microsoft, 
Apple, Facebook, et al. should think deeply about how programming 
language design might be contributing to these effects 
(especially before they roll out any more C-like programming 
languages).


Informally, I think what's happening in many cases is that when 
smart women are exposed to programming, it looks ridiculous and 
they think something like "Screw this – I'm going to med school", 
or any of a thousand permutations of that sentiment.


Mainstream PL syntax is extremely unintuitive and poorly designed 
by known pedagogical, epistemological, and 

Re: Compiler silently ignores some method overloads

[Peter Häggman via Digitalmars-d-learn]

On Monday, 9 May 2016 at 11:22:37 UTC, pineapple wrote:

On Monday, 9 May 2016 at 00:27:17 UTC, Peter Häggman wrote:
Can you show your GLColor struct ? Maybe it contains an alias 
this or something else that mess the overload resolution.


My GLColor struct: http://pastebin.com/mUcA6G85


No problem here (tested with everything in a single module). I 
can't help more.

Front end version ?

foreach(i,ref val; ndim_arr)??

[Jay Norwood via Digitalmars-d-learn]

I noticed some discussion of Cartesian indexes in Julia, where 
the index is a tuple, along with some discussion of optimizing 
the index created for cache efficiency.  I could find foreach(ref 
val, m.byElement()), but didn't find an example that returned a 
tuple index.   Is that supported?


http://julialang.org/blog/2016/02/iteration

http://julialang.org/blog/2016/03/arrays-iteration

Re: Always false float comparisons

[tsbockman via Digitalmars-d]

On Monday, 9 May 2016 at 18:37:10 UTC, Xinok wrote:

(1) Yes, emit a warning for this case.
(2) Generalize it to all variables, like Nordlöw suggested.
(3) Generalize it to all comparisons as well, including < and > 
.
(4) While we're at it, let's also emit a warning when comparing 
signed and unsigned types.
(5) Dare I say it... warn against implicit conversions of 
double to float.

(6) The same applies to "real" as well.

All of these scenarios are capable of producing "incorrect" 
results, are a source of discrete bugs (often corner cases that 
we failed to consider and test), and can be hard to detect. 
It's about time we stopped being stubborn and flagged these 
things as warnings. Even if they require a special compiler 
flag and are disabled by default, that's better than nothing.


(1) is good, because the code in question is always wrong.

(2) is a logical extension, in those cases where constant folding 
and VRP can prove that the code is always wrong.


(3) Makes no sense though; inequalities with mixed floating-point 
types are perfectly safe. (Well, as safe as any floating-point 
code can be, anyway.)


(4) is already planned; it's just taking *a lot* longer than 
anticipated to actually implement it:

https://issues.dlang.org/show_bug.cgi?id=259
https://github.com/dlang/dmd/pull/1913
https://github.com/dlang/dmd/pull/5229

Re: File size of exe: DMD vs LDC

[David Nadlinger via Digitalmars-d]

On Monday, 9 May 2016 at 13:53:45 UTC, Dicebot wrote:

On Monday, 9 May 2016 at 13:48:50 UTC, Walter Bright wrote:

On 5/9/2016 5:24 AM, Jacob Carlborg wrote:

LDC can strip sections which DMD cannot.


Why not?


AFAIR, because of how ModuleInfo/TypeInfo is emitted which 
makes linker never collect sections because they are referenced 
at least from there. LDC was intentionally modified to change 
code gen in that regard to make --gc-sections work - David will 
surely tell more :)


It's something along those lines. What is certainly true is that 
I spent quite some time trying to work around "interesting" 
linker behaviour to make this work. You can find more details on 
my solution at https://issues.dlang.org/show_bug.cgi?id=879.


I haven't looked at DMD's related codegen in a while, so I don't 
know what exactly remains to be done there.


 — David

Re: Always false float comparisons

[Jonathan M Davis via Digitalmars-d]

On Monday, May 09, 2016 02:10:19 Walter Bright via Digitalmars-d wrote:
> Don Clugston pointed out in his DConf 2016 talk that:
>
>  float f = 1.30;
>  assert(f == 1.30);
>
> will always be false since 1.30 is not representable as a float. However,
>
>  float f = 1.30;
>  assert(f == cast(float)1.30);
>
> will be true.
>
> So, should the compiler emit a warning for the former case?

It does seem like having implicit conversions with floating point numbers is
problematic in general, though warning about it or making it illegal could
very well be too annoying to be worth it. But at bare minimum, warning about
literals not matching the type that they're being compared against when
there _is_ a literal that would be of the same type is probably worth
warning about - and that could apply to more than just floating point
values. But figuring out when implicit conversions are genuinely useful and
should be allowed and when they're more trouble than they're worth is
surprisingly hard to get right. :(

- Jonathan M Davis

[Issue 11229] std.string.toLower is slow

[via Digitalmars-d-bugs]

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

--- Comment #8 from Jack Stouffer  ---
(In reply to Jon Degenhardt from comment #7)
> auto mapAsLowerCase(Range)(Range str)
> if (isInputRange!Range && isSomeChar!(ElementEncodingType!Range) &&
> !isConvertibleToString!Range)
> {
> static if (ElementEncodingType!Range.sizeof < dchar.sizeof)
> {
> import std.utf : byDchar;
> return str.byDchar.mapAsLowerCase;
> }
> else
> {
> import std.algorithm : map;
> import std.uni : toLower;
> 
> return str.map!(x => x.toLower);
> }
> }

I attempted to replace asLowerCase with this, but it's blocked by
https://issues.dlang.org/show_bug.cgi?id=16005

--

Re: Walter's Famous German Language Essentials Guide

[Jonathan M Davis via Digitalmars-d]

On Friday, May 06, 2016 13:34:08 Andrei Alexandrescu via Digitalmars-d wrote:
> On 5/6/16 1:04 PM, Chris wrote:
> > Ok, guilty as charged
>
> No need to feel singled out, most of us do this once in a while. We're
> exploring either the creation of an "internal" forum (more focused) or
> an "offtopic" forum where such discussions can go. -- Andrei

The main problem with the "offtopic" forum idea is that most of the time
when we end up with an off-topic discussion, it's because a perfectly
on-topic discussion devolves into an off-topic one. It may very well be a
good idea to create an off-topic forum, but I doubt that it'll get a lot of
traffic or that it will really fix the OT problems here aside from making it
possible to tell folks to take it to the OT forum if they want to continue
to discuss whatever OT thing they started discussing. It's actually one area
where more traditional forum software might do better, because then threads
(or portions of them) could be moved to different forums so that OT
discussions could theoretically be moved out of on-topic threads. But that
would also required increased moderation, which isn't something that we're
really looking for either.

As for a more focused forum, that probably depends at least somewhat on what
it's focused on (though any forum will likely risk some topics devolving
into OT discussions) - and we already created dlang-study for at least some
of the more directed discussions, and that hasn't really gone much of
anywhere.

I think that part of the problem is that we seem to have had fewer useful
discussions of late (for whatever reason), so the OT discussions have stood
out more, and we've gotten at least a couple that have gotten pretty far out
of hand with discussions on gender and whatnot. So, it seems like the recent
situation is worse than it's been historically. Historically, I don't think
that OT discussions have been that big of a problem, whereas recently, it's
been pretty bad.

- Jonathan M Davis

[Issue 16005] New: std.uni.toUpper returns wrong value for U+1FE2

[via Digitalmars-d-bugs]

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

  Issue ID: 16005
   Summary: std.uni.toUpper returns wrong value for U+1FE2
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

'\u1FE2'.toUpper returns U+1FE2 instead of the correct answer U+03A5

--

Re: Always false float comparisons

[Xinok via Digitalmars-d]

On Monday, 9 May 2016 at 09:10:19 UTC, Walter Bright wrote:

Don Clugston pointed out in his DConf 2016 talk that:

float f = 1.30;
assert(f == 1.30);

will always be false since 1.30 is not representable as a 
float. However,


float f = 1.30;
assert(f == cast(float)1.30);

will be true.

So, should the compiler emit a warning for the former case?


(1) Yes, emit a warning for this case.
(2) Generalize it to all variables, like Nordlöw suggested.
(3) Generalize it to all comparisons as well, including < and > .
(4) While we're at it, let's also emit a warning when comparing 
signed and unsigned types.
(5) Dare I say it... warn against implicit conversions of double 
to float.

(6) The same applies to "real" as well.

All of these scenarios are capable of producing "incorrect" 
results, are a source of discrete bugs (often corner cases that 
we failed to consider and test), and can be hard to detect. It's 
about time we stopped being stubborn and flagged these things as 
warnings. Even if they require a special compiler flag and are 
disabled by default, that's better than nothing.

[Issue 3960] Unused local variables not reported

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=3960
Issue 3960 depends on issue 7989, which changed state.

Issue 7989 Summary: isInputRange and isForwardRange declare unused variables
https://issues.dlang.org/show_bug.cgi?id=7989

   What|Removed |Added

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

--

[Issue 7989] isInputRange and isForwardRange declare unused variables

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dlang.org/commit/eb74b278dfde3982ddeaf6f7a57af76462a8a9b0
Fix Issues 3960 and 7989

--

[Issue 3960] Unused local variables not reported

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dlang.org/commit/eb74b278dfde3982ddeaf6f7a57af76462a8a9b0
Fix Issues 3960 and 7989

--

[Issue 3960] Unused local variables not reported

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Battle-plan for CTFE

[Robert burner Schadek via Digitalmars-d-announce]

awesome news :-) thanks you

Re: Battle-plan for CTFE

[David Nadlinger via Digitalmars-d-announce]

Hi Stefan,

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:

My Plan is as follows.


I think you guys talked about it at the conference, but be sure 
to coordinate with Timon Gehr. You'll want to steal all the best 
ideas from the various implementations anyway. ;)


Do Dataflow analysis on the code that is to be ctfe'd so we can 
tell beforehand if we need to store state in the ctfe stack or 
not.


Or baring proper data-flow analysis: RefCouting the variables 
on the ctfe-stack could also be a solution.


I presume by "store state" you mean persisting objects beyond the 
bounds of a single CTFE invocation? My first inclination here 
would simply be to make all allocations from a new arena each 
time CTFE is entered (can also re-use memory from prior runs for 
that), do a deep-copy of the result (converting it to full AST 
nodes, etc.), and then drop the entire arena. But probably you 
have thought of (and discarded) this already.


 — David

[Issue 15966] [REG 2.071] {public,protected} imports in base class ignored on symbol lookup

[via Digitalmars-d-bugs]

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

--- Comment #7 from Martin Nowak  ---
(In reply to Walter Bright from comment #3)
> The trouble is that imports in the base class will override global imports
> referred to by the derived class. This is exactly the kind of problem the
> import changes were so strongly desired to fix.
> 
> The compiler is working as designed, this is deliberate behavior.

Even if desired we'd at least have to integrate this w/ our
-transition=checkimport/imports infrastructure.
Should this really apply to public imports as well?

--

Re: How are you enjoying DConf? And where to go next?

[deadalnix via Digitalmars-d]

On Monday, 9 May 2016 at 15:32:05 UTC, wobbles wrote:
I also think it should not only be in a decently cheap 
location, but also in a location where there is, by default, a 
high concentration of D users.


Berlin fits that.
Facebook fits that.
Where's the other high concentration of D users?


Lots of D user in Japan and Australia. Many scattered around the 
US.

Re: LDC 1.0.0-beta1 has been released! Please help testing!

[Kai Nacke via Digitalmars-d-announce]

On Monday, 9 May 2016 at 07:31:39 UTC, Guillaume Chatelet wrote:

On Monday, 25 April 2016 at 06:42:02 UTC, Kai Nacke wrote:

Hi everyone,

LDC 1.0.0-beta1, the LLVM-based D compiler, is available for 
download!
This BETA release is based on the 2.070.2 frontend and 
standard library and supports LLVM 3.5-3.8.


The 1.0 release will be a major milestone. Please help testing 
to make it the best release ever!
We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM 
(armv7hf). :-)


As usual, you can find links to the changelog and the binary 
packages over at digitalmars.D.ldc:

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

Regards,
Kai


Why does it requires libconfig.so.8? Could you static link it?


It's a bug. See https://github.com/ldc-developers/ldc/issues/1460.
(Hopefully fixed now.)

Regards,
Kai

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On 09 May 2016 19:01, "Stefan Koch via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> Hi Guys,
>
> I have been looking into the DMD now to see what I can do about CTFE.
> Unfortunately It is a pretty big mess to untangle.
> Code responsible for CTFE is in at least 3 files.
> [dinterpret.d, ctfeexpr.d, constfold.d]
> I was shocked to discover that the PowExpression actually depends on
phobos! (depending on the exact codePath it may or may not compile...)
> which let to me prematurely stating that it worked at ctfe [
http://forum.dlang.org/thread/ukcoibejffinknrbz...@forum.dlang.org]
>
> My Plan is as follows.
>
> Add a new file for my ctfe-interpreter and update it gradually to take
more and more of the cases the code in the files mentioned above was used
for.
>
> Do Dataflow analysis on the code that is to be ctfe'd so we can tell
beforehand if we need to store state in the ctfe stack or not.
>
> Or baring proper data-flow analysis: RefCouting the variables on the
ctfe-stack could also be a solution.
>
> I will post more details as soon as I dive deeper into the code.
>
>

Will be awesome. Particularly if you document the workings of ctfe, might
make a great set of articles for a blog.

Re: Querying Function Template Restrictions

[Meta via Digitalmars-d-learn]

On Monday, 9 May 2016 at 11:57:11 UTC, Nordlöw wrote:
In what ways can I compile-time introspect the template 
restrictions of a specific function overload set in D?


In other words if I have, for instance,

T f(T)(T x) if (isFloat!T) {}
T f(T)(T x) if (isInteger!T) {}

T g(T)(T x) if (isFloat!T && isInteger!T) {}

can I somehow at compile-time query that

- f() is a function having *two* overloads where the first 
takes an integer and the second takes a float?
- g() is a function having *one* overload taking either an 
integer or a float?


Or is it only via trial-and-error calls such as

__traits(compiles, { f(1); } ); // ok
__traits(compiles, { f(1.2); } ); // ok
__traits(compiles, { f("1"); } ); // not ok
__traits(compiles, { f('1'); } ); // not ok

__traits(compiles, { g(1); } ); // ok
__traits(compiles, { g(1.2); } ); // ok
__traits(compiles, { g("1"); } ); // not ok
__traits(compiles, { g('1'); } ); // not ok

I can get that information?


Unfortunately, you cannot introspect template constraints. The 
only thing you can do is check if calling it with given arguments 
compiles or not.

Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

Hi Guys,

I have been looking into the DMD now to see what I can do about 
CTFE.

Unfortunately It is a pretty big mess to untangle.
Code responsible for CTFE is in at least 3 files.
[dinterpret.d, ctfeexpr.d, constfold.d]
I was shocked to discover that the PowExpression actually depends 
on phobos! (depending on the exact codePath it may or may not 
compile...)
which let to me prematurely stating that it worked at ctfe 
[http://forum.dlang.org/thread/ukcoibejffinknrbz...@forum.dlang.org]


My Plan is as follows.

Add a new file for my ctfe-interpreter and update it gradually to 
take more and more of the cases the code in the files mentioned 
above was used for.


Do Dataflow analysis on the code that is to be ctfe'd so we can 
tell beforehand if we need to store state in the ctfe stack or 
not.


Or baring proper data-flow analysis: RefCouting the variables on 
the ctfe-stack could also be a solution.


I will post more details as soon as I dive deeper into the code.

Re: Always false float comparisons

[Nordlöw via Digitalmars-d]

On Monday, 9 May 2016 at 12:28:04 UTC, Walter Bright wrote:

On 5/9/2016 4:38 AM, Nordlöw wrote:

Would that include comparison of variables only aswell?

No.


Why?

[Issue 14835] Statement is not reachable doesn't play along generic code

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com
   Severity|normal  |major

--- Comment #7 from Jack Stouffer  ---
This has come up again: https://github.com/dlang/phobos/pull/4287

This issue is a major annoyance when writing template code and almost anyone
writing optimized code with static if's will run into it eventually, so I'm
raising the importance of this.

--

Re: How are you enjoying DConf? And where to go next?

[wobbles via Digitalmars-d]

On Monday, 9 May 2016 at 15:12:25 UTC, krzaq wrote:

On Monday, 9 May 2016 at 09:58:32 UTC, Mark Isaacson wrote:
Full recognition that there was way less demand for another US 
DConf... so perhaps somewhere easier to fly to?


Reykjavik?
Dublin?
Oslo?
Stockholm?
Barcelona?
London?

Those are pretty good hubs and have solid airfare from the 
US... and all over. London and Barcelona in particular have a 
truly impressive number of flights in and out. They're all 
also really wonderful places to go exploring. Not a huge fan 
of Berlin as a city... that said the venue was pretty nice (a 
larger screen would've been better) and the food was 
definitely a step up from Utah.


It's not just the distance, but also the overall personal cost 
of attending the conference. Berlin is, all things considered, 
a fairly cheap city. London is a big NO in this regard, can't 
speak about the other suggestions.


I also think it should not only be in a decently cheap location, 
but also in a location where there is, by default, a high 
concentration of D users.


Berlin fits that.
Facebook fits that.
Where's the other high concentration of D users?

Re: How are you enjoying DConf? And where to go next?

[krzaq via Digitalmars-d]

On Monday, 9 May 2016 at 09:58:32 UTC, Mark Isaacson wrote:
Full recognition that there was way less demand for another US 
DConf... so perhaps somewhere easier to fly to?


Reykjavik?
Dublin?
Oslo?
Stockholm?
Barcelona?
London?

Those are pretty good hubs and have solid airfare from the 
US... and all over. London and Barcelona in particular have a 
truly impressive number of flights in and out. They're all also 
really wonderful places to go exploring. Not a huge fan of 
Berlin as a city... that said the venue was pretty nice (a 
larger screen would've been better) and the food was definitely 
a step up from Utah.


It's not just the distance, but also the overall personal cost of 
attending the conference. Berlin is, all things considered, a 
fairly cheap city. London is a big NO in this regard, can't speak 
about the other suggestions.

Re: Always false float comparisons

[qznc via Digitalmars-d]

On Monday, 9 May 2016 at 12:24:05 UTC, John Colvin wrote:

On Monday, 9 May 2016 at 11:26:55 UTC, Walter Bright wrote:

On 5/9/2016 3:16 AM, Jens Mueller via Digitalmars-d wrote:
Warning for those comparisons should be fine. Shouldn't mix 
them anyway.


Too onerous.


Surely not too onerous if we're only talking about == ? Mixing 
floating point types on either side of == seems like a pretty 
solidly bad idea.


Why only == ? The example also applies to opCmp.

float f = 1.30;
assert(f >= 1.30);
assert(f <= 1.30);

Re: parameter pack to inputRange

[Alex Parrill via Digitalmars-d-learn]

On Sunday, 8 May 2016 at 14:11:31 UTC, Ali Çehreli wrote:
I like Alex Parrill's only() solution but it allocates a 
dynamic array as well by doing the equivalent of [args] in the 
guts of its implementation.


No it does not.

The constructor does `this.data = [values];`, but `this.data` is 
a fixed-sized array, which is stored in the structure itself. No 
allocation needs to happen (it should be the same as the foreach 
loop in your implementation).


You guys are just re-inventing `only`.

Re: std.experimental.allocator and @nogc

[rikki cattermole via Digitalmars-d]

On 10/05/2016 1:05 AM, ZombineDev wrote:

On Monday, 9 May 2016 at 12:37:24 UTC, rikki cattermole wrote:

On 10/05/2016 12:33 AM, ZombineDev wrote:

On Monday, 9 May 2016 at 12:02:19 UTC, rikki cattermole wrote:

On 09/05/2016 11:56 PM, ZombineDev wrote:

On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:

On 09/05/2016 11:12 PM, ZombineDev wrote:

On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote:

I've done windowing and image libraries before.
You are correct, you do not need OOP.

But if you want to keep implementation nicely separated out from
usage, you really do. Which is a major part of my requirements.


Well, in my example above, everything is nicely separated, easy to
use,
yet quite flexible. And still there is no Java-style OOP. Do you
have
any examples, where the use of classic OOP would provide a strictly
superior design?


You're using templates. While this might be ok for image library.
I cannot use this for the windowing library. The implementation may
not be known and must be plugable at runtime.
The reality is, just because you say you know about something at
compile time doesn't mean the system that runs a program does.


I'm still not convinced. You have a fixed at CT number of
implementations. Even if you don't know at CT the actual platform that
will be used, you can still choose at RT the correct template.
Example:


You do not.
Shared libraries remember them?


You will statically link the windowing library and it will dynamically
load the necessary shared/dynamic libaries of the platform at runtime.
What's the problem? E.g. Derelict* does the same.


// platform name can be "X11", "mir", "Wayland", etc.
auto getPlatformWindow(CTArgs...)(string platformNameRTArg)
{
switch (platformNameRTArg.toLower)
{
default:
 enforce(false, "Unknown platform: " ~ platformNameRTArg);

foreach (platform; EnumMembers!Platform)
case name.stringof:
 // Use std.experiment.typecons.Wrap if you need a
common type.
 return getWindow!(name, CTArgs);
}
assert (0);
}


Platform is undefined, did you mean IPlatform?


Platform obviously an enum. The return type can be a plain struct, a
Variant, or a std.experimental.typecons.wrap, depending on your needs.


But that's besides the point. Even with OOP, your return type can
be an
interface that has template parameters like allocators, policies, etc.
You're providing some the arguments at CT and the rest of the return
type is dynamically polymorphic. E.g.:

interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);


Sure you can, but now you have added another layer of indirection
between implementation and usage because you can't use templated types
in between.


There's no indirection (besides the interface, which would also be the
case with your approach) and you **should** use templated types :)


My point is that there's no need for IAllocator, even if you want
to use
OOP so badly.
But in most cases you will either write different code for different
platforms, making interfaces unnecessary, or you would be able to hide
the differences behind a struct.

And when the allocator and the other policies are template parameters
you will know at CT that your code is @nogc.


Again, no templates. You cannot initialize them at runtime, and since
you won't know all implementations until it executes, well, you've got
a problem.
Its a many to many problem. I faced this with Cmsed as well.


As I demonstrated, it's not a problem. You just need to choose the
template at runtime. You have a fixed number of implementations which
are all statically linked. Only the one chosen at runtime will be
initialized and at the moment of initialization it can do the necessary
dynamic loading.

In the example above:


interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);


Since you don't need to switch Allocator implementations at run-time
(and if you switch them you will most certainly get silent memory
corruption), you can leverage the fact that some stuff are known at CT
and leave the rest to RT.


At this point, all I'm going to say is, prove me wrong.
Give me all the power I have now and do it the way you want to.


Challange accepted ;)


PR's welcome.


Well, I'll maybe write my own implementation just cuz it's fun. May be
we can contribute in the future :)


 https://github.com/rikkimax/alphaPhobos/


From a cursory look, I would have written
std.experimental.ui.rendering.IDisplay like this:

struct Display
{
// I prefer Nullable because not all information
// could be available on all platforms.
// May be some things are common everywhere,
// but I don't have time to check, right now.

Nullable!string   name;
Nullable!vec2!ushort  size;
Nullable!uint refreshRate;
Nullable!uint luminosity;

Re: parameter pack to inputRange

[Dicebot via Digitalmars-d-learn]

On Monday, 9 May 2016 at 12:36:00 UTC, Ali Çehreli wrote:

On 05/09/2016 03:44 AM, Dicebot wrote:

> Ali version generates a compile-time switch for index

I think it's a run-time switch, generated by a compile-time 
foreach:


E front() {
final switch (index) {// <-- RUNTIME
/* static */ foreach (i, arg; Args) { // <-- COMPILE 
TIME

case i:   // <-- RUNTIME
return arg;   // <-- RUNTIME
}
}
}

Quite confusing. :)


It becomes even more confusing if you keep in mind that it is a 
final switch on an index range known at compile-time - which 
means that as long as whole template can be inlined and actual 
index is know at CT, compiler can eliminate all runtime indexing 
checks and just replace it with matching literal/symbol.

Re: C#7 features

[maik klein via Digitalmars-d-announce]

On Monday, 9 May 2016 at 13:09:24 UTC, Jacob Carlborg wrote:

On 2016-05-09 14:46, John wrote:

C# 7's tuples are something different though. They don't even 
map to

System.Tuple. The syntax is:

   (int x, int y) GetPoint() {
 return (500, 400);
   }

   var p = GetPoint();
   Console.WriteLine($"{p.x}, {p.y}");


Would be nice to have in D. Both with and without named fields.


I mean it is not much shorter than in D

alias Point = Tuple!(int, "x", int, "y");
Point getPoint(){
return Point(500, 400);
}

What would be nice though if tuples would be implicitly 
convertible to named tuples, if the types matches.


Tuple!(int, "x", int, "y") getPoint(){
return tuple(500, 400);
}

Re: File size of exe: DMD vs LDC

[Dicebot via Digitalmars-d]

On Monday, 9 May 2016 at 13:48:50 UTC, Walter Bright wrote:

On 5/9/2016 5:24 AM, Jacob Carlborg wrote:

LDC can strip sections which DMD cannot.


Why not?


AFAIR, because of how ModuleInfo/TypeInfo is emitted which makes 
linker never collect sections because they are referenced at 
least from there. LDC was intentionally modified to change code 
gen in that regard to make --gc-sections work - David will surely 
tell more :)

Re: File size of exe: DMD vs LDC

[Walter Bright via Digitalmars-d]

On 5/9/2016 5:24 AM, Jacob Carlborg wrote:

LDC can strip sections which DMD cannot.


Why not?

Re: Always false float comparisons

[Steven Schveighoffer via Digitalmars-d]

On 5/9/16 7:26 AM, Walter Bright wrote:

I wonder what's the difference between 1.30f and cast(float)1.30.


There isn't one.


I know this is a bit band-aid-ish, but if one is comparing literals to a 
float, why not treat the literal as the type being compared against? In 
other words, imply the 1.3f. This isn't integer-land where promotions do 
not change the outcome.


What I see here is that double(1.3) cannot be represented as a float. So 
right there, the compiler can tell you, no, this is never going to be 
true. Something stinks when you can write an always-false expression as 
an if conditional by accident.


-Steve

[Issue 15974] Spurious error: argument to mixin must be a string, not (expression()) of type string

[via Digitalmars-d-bugs]

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

--- Comment #1 from Kenji Hara  ---
I got a real minimized test case from incomplete sample code.

// test.d

string format(Args...)(string fmt, Args args)
{
return "";
}

void loadDeviceFns()
{
enum allFns = ["vkCreateSampler"];
foreach (f;allFns)
{
mixin("%s".format(f));
}
}

$ dmd -o- test
test.d(11): Error: variable f cannot be read at compile time
test.d(11):called from here: format("%s", f)
test.d(11): Error: argument to mixin must be a string, not (format("%s", f)) of
type string

--

Re: std.experimental.allocator and @nogc

[ZombineDev via Digitalmars-d]

On Monday, 9 May 2016 at 12:37:24 UTC, rikki cattermole wrote:

On 10/05/2016 12:33 AM, ZombineDev wrote:

On Monday, 9 May 2016 at 12:02:19 UTC, rikki cattermole wrote:

On 09/05/2016 11:56 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole 
wrote:

On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole 
wrote:

I've done windowing and image libraries before.
You are correct, you do not need OOP.

But if you want to keep implementation nicely separated 
out from
usage, you really do. Which is a major part of my 
requirements.


Well, in my example above, everything is nicely separated, 
easy to

use,
yet quite flexible. And still there is no Java-style OOP. 
Do you have
any examples, where the use of classic OOP would provide a 
strictly

superior design?


You're using templates. While this might be ok for image 
library.
I cannot use this for the windowing library. The 
implementation may

not be known and must be plugable at runtime.
The reality is, just because you say you know about 
something at
compile time doesn't mean the system that runs a program 
does.


I'm still not convinced. You have a fixed at CT number of
implementations. Even if you don't know at CT the actual 
platform that
will be used, you can still choose at RT the correct 
template. Example:


You do not.
Shared libraries remember them?


You will statically link the windowing library and it will 
dynamically
load the necessary shared/dynamic libaries of the platform at 
runtime.

What's the problem? E.g. Derelict* does the same.


// platform name can be "X11", "mir", "Wayland", etc.
auto getPlatformWindow(CTArgs...)(string platformNameRTArg)
{
switch (platformNameRTArg.toLower)
{
default:
 enforce(false, "Unknown platform: " ~ 
platformNameRTArg);


foreach (platform; EnumMembers!Platform)
case name.stringof:
 // Use std.experiment.typecons.Wrap if you 
need a

common type.
 return getWindow!(name, CTArgs);
}
assert (0);
}


Platform is undefined, did you mean IPlatform?


Platform obviously an enum. The return type can be a plain 
struct, a
Variant, or a std.experimental.typecons.wrap, depending on 
your needs.


But that's besides the point. Even with OOP, your return 
type can be an
interface that has template parameters like allocators, 
policies, etc.
You're providing some the arguments at CT and the rest of 
the return

type is dynamically polymorphic. E.g.:

interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);


Sure you can, but now you have added another layer of 
indirection
between implementation and usage because you can't use 
templated types

in between.


There's no indirection (besides the interface, which would 
also be the
case with your approach) and you **should** use templated 
types :)


My point is that there's no need for IAllocator, even if you 
want to use

OOP so badly.
But in most cases you will either write different code for 
different
platforms, making interfaces unnecessary, or you would be 
able to hide

the differences behind a struct.

And when the allocator and the other policies are template 
parameters

you will know at CT that your code is @nogc.


Again, no templates. You cannot initialize them at runtime, 
and since
you won't know all implementations until it executes, well, 
you've got

a problem.
Its a many to many problem. I faced this with Cmsed as well.


As I demonstrated, it's not a problem. You just need to choose 
the
template at runtime. You have a fixed number of 
implementations which
are all statically linked. Only the one chosen at runtime will 
be
initialized and at the moment of initialization it can do the 
necessary

dynamic loading.

In the example above:


interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);


Since you don't need to switch Allocator implementations at 
run-time
(and if you switch them you will most certainly get silent 
memory
corruption), you can leverage the fact that some stuff are 
known at CT

and leave the rest to RT.


At this point, all I'm going to say is, prove me wrong.
Give me all the power I have now and do it the way you want to.


Challange accepted ;)


PR's welcome.


Well, I'll maybe write my own implementation just cuz it's fun. 
May be we can contribute in the future :)



 https://github.com/rikkimax/alphaPhobos/


From a cursory look, I would have written 
std.experimental.ui.rendering.IDisplay like this:


struct Display
{
// I prefer Nullable because not all information
// could be available on all platforms.
// May be some things are common everywhere,
// but I don't have time to check, right now.

Nullable!string   name;
Nullable!vec2!ushort  size;
Nullable!uint refreshRate;
Nullable!uint luminosity;

Re: C#7 features

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-05-09 14:46, John wrote:


C# 7's tuples are something different though. They don't even map to
System.Tuple. The syntax is:

   (int x, int y) GetPoint() {
 return (500, 400);
   }

   var p = GetPoint();
   Console.WriteLine($"{p.x}, {p.y}");


Would be nice to have in D. Both with and without named fields.

--
/Jacob Carlborg

Re: powExpressions work at ctfe

[Stefan Koch via Digitalmars-d]

On Monday, 9 May 2016 at 12:49:16 UTC, Stefan Koch wrote:

On Monday, 9 May 2016 at 12:33:33 UTC, Stefan Koch wrote:

On Monday, 9 May 2016 at 12:24:18 UTC, Timon Gehr wrote:

[...]


I see.
I did not test a floating point value at the left-hand site.
working on a fix.


okay the workaround would be just to avoid pointer casts.
And use bitwise operations to convert the values.
Another option is not to jit std.math routines at ctfe.

I would prefer the second option, any opinions ?


Yet another option is using soft-float for ctfe, that would also 
prevent issues with cross-compiled binarys that have ctfe in them.

[Issue 9766] align(n) with n compile-time constant

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #6 from Kenji Hara  ---
https://github.com/dlang/dmd/pull/5750
https://github.com/dlang/dlang.org/pull/1293

--

[Issue 15966] [REG 2.071] {public,protected} imports in base class ignored on symbol lookup

[via Digitalmars-d-bugs]

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

--- Comment #6 from Mathias Lang  ---
(In reply to Walter Bright from comment #3)
> The trouble is that imports in the base class will override global imports
> referred to by the derived class. This is exactly the kind of problem the
> import changes were so strongly desired to fix.
> 
> The compiler is working as designed, this is deliberate behavior.

I don't see why it should be a problem. A base class in another module can
already override global imports by introducing new local symbols.
It's expected when changing a base class than touching any non-private symbol
can affect derived class.

--

Re: powExpressions work at ctfe

[Stefan Koch via Digitalmars-d]

On Monday, 9 May 2016 at 12:33:33 UTC, Stefan Koch wrote:

On Monday, 9 May 2016 at 12:24:18 UTC, Timon Gehr wrote:

On 09.05.2016 11:24, Stefan Koch wrote:

At Dconf Manu asked to use pow expressions at CTFE.
Luckily he can.
powExpressions work at ctfe.


enum x=2.4^^4.5;

DMD master:

./../../phobos/std/math.d(4857): Error: cannot convert  
to ushort* at compile time
./../../phobos/std/math.d(6113):called from here: 
isNaN(y)
./../../phobos/std/math.d(6303):called from here: 
impl(cast(real)x, cast(real)y)

ctfepow.d(1):called from here: pow(2.4, 4.5)


I see.
I did not test a floating point value at the left-hand site.
working on a fix.


okay the workaround would be just to avoid pointer casts.
And use bitwise operations to convert the values.
Another option is not to jit std.math routines at ctfe.

I would prefer the second option, any opinions ?

Re: C#7 features

[John via Digitalmars-d-announce]

On Monday, 9 May 2016 at 00:44:09 UTC, Peter Häggman wrote:

Their tuples seem to be a complete DIY:

https://msdn.microsoft.com/en-us/library/system.tuple(v=vs.110).aspx


C# 7's tuples are something different though. They don't even map 
to System.Tuple. The syntax is:


  (int x, int y) GetPoint() {
return (500, 400);
  }

  var p = GetPoint();
  Console.WriteLine($"{p.x}, {p.y}");

Re: Always false float comparisons

[Ethan Watson via Digitalmars-d]

On Monday, 9 May 2016 at 12:30:13 UTC, Walter Bright wrote:

Promoting to double does not lose precision.


Yes, badly worded on my part, I was getting at the original 
assignment from double to float.

Re: parameter pack to inputRange

[Ali Çehreli via Digitalmars-d-learn]

On 05/09/2016 03:44 AM, Dicebot wrote:

> Ali version generates a compile-time switch for index

I think it's a run-time switch, generated by a compile-time foreach:

E front() {
final switch (index) {// <-- RUNTIME
/* static */ foreach (i, arg; Args) { // <-- COMPILE TIME
case i:   // <-- RUNTIME
return arg;   // <-- RUNTIME
}
}
}

Quite confusing. :)

> that returns either literals or external variables by
> referencing their symbol directly.

I see. So, a parameter pack (AliasSeq) uses 'alias' template parameters 
for symbols. Makes sense...


Ali

Re: std.experimental.allocator and @nogc

[rikki cattermole via Digitalmars-d]

On 10/05/2016 12:33 AM, ZombineDev wrote:

On Monday, 9 May 2016 at 12:02:19 UTC, rikki cattermole wrote:

On 09/05/2016 11:56 PM, ZombineDev wrote:

On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:

On 09/05/2016 11:12 PM, ZombineDev wrote:

On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote:

I've done windowing and image libraries before.
You are correct, you do not need OOP.

But if you want to keep implementation nicely separated out from
usage, you really do. Which is a major part of my requirements.


Well, in my example above, everything is nicely separated, easy to
use,
yet quite flexible. And still there is no Java-style OOP. Do you have
any examples, where the use of classic OOP would provide a strictly
superior design?


You're using templates. While this might be ok for image library.
I cannot use this for the windowing library. The implementation may
not be known and must be plugable at runtime.
The reality is, just because you say you know about something at
compile time doesn't mean the system that runs a program does.


I'm still not convinced. You have a fixed at CT number of
implementations. Even if you don't know at CT the actual platform that
will be used, you can still choose at RT the correct template. Example:


You do not.
Shared libraries remember them?


You will statically link the windowing library and it will dynamically
load the necessary shared/dynamic libaries of the platform at runtime.
What's the problem? E.g. Derelict* does the same.


// platform name can be "X11", "mir", "Wayland", etc.
auto getPlatformWindow(CTArgs...)(string platformNameRTArg)
{
switch (platformNameRTArg.toLower)
{
default:
 enforce(false, "Unknown platform: " ~ platformNameRTArg);

foreach (platform; EnumMembers!Platform)
case name.stringof:
 // Use std.experiment.typecons.Wrap if you need a
common type.
 return getWindow!(name, CTArgs);
}
assert (0);
}


Platform is undefined, did you mean IPlatform?


Platform obviously an enum. The return type can be a plain struct, a
Variant, or a std.experimental.typecons.wrap, depending on your needs.


But that's besides the point. Even with OOP, your return type can be an
interface that has template parameters like allocators, policies, etc.
You're providing some the arguments at CT and the rest of the return
type is dynamically polymorphic. E.g.:

interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);


Sure you can, but now you have added another layer of indirection
between implementation and usage because you can't use templated types
in between.


There's no indirection (besides the interface, which would also be the
case with your approach) and you **should** use templated types :)


My point is that there's no need for IAllocator, even if you want to use
OOP so badly.
But in most cases you will either write different code for different
platforms, making interfaces unnecessary, or you would be able to hide
the differences behind a struct.

And when the allocator and the other policies are template parameters
you will know at CT that your code is @nogc.


Again, no templates. You cannot initialize them at runtime, and since
you won't know all implementations until it executes, well, you've got
a problem.
Its a many to many problem. I faced this with Cmsed as well.


As I demonstrated, it's not a problem. You just need to choose the
template at runtime. You have a fixed number of implementations which
are all statically linked. Only the one chosen at runtime will be
initialized and at the moment of initialization it can do the necessary
dynamic loading.

In the example above:


interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator,
Policy)(RunTimeArgs);


Since you don't need to switch Allocator implementations at run-time
(and if you switch them you will most certainly get silent memory
corruption), you can leverage the fact that some stuff are known at CT
and leave the rest to RT.


At this point, all I'm going to say is, prove me wrong.
Give me all the power I have now and do it the way you want to.

PR's welcome. https://github.com/rikkimax/alphaPhobos/

FYI, I'll be streaming in a minute https://www.livecoding.tv/alphaglosined/

Re: std.experimental.allocator and @nogc

[ZombineDev via Digitalmars-d]

On Monday, 9 May 2016 at 12:02:19 UTC, rikki cattermole wrote:

On 09/05/2016 11:56 PM, ZombineDev wrote:

On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:

On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole 
wrote:

I've done windowing and image libraries before.
You are correct, you do not need OOP.

But if you want to keep implementation nicely separated out 
from
usage, you really do. Which is a major part of my 
requirements.


Well, in my example above, everything is nicely separated, 
easy to use,
yet quite flexible. And still there is no Java-style OOP. Do 
you have
any examples, where the use of classic OOP would provide a 
strictly

superior design?


You're using templates. While this might be ok for image 
library.
I cannot use this for the windowing library. The 
implementation may

not be known and must be plugable at runtime.
The reality is, just because you say you know about something 
at

compile time doesn't mean the system that runs a program does.


I'm still not convinced. You have a fixed at CT number of
implementations. Even if you don't know at CT the actual 
platform that
will be used, you can still choose at RT the correct template. 
Example:


You do not.
Shared libraries remember them?


You will statically link the windowing library and it will 
dynamically load the necessary shared/dynamic libaries of the 
platform at runtime. What's the problem? E.g. Derelict* does the 
same.



// platform name can be "X11", "mir", "Wayland", etc.
auto getPlatformWindow(CTArgs...)(string platformNameRTArg)
{
switch (platformNameRTArg.toLower)
{
default:
 enforce(false, "Unknown platform: " ~ 
platformNameRTArg);


foreach (platform; EnumMembers!Platform)
case name.stringof:
 // Use std.experiment.typecons.Wrap if you 
need a

common type.
 return getWindow!(name, CTArgs);
}
assert (0);
}


Platform is undefined, did you mean IPlatform?


Platform obviously an enum. The return type can be a plain 
struct, a Variant, or a std.experimental.typecons.wrap, depending 
on your needs.


But that's besides the point. Even with OOP, your return type 
can be an
interface that has template parameters like allocators, 
policies, etc.
You're providing some the arguments at CT and the rest of the 
return

type is dynamically polymorphic. E.g.:

interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator, 
Policy)(RunTimeArgs);


Sure you can, but now you have added another layer of 
indirection between implementation and usage because you can't 
use templated types in between.


There's no indirection (besides the interface, which would also 
be the case with your approach) and you **should** use templated 
types :)


My point is that there's no need for IAllocator, even if you 
want to use

OOP so badly.
But in most cases you will either write different code for 
different
platforms, making interfaces unnecessary, or you would be able 
to hide

the differences behind a struct.

And when the allocator and the other policies are template 
parameters

you will know at CT that your code is @nogc.


Again, no templates. You cannot initialize them at runtime, and 
since you won't know all implementations until it executes, 
well, you've got a problem.

Its a many to many problem. I faced this with Cmsed as well.


As I demonstrated, it's not a problem. You just need to choose 
the template at runtime. You have a fixed number of 
implementations which are all statically linked. Only the one 
chosen at runtime will be initialized and at the moment of 
initialization it can do the necessary dynamic loading.


In the example above:


interface Window(Allocator, Policy);
Window!(Allocator, Policy) getWindow(alias allocator, 
Policy)(RunTimeArgs);


Since you don't need to switch Allocator implementations at 
run-time (and if you switch them you will most certainly get 
silent memory corruption), you can leverage the fact that some 
stuff are known at CT and leave the rest to RT.

Re: powExpressions work at ctfe

[Stefan Koch via Digitalmars-d]

On Monday, 9 May 2016 at 12:24:18 UTC, Timon Gehr wrote:

On 09.05.2016 11:24, Stefan Koch wrote:

At Dconf Manu asked to use pow expressions at CTFE.
Luckily he can.
powExpressions work at ctfe.


enum x=2.4^^4.5;

DMD master:

./../../phobos/std/math.d(4857): Error: cannot convert  to 
ushort* at compile time
./../../phobos/std/math.d(6113):called from here: 
isNaN(y)
./../../phobos/std/math.d(6303):called from here: 
impl(cast(real)x, cast(real)y)

ctfepow.d(1):called from here: pow(2.4, 4.5)


I see.
I did not test a floating point value at the left-hand site.
working on a fix.

Re: So, About That Official Blog...

[Seb via Digitalmars-d]

On Sunday, 8 May 2016 at 20:31:26 UTC, Nick Sabalausky wrote:
I would also recommend a static site generator, I currently 
use Hugo
https://gohugo.io/ though it is written it Go haha. Jekyll got 
really
slow after 30 blog entries, especially if you want to do the 
syntax

highlighting offline.


In short: Hybrid site generating :) Only generate on-the-fly 
what NEEDS to be on-the-fly. Only regenerate things when they 
change, not every time they're viewed (unless they change more 
than they're viewed, like maybe an admin-only site webstats 
page, but such cases are rare).


Guys - KISS! During the time we already spent in this thread, we 
could have written least five great blog entries!


Therefore +1 for static site generators - they keep stuff simple.
The advantage of Jekyll is that it works so nice with Github 
pages and everyone can thus preview the changes on their local 
gh-pages branch. Getting the Dlang theme is not difficult, see 
e.g. my proposal for to put the DIPs into a github repo:


https://github.com/wilzbach/d-dip
http://wilzbach.github.io/d-dip/DIP86

The DIP Jekyll site builds in ~five seconds (90 pages).
That being said, I like Hugo too.

Btw if we just keep using DDOC (a static site generator), all the 
custom macros will continue to work ;-)

Re: Always false float comparisons

[Walter Bright via Digitalmars-d]

On 5/9/2016 5:21 AM, Ethan Watson wrote:

I'd assume in the first case that the float is being promoted to double for the
comparison. Is there already a warning for loss of precision?


Promoting to double does not lose precision.


We treat warnings
as errors in our C++ code, so C4244 triggers all the time in MSVC with integer
operations. I just tested that float initialisation in MSVC, initialising a
float with a double triggers C4305.


That's going quite a bit further.