Re: Is the following well defined and allowed?

[Nathan S. via Digitalmars-d]

On Thursday, 1 March 2018 at 21:01:08 UTC, Steven Schveighoffer 
wrote:

Yeah, it seems like -noboundscheck should never be used.


How good is DMD at omitting redundant bounds checks? I assume not 
much engineering effort has been put towards that due to 
"-boundscheck=off" being available.

Re: Opt-in non-null class references?

[Jacob Carlborg via Digitalmars-d]

On Wednesday, 28 February 2018 at 23:58:44 UTC, Jonathan M Davis 
wrote:
he's stated that dmd's optimizer uses code-flow analysis for 
some stuff, but for anything that involves putting it in the 
frontend where the behavior would have to be encoded in the 
spec, he's been against it.


The compiler can actually detect simple cases of null 
dereferences if optimizations are turned on, "-O", due to the 
optimizer using flow analysis.


--
/Jacob Carlborg

Re: I have a patch to let lldb demangle D symbols ; help welcome to improve it

[Jacob Carlborg via Digitalmars-d]

On Tuesday, 27 February 2018 at 05:28:41 UTC, Timothee Cour wrote:

https://github.com/llvm-mirror/lldb/pull/3
+
https://github.com/timotheecour/dtools/blob/master/dtools/lldbdplugin.d


on OSX, it works great except when encountering large symbols 
which

cause segfault when GC does a collection (triggered inside
core.demangle.demangle);
Help is welcome to improve that (or more generally to improve D
support in lldb, which I started in
https://github.com/llvm-mirror/lldb/pull/3)
NOTE: lldb doesn't accept github PR's but easier to work with 
PR's for

whoever wants to help on tha in the meantime


This is great work.

Keep in mind that DMD does not support dynamic libraries on macOS.

--
/Jacob Carlborg

Re: Thinktank: CI's, compiler lists, and project automation

[Jacob Carlborg via Digitalmars-d]

On Friday, 2 March 2018 at 06:07:25 UTC, Nick Sabalausky 
(Abscissa) wrote:
(I'm posting this here instead of D.learn because it isn't 
really a "How to do XYZ in D?", but rather to invite discussion 
on high-level solutions to a problem.)


Here's a common problem:

1. A project (ex, some library) uses travis-ci (and/or other) 
to ensure compatibility with a range of compiler versions. The 
travis configuration file includes a manually-curated list of 
compiler versions.


2. CI tests are triggered by new commits/merges/PRs in the 
project.


3. New compiler versions are released.

4. Compiler updates may or may not trigger new tests with the 
new compiler, depending on the project.


5. Project maintainer must manually update the list of 
compilers. (And this isn't one task, but rather O(n), where 
n=number of projects the given person is maintaining).


The challenge: What is the best way to automate this? (ie, #4 
and #5)


Travis CI allows you to specify a D compiler in the following 
ways:


*  - the latest version of the specified compiler
* -beta - the latest beta
* -nightly - the nightly build
* - - a specific version of the compiler

Where  is "dmd", "ldc" or "gdc".

Combine the above with a scheduled build that builds once every 
day you're pretty well covered. For an example, see the Travis CI 
configuration for DStep [1]. I'm building the latest version of 
DMD and LDC on Linux and macOS, but the betas and nightly are 
only built on Linux, due the the limited resources of macOS 
builds on Travis CI.


[1] 
https://github.com/jacob-carlborg/dstep/blob/master/.travis.yml


--
/Jacob Carlborg

[Issue 11601] pragma(msg, ...) output not silenced inside is(typeof()) and __traits(compiles, ...)

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #2 from Simen Kjaeraas  ---
I was apparently a bit hasty in closing this. Encountered the same issue again
today, and testing the code in comment #0 again shows that its behavior has not
been fixed in 2.078.3.

--

Re: Spawning a process: Can I "have my cake and eat it too"?

[Vladimir Panteleev via Digitalmars-d-learn]

On Friday, 2 March 2018 at 04:50:06 UTC, Nick Sabalausky 
(Abscissa) wrote:
Launch a process (spawnProcess, pipeShell, etc) so the child's 
stdout/stderr go to the parent's stdout/stderr *without* the 
possibility of them getting inadvertently 
reordered/reinterleaved when viewed on the terminal, *and* 
still allow the parent to read the child's stdout and stderr?


I think it's possible on Linux.
1. Disable buffering on the pipe (see stdbuf etc.)
2. Fake output type to fool isatty (e.g. script -c 'child_program 
args...' /dev/null)

Thinktank: CI's, compiler lists, and project automation

[Nick Sabalausky (Abscissa) via Digitalmars-d]

(I'm posting this here instead of D.learn because it isn't really a "How 
to do XYZ in D?", but rather to invite discussion on high-level 
solutions to a problem.)


Here's a common problem:

1. A project (ex, some library) uses travis-ci (and/or other) to ensure 
compatibility with a range of compiler versions. The travis 
configuration file includes a manually-curated list of compiler versions.


2. CI tests are triggered by new commits/merges/PRs in the project.

3. New compiler versions are released.

4. Compiler updates may or may not trigger new tests with the new 
compiler, depending on the project.


5. Project maintainer must manually update the list of compilers. (And 
this isn't one task, but rather O(n), where n=number of projects the 
given person is maintaining).


The challenge: What is the best way to automate this? (ie, #4 and #5)

We do already have certain approaches to at least certain facets of the 
problem (ex: some third party libs are included in DMD's CI testing), 
but there are still limitations and downsides (ex: D tester has limited 
resources, and it doesn't address manually updating the travis config's 
list of compilers or notifying authors their project's compiler list 
needs updated.)


Another sample point of discussion: One possible approach is to have a 
bot generate PRs to update project's compiler lists. But that leads to 
other questions: How/when is the bot triggered? On what machine does it 
run? Is there an existing jumping-off point for creating such a bot? How 
does it approach the task of modifying `.travis.yml` (how smart/dumb 
does it need to be)? Any security concerns to be mindful of? Etc.

Re: State of D 2018 Survey

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

On Friday, 2 March 2018 at 02:35:46 UTC, Meta wrote:
D1 -> D2 nearly killed D (can't remember which, but it was 
either Walter or Andrei that have said this on multiple 
occasions).


This gets repeated over and over again, but I haven't actually 
seen any evidence for it.


But even if it is true, I'd say it is just because they did it 
wrong. There never really was a D1->D2. There was just an ongoing 
evolution of D where one version was arbitrarily forked off and 
called D1. Seriously, D1.00 and D 2.00 came out at about the same 
time: Version D 1.001 Jan 23, 2007; 2.000 Jun 17, 2007.


I remember the biggest troubles I had with D2: immutable being 
introduced and changing, and a bunch of little library 
renames and they weren't really that big of a deal and btw 
occurred over the next ~2ish *years*. It wasn't all at once - 
remember "D2" was just the evolving D. D1 was a random, arbitrary 
snapshot.


If I were to do a D3, I'd make it opt in at the module level, and 
keep it so all D code can be compiled together - corresponding 
features added each step. For example, a "d3 module" is @safe by 
default. But the @safe semantics are still tehre for a "d2 
module", you just annotate it elsewhere. Then there's no breakage 
and you can still change things.

Re: Documentation for any* dub package, any version

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

If you guys have bug reports or feature requests, you can put it 
on the github too if you like:


https://github.com/adamdruppe/dpldocs/issues

Re: Spawning a process: Can I "have my cake and eat it too"?

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

I would suggest redirecting the child to the parent pipe, but 
then having the parent write the data back out to its own 
stdout/err.


It'd be a bit tricky with just Phobos' file though because it 
doesn't make it easy to wait for or be notified about input on 
it, but the underlying OS apis make this reasonably simple 
(WaitForMultipleObjects or select) if you're willing to write a 
bit more code to do it yourself or at least pull the underlying 
handles out of the Phobos file.

Spawning a process: Can I "have my cake and eat it too"?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

I'd like to include this functionality in Scriptlike, but I don't know 
if it's even possible:


Launch a process (spawnProcess, pipeShell, etc) so the child's 
stdout/stderr go to the parent's stdout/stderr *without* the possibility 
of them getting inadvertently reordered/reinterleaved when viewed on the 
terminal, *and* still allow the parent to read the child's stdout and 
stderr?


How could this be accomplished? Is it even possible?

Re: State of D 2018 Survey

[psychoticRabbit via Digitalmars-d-announce]

On Friday, 2 March 2018 at 03:57:25 UTC, barry.harris wrote:


Sorry little rabbit, your are misguided in this belief. Back in 
day we all used C and this is the reason most "safer" languages 
exist today.


You can write pretty safe code in C these days, without too much 
trouble. We have the tooling and the knowledge to make that 
happen.. developed over decades - and both keep getting better, 
because the language is not subjected to a constant and frequent 
release cycle.


Ironically, the demands on programmers to adapt to constant 
change, is actually making applications less safe. - and least, 
that's my thesis ;-)


The real problem with using C these days (in some areas), is more 
to do with its limited abstraction power, not its lack of safety.


And also C is frowned upon (and C++ too for that matter), cause 
most programmers are so lazy these days, and don't want to write 
code - but prefer to just 'link algorithms' that someone else 
wrote.


I include myself in this - hence my interest in D ;-)

Keep those algorithms coming!

Re: State of D 2018 Survey

[psychoticRabbit via Digitalmars-d-announce]

On Friday, 2 March 2018 at 02:35:46 UTC, Meta wrote:


D1 -> D2 nearly killed D (can't remember which, but it was 
either Walter or Andrei that have said this on multiple 
occasions). A D2 -> D3 transition might generate a lot of 
publicity if done very carefully, but more than likely it would 
just put the nails in the coffin for good and destroy all the 
momentum D has built up over the past 3 years (I feel like 2015 
was a big turning point where D finally got back on peoples' 
radars).


I've read a bit about that history, but really, sometimes you 
have to be agressive with change or just it won't come about.


And I don't see how D2 could have come about without an agressive 
push for change.


And it's unlikely that D would have died. Some people might have 
left (and probably did). But D is better because it's D2.


Imagine promoting D1 to the world!

D3 could be even better. (e.g. @safe by default..just for 
starters).


And I personally think all this ongoing integration with C and 
C++ is not ideal. It's creating a really complex beast, that has 
to be maintained indefinitely... by someone.


So I'd like to see D3 dump all the compatibility crap ;-)

Re: State of D 2018 Survey

[barry.harris via Digitalmars-d-announce]

On Friday, 2 March 2018 at 02:34:23 UTC, psychoticRabbit wrote:

On Friday, 2 March 2018 at 02:02:42 UTC, psychoticRabbit wrote:


btw. I never said 'stop changing', I said "I wish programming 
languages would just stop changing so often."




I'd also argue, that languages that are relatively stable, are 
far 'safer' than languages that constantly change.


So given that the world is so focused on developing  a variety 
of so called 'safer' languages, with ever rapid, frequent, 
release cycles, the world would actually be alot 'safer' if 
everyone went back and programmed in C ;-)


Sorry little rabbit, your are misguided in this belief. Back in 
day we all used C and this is the reason most "safer" languages 
exist today.

[Issue 18546] Improvement: Implicit Class Template Instantiation

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

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from Jonathan M Davis  ---
The normal solution is to use a factory function which can then take advantage
of IFTI. As it stands, the compiler never does any implicit template
instantations except for functions, because for templates that aren't function
templates, it's ambiguous. This particular case is a bit special in that it's
using the type, not a function, but it's also triggering the constructor, which
_is_ a function. So, I don't know. Really, what it comes down to is that some
specific cases of implicitly instantiating templated types could be made to
work, but it can't work in the general case. So, thus far, the solution has
been to simply not support it.

Related: issue #1012.

--

Re: State of D 2018 Survey

[Meta via Digitalmars-d-announce]

On Friday, 2 March 2018 at 00:39:08 UTC, psychoticRabbit wrote:
On Thursday, 1 March 2018 at 21:49:31 UTC, Jonathan M Davis 
wrote:


That being said, I think that it's a given that we need to 
make breaking changes at least occasionally. The question is 
more how big they can be and how we go about it. Some changes 
would clearly be far too large to be worth it, whereas others 
clearly pay for themselves. The harder question is the stuff 
in between.


...
- Jonathan M Davis


Personally. I think the D1..D2 transistion was great idea.

I think D2..D3 should follow the same principle.


D1 -> D2 nearly killed D (can't remember which, but it was either 
Walter or Andrei that have said this on multiple occasions). A D2 
-> D3 transition might generate a lot of publicity if done very 
carefully, but more than likely it would just put the nails in 
the coffin for good and destroy all the momentum D has built up 
over the past 3 years (I feel like 2015 was a big turning point 
where D finally got back on peoples' radars).

Re: State of D 2018 Survey

[psychoticRabbit via Digitalmars-d-announce]

On Friday, 2 March 2018 at 02:02:42 UTC, psychoticRabbit wrote:


btw. I never said 'stop changing', I said "I wish programming 
languages would just stop changing so often."




I'd also argue, that languages that are relatively stable, are 
far 'safer' than languages that constantly change.


So given that the world is so focused on developing  a variety of 
so called 'safer' languages, with ever rapid, frequent, release 
cycles, the world would actually be alot 'safer' if everyone went 
back and programmed in C ;-)

Re: State of D 2018 Survey

[psychoticRabbit via Digitalmars-d-announce]

On Friday, 2 March 2018 at 01:19:53 UTC, H. S. Teoh wrote:


Because it has not stopped changing.  To wit:

K C (1978)
C89 / C90 / ANSI C (1989-1990)
The 1995 amendment to ANSI C (1995)
C99 (1999)
(Embedded C (2008))
C11 (2011)


T


btw. I never said 'stop changing', I said "I wish programming 
languages would just stop changing so often."


And that last update to C, in 2011, was 7 years ago..

relative stability is a sure sign that something is right.

constant, regular, change is a sure sign that something is wrong.

And if stability were not the preferred state towards which 
things evolve, then the universe would be a very different place 
indeed.

Re: State of D 2018 Survey

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

On Fri, Mar 02, 2018 at 12:57:22AM +, psychoticRabbit via 
Digitalmars-d-announce wrote:
> On Friday, 2 March 2018 at 00:53:02 UTC, H. S. Teoh wrote:
> > On Fri, Mar 02, 2018 at 12:39:08AM +, psychoticRabbit via
> > Digitalmars-d-announce wrote: [...]
> > > On the otherhand, I wish programming languages would just stop
> > > changing so often.
> > [...]
> > 
> > Change is inevitable, except from a vending machine. :-P
> > 
> > The day a language stops changing is the day it begins to die.
[...]
> C will never die
[...]

Because it has not stopped changing.  To wit:

K C (1978)
C89 / C90 / ANSI C (1989-1990)
The 1995 amendment to ANSI C (1995)
C99 (1999)
(Embedded C (2008))
C11 (2011)


T

-- 
"If you're arguing, you're losing." -- Mike Thomas

Re: State of D 2018 Survey

[psychoticRabbit via Digitalmars-d-announce]

On Friday, 2 March 2018 at 00:53:02 UTC, H. S. Teoh wrote:
On Fri, Mar 02, 2018 at 12:39:08AM +, psychoticRabbit via 
Digitalmars-d-announce wrote: [...]
On the otherhand, I wish programming languages would just stop 
changing so often.

[...]

Change is inevitable, except from a vending machine. :-P

The day a language stops changing is the day it begins to die.


T


C will never die

!!

[Issue 18546] New: Improvement: Implicit Class Template Instantiation

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

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

  Issue ID: 18546
   Summary: Improvement: Implicit Class Template Instantiation
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: default_357-l...@yahoo.de

Why does this not work? Should  this work?

class Foo(T) {
this(T t) { }
}

auto foo = new Foo(5);

C++ can do it...

--

Re: State of D 2018 Survey

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

On Fri, Mar 02, 2018 at 12:39:08AM +, psychoticRabbit via 
Digitalmars-d-announce wrote:
[...]
> On the otherhand, I wish programming languages would just stop
> changing so often.
[...]

Change is inevitable, except from a vending machine. :-P

The day a language stops changing is the day it begins to die.


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't deserve what 
you have now either.

Re: State of D 2018 Survey

[psychoticRabbit via Digitalmars-d-announce]

On Thursday, 1 March 2018 at 21:49:31 UTC, Jonathan M Davis wrote:


That being said, I think that it's a given that we need to make 
breaking changes at least occasionally. The question is more 
how big they can be and how we go about it. Some changes would 
clearly be far too large to be worth it, whereas others clearly 
pay for themselves. The harder question is the stuff in between.


...
- Jonathan M Davis


Personally. I think the D1..D2 transistion was great idea.

I think D2..D3 should follow the same principle.

i.e restrict breaking changes to major versions.

People are always able to stay on the major branch that they need 
- there are no forced upgrades here - you choose which major 
branch works for you. The source code is all there for you, to do 
as you please.


This is the only way to evolve - otherwise D will just become 
another convoluted piece of %3@f!, like C++.


On the otherhand, I wish programming languages would just stop 
changing so often.


The constant release cycles is just crazy! That's a sure sign 
that something is not right. And who wants to program in a 
langauge that is not right??


That's why I still like, still use, and typically still prefer .. 
C.


Nobody dares change it ;-)

Re: Assigning to slice of array

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, March 01, 2018 23:51:37 Jamie via Digitalmars-d-learn wrote:
> On a similar not, is there an accepted way to assign across
> arrays? As Steve mentioned, cross-slicing isn't supported, so is
> the best way to iterate through the array and assign as necessary?

That's what you would have to do. You're basically dealing with stuff like
int*** except that it also has its length with it and wraps it in a nicer
way, and so each of these buffers that you're dealing with are essentially
unrelated. They just have a common root. Even if there were some sort of
high level operation that did something along the lines of what you're
looking for, it would pretty much have to lower to something along the lines
of what you'd be doing to solve the problem on your own. It's not like these
are these are buffers which are somehow squares or cubes in memory such that
they you could slice along a different dimension. They're still just linear
buffers of memory.

- Jonathan M Davis

Re: I have a patch to let lldb demangle D symbols ; help welcome to improve it

[Timothee Cour via Digitalmars-d]

yes, I've fixed the issue with crashes on large symbols using a
patched `demangle` ; will update code soon; but feel free to take a
look at lldb side of things




On Thu, Mar 1, 2018 at 12:23 PM, Luís Marques via Digitalmars-d
 wrote:
> On Tuesday, 27 February 2018 at 11:23:02 UTC, timotheecour wrote:
>>
>> On Tuesday, 27 February 2018 at 05:28:41 UTC, Timothee Cour wrote:
>>>
>>> https://github.com/llvm-mirror/lldb/pull/3
>>> +
>>> https://github.com/timotheecour/dtools/blob/master/dtools/lldbdplugin.d
>>>
>>>
>>> on OSX, it works great except when encountering large symbols which
>>> cause segfault when GC does a collection (triggered inside
>>> core.demangle.demangle);
>>> Help is welcome to improve that (or more generally to improve D
>>> support in lldb, which I started in
>>> https://github.com/llvm-mirror/lldb/pull/3)
>>> NOTE: lldb doesn't accept github PR's but easier to work with PR's for
>>> whoever wants to help on tha in the meantime
>>
>>
>> Specifically, the issue I'm facing is:
>> https://github.com/timotheecour/dtools/issues/2 (a crash occurs when
>> _d_arraysetlengthiT is called)
>>
>> any help would be greatly appreciated
>
>
> Thanks for working on this. I'll try to look into this in the next few days.
> (If you have further progress on this please provide an update here).

Re: Documentation for any* dub package, any version

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

On Thursday, 1 March 2018 at 11:00:15 UTC, Jonas Drewsen wrote:
Would be cool if you could add support for creating docs from 
any dub project stored on github and not only the ones on 
code.dlang.org.


That might be possible too.


BTW I just put the server code up on github
https://github.com/adamdruppe/dpldocs


there's actually not that much to it right now.

Re: Assigning to slice of array

[Jamie via Digitalmars-d-learn]

On Thursday, 1 March 2018 at 23:17:11 UTC, Jonathan M Davis wrote:

So, something like

auto arr = new int[][][](3, 2, 1);
arr.length = 4;
arr[0].length = 5;
arr[0][0].length = 6;

is legal, but something like


Thanks Jonathan, this is exactly what I was looking for. I was 
getting confused with not being able to resize because I was 
looking at int[] arrays and I guess the way I was defining them 
caused them both to be dynamic (when I thought one was static).


On a similar not, is there an accepted way to assign across 
arrays? As Steve mentioned, cross-slicing isn't supported, so is 
the best way to iterate through the array and assign as necessary?

Thanks, Jamie

Re: Assigning to slice of array

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, March 01, 2018 22:57:16 Jamie via Digitalmars-d-learn wrote:
> On Thursday, 1 March 2018 at 21:34:41 UTC, Jonathan M Davis wrote:
> > Don't put the indices within the brackets. What you want is
> >
> > auto arr = new int[][][](3, 2, 1);
>
> Okay thanks, but I don't understand what is the issue with having
> static arrays there instead? My functionality didn't change when
> I replaced the single line with your line?
>
> And I couldn't resize either of them with array.length, which is
> also something I would like.
> Thanks

static arrays have a fixed size, so you can't resize them with any operation
- including setting their length. Static arrays are value types, so when
they're copied, the whole thing is copied, whereas with a dynamic array is
just a pointer and a length, so copying it just slices the dynamic array to
give you another dynamic array. It's just copying the pointer and the
length. A dynamic array is effectively

struct DynamicArray(T)
{
size_t length;
T* ptr;
}

whereas a static array is an actual buffer that sits wherever it's declared
(on the stack if it's a local variable).

So, something like

auto arr = new int[][][](3, 2, 1);
arr.length = 4;
arr[0].length = 5;
arr[0][0].length = 6;

is legal, but something like

auto arr = new int[3][2][1];
arr.length = 4; // this one is still legal, since it's a dynamic array
arr[0].length = 5;
arr[0][0].length = 6;

is not legal.

- Jonathan M Davis

Re: Assigning to slice of array

[Jamie via Digitalmars-d-learn]

On Thursday, 1 March 2018 at 21:34:41 UTC, Jonathan M Davis wrote:

Don't put the indices within the brackets. What you want is

auto arr = new int[][][](3, 2, 1);


Okay thanks, but I don't understand what is the issue with having 
static arrays there instead? My functionality didn't change when 
I replaced the single line with your line?


And I couldn't resize either of them with array.length, which is 
also something I would like.

Thanks

Re: Assigning to slice of array

[ag0aep6g via Digitalmars-d-learn]

On 03/01/2018 11:43 PM, Jamie wrote:

So if I do
     arr[0 .. 1][0] = 3;
shouldn't this return
     [[3, 0, 0], [0, 0, 0]] ? Because I'm taking the slice arr[0 .. 1], 
or arr[0], which is the first [0, 0, 0]?


arr[0 .. 1] is not the same as arr[0].

arr[0 .. 1] is not the first element of arr; it's an array that contains 
the first element of arr. It's not [0, 0, 0]; it's [[0, 0, 0]]. It's not 
an int[]; it's an int[][].


Then assigning the first 
element to 3?

instead it returns
     [[3, 3, 3], [0, 0, 0]]


Since arr[0 .. 1] is [[0, 0, 0]], arr[0 .. 1][0] is [0, 0, 0]. Assigning 
3 to that means assigning to all of its values. And so you get [3, 3, 3].

Re: How to stringify a template instantiation expression?

[aliak via Digitalmars-d]

On Thursday, 1 March 2018 at 16:46:30 UTC, Yuxuan Shui wrote:

Did you actually try that? With dmd 2.079-rc1, this:

template A(T...) {}
struct B {}
struct D {}
struct E {}
template C(T...) {}
pragma(msg, (A!(B, C!(D, E))).stringof);

Prints:

A!(B, __T1CTS2ax1DTSQh1EZ)

When compiled


Yep, though not all possible combinations of course:

struct X(T...) {}

void main() {
writeln(X!(int, X!(X!(int), float), char).stringof);
}

Seems like if you throw in template templates then things get a 
little more ... complicated.

Re: Assigning to slice of array

[Jamie via Digitalmars-d-learn]

On Thursday, 1 March 2018 at 21:31:49 UTC, Steven Schveighoffer 
wrote:
No, I think you did int[3][2], if you got that output. 
Otherwise it would have been:


[[[0,0,0],[0,0,0]]]


Yes apologies that was there from a previous attempt, you are 
correct.


Well, that's because that type of slicing isn't supported 
directly. You can't slice an array cross-wise like that.


You may be interested in ndslice inside mir: 
http://docs.algorithm.dlang.io/latest/mir_ndslice.html


Thanks I've just had a quick read and this looks promising for 
what I want (similar functionality to numpy), but I also want to 
understand arrays.



when I try
     arr[0 .. 2][0] = 3;   // which I think is equivalent to 
arr[0][0]


Consider the array:

int[] x = new int[2];

Now, what would the slice x[0 .. 2] be? That's right, the same 
as x.


So when you slice arr[0 .. 2], it's basically the same as arr 
(as arr has 2 elements).


So arr[0 .. 2][0] is equivalent to arr[0].


So if I do
arr[0 .. 1][0] = 3;
shouldn't this return
[[3, 0, 0], [0, 0, 0]] ? Because I'm taking the slice arr[0 
.. 1], or arr[0], which is the first [0, 0, 0]? Then assigning 
the first element to 3?

instead it returns
[[3, 3, 3], [0, 0, 0]]

One thing that is interesting is that you assigned 3 to an 
array, and it wrote it to all the elements. I did not know you 
could do that with static arrays without doing a proper slice 
assign. But it does compile (I learn something new every day).


-Steve

Well I'm learning a lot today :)

Re: Opt-in non-null class references?

[aliak via Digitalmars-d]

On Thursday, 1 March 2018 at 19:10:29 UTC, Jonathan M Davis wrote:
DIP 1000 operates based on the type. As I understand it, it 
looks at the fact that something is scope or not and then 
determines whether a particular operation is valid or not based 
on whether the operation could result in a reference to the 
data escaping. An operation is then valid or not regardless of 
what other lines in the code are doing. As such, if I 
understand correctly, code-flow analysis isn't really 
necessary, just like code-flow analysis isn't necessary to 
determine what's valid or not when const is involved.


- Jonathan M Davis


Ah right, makes sense yep. Thanky!

Re: Is the following well defined and allowed?

[ag0aep6g via Digitalmars-d]

On Thursday, 1 March 2018 at 21:01:08 UTC, Steven Schveighoffer 
wrote:

Yeah, it seems like -noboundscheck should never be used.


Agreed.

It's undefined behavior if the check is disabled. How you get 
the check disabled may be affected by @safe, but whether it's 
UB or not has nothing to do with @safe. It has to do with "I 
turned off the checks". Basically, in D, if your program *would 
have* thrown an Error, but didn't because you turned it off, 
the compiler is free to assume UB.


You're looking at the behavior of the compiled executable. Then 
it makes sense to say that a program compiled with the checks has 
defined behavior (throwing Errors) and a program without the 
checks does something undefined (because the compiler manual 
doesn't say that anything in particular is supposed to happen).


That's not how I understand/use "undefined behavior". To me, it's 
the D source code that can have "undefined behavior". When it 
does, the program (as given in source code) is invalid and the 
compiler can do whatever it wants with it. It may:


1) reject the program statically, or it may
2) generate code that throws an Error at run time, or it may
3) generate code that does something arbitrary.

With that meaning of UB, out-of-bounds accesses and overlapping 
copies have undefined behavior in @system code, but they have 
defined behavior in @safe code.


For @system code, DMD chooses option #2 or option #3 depending on 
whether you give -release or not. DMD is free to do this, because 
the source code has UB.


For @safe code, DMD goes with option #2 either way, because the 
spec demands it.


If it were capable, DMD could also go with option #1 for both 
@system and @safe code. The spec allows/encourages that.


In this interpetation, -noboundscheck switches DMD to a different 
dialect of D. In that dialect, out-of-bounds accesses (and 
overlapping copies, apparently) always have UB, in both @system 
and @safe code. That defeats the purpose of @safe. Which is why I 
don't really care for that dialect.

Re: State of D 2018 Survey

[Jonathan M Davis via Digitalmars-d-announce]

On Thursday, March 01, 2018 13:24:29 Bill Baxter via Digitalmars-d-announce 
wrote:
> Just don't overlook the fact that people who fill out 30 minute surveys
> right away after being told about them are a self-selected group of people
> who apparently have way too much time on their hands.
> Which also suggests they would likely also have more free time to go chase
> down and fix breaks in their legacy code caused by new compilers.

It's also the case that the folks who even see this survey are likely to be
a fairly small percentage of the actual user base. So, while its results may
be useful, they need to be viewed with that fact in mind.

That being said, I think that it's a given that we need to make breaking
changes at least occasionally. The question is more how big they can be and
how we go about it. Some changes would clearly be far too large to be worth
it, whereas others clearly pay for themselves. The harder question is the
stuff in between.

For instance, while we might not actually have a new operator if D were
being redesigned from the ground up (Andrei has previously stated that it
really should have just been a function in the standard library or runtime),
that would be far too large a change with far too little benefit to be even
vaguely worth it at this point. On the other hand, we _did_ change it so
that switch statements don't have implicit fallthrough anymore, and that
change was _very_ well received, because it caught bugs and it was a quick
fix to update correct code that was then an error (it was probably also true
that relatively little correct code had to be updated, but that's harder to
measure).

Each potential breaking change has to be weighed on its own, and the real
question is how strongly we weight the pros vs the cons. We could choose to
favor breaking code only when it's cleary _very_ benificial to do so, or we
could choose to break code any time there's even a slight benefit to it. I
think that it's pretty clear that the right choice is somewhere in between
those two extremes, but it's not an easy question as to where it is.

And as has been discussed before, we have folks clamoring for breaking
changes and folks clamoring for nothing to ever break, and sometimes,
they're exactly the same folks. :|

- Jonathan M Davis

Re: State of D 2018 Survey

[Daniel Kozak via Digitalmars-d-announce]

Ok, I have same feeling, but after trying to fill this survey with one of
my colleague, I have find out that it takes "only" 15 minutes to complete.
But still I thing almost everyone from our field is OK with filling surveys
anyway.

On Thu, Mar 1, 2018 at 10:24 PM, Bill Baxter via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> Just don't overlook the fact that people who fill out 30 minute surveys
> right away after being told about them are a self-selected group of people
> who apparently have way too much time on their hands.
> Which also suggests they would likely also have more free time to go chase
> down and fix breaks in their legacy code caused by new compilers.
>
> --bb
>
>
> On Thu, Mar 1, 2018 at 1:19 PM, bauss via Digitalmars-d-announce <
> digitalmars-d-announce@puremagic.com> wrote:
>
>> On Wednesday, 28 February 2018 at 20:37:36 UTC, Seb wrote:
>>
>>> On Wednesday, 28 February 2018 at 20:24:00 UTC, JN wrote:
>>>
 On Wednesday, 28 February 2018 at 20:01:16 UTC, Seb wrote:

> Thanks! I hope so too!
>

 Is there some way to access the results without retaking the survey?

>>>
>>> Yeah the link TypeForm generates at the end is permanent:
>>>
>>> https://dlang.typeform.com/report/H1GTak/PY9NhHkcBFG0t6ig
>>>
>>> though for some reason it doesn't show full-text answers (I have opened
>>> a support ticket for that a while ago).
>>> Anyhow, as Mike said we will look at all answers and do a summary once
>>> the survey concluded.
>>>
>>
>> Interesting results. 80% in favor for breaking changes.
>>
>> Maybe it's time to not care too much about making D better and leave old
>> legacy stuff that stops D from evolving behind curtains.
>>
>
>

Re: State of D 2018 Survey

[bachmeier via Digitalmars-d-announce]

On Thursday, 1 March 2018 at 21:24:29 UTC, Bill Baxter wrote:
Just don't overlook the fact that people who fill out 30 minute 
surveys
right away after being told about them are a self-selected 
group of people

who apparently have way too much time on their hands.
Which also suggests they would likely also have more free time 
to go chase
down and fix breaks in their legacy code caused by new 
compilers.


--bb


Nothing makes the old compilers disappear. If you have working 
code, keep using the compiler that compiled it. New features or 
breaking changes. Otherwise D will stop evolving, and unlike C++, 
will not have tons of legacy code to force people to continue to 
use it.

Re: Assigning to slice of array

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/1/18 4:16 PM, Jamie wrote:
I'm trying to understand arrays and have read a lot of the information 
about them on this forum. I think I understand that they are set-up like 
Type[], so that int[][] actually means an array of int[].


I create an array as per the following:
     auto arr = new int[3][2][1];
which produces:
     [[0, 0, 0], [0, 0, 0]]


No, I think you did int[3][2], if you got that output. Otherwise it 
would have been:


[[[0,0,0],[0,0,0]]]

Looking at the rest of your code, I think it wouldn't work if you had 
done the line above.


(for each of the following assignments, assume that the array is set 
back to zeros)


and I can change the 2nd element of the 1st array using:
     arr[0][1] = 4;
which produces:
     [[0, 4, 0], [0, 0, 0]]

and I can change the entire 1st array using:
     arr[0][0 .. 3] = 5;
which produces:
     [[5, 5, 5], [0, 0, 0,]]


Yes, all correct.



however when I try and change elements across arrays rather than within 
arrays my understanding breaks down..


Well, that's because that type of slicing isn't supported directly. You 
can't slice an array cross-wise like that.


You may be interested in ndslice inside mir: 
http://docs.algorithm.dlang.io/latest/mir_ndslice.html



when I try
     arr[0 .. 2][0] = 3;   // which I think is equivalent to arr[0][0] 


Consider the array:

int[] x = new int[2];

Now, what would the slice x[0 .. 2] be? That's right, the same as x.

So when you slice arr[0 .. 2], it's basically the same as arr (as arr 
has 2 elements).


So arr[0 .. 2][0] is equivalent to arr[0].

One thing that is interesting is that you assigned 3 to an array, and it 
wrote it to all the elements. I did not know you could do that with 
static arrays without doing a proper slice assign. But it does compile 
(I learn something new every day).


-Steve

Re: Assigning to slice of array

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, March 01, 2018 21:16:54 Jamie via Digitalmars-d-learn wrote:
> I'm trying to understand arrays and have read a lot of the
> information about them on this forum. I think I understand that
> they are set-up like Type[], so that int[][] actually means an
> array of int[].
>
> I create an array as per the following:
>  auto arr = new int[3][2][1];
> which produces:

Don't put the indices within the brackets. What you want is

auto arr = new int[][][](3, 2, 1);

With a new expression, unless you only have one dimension, you end up with
dynamic arrays of static arrays. e.g. if you use what I wrote there with

pragma(msg, typeof(arr).stringof);

it prints

int[][][]

whereas with what you wrote, you get

int[3][2][]

which is a dynamic array of a static array of length 2 of static arrays of
int of length 3 rather than a dynamic array of a dynamic array of a dynamic
array of ints. Unfortunately,

auto arr = new int[5];

and

auto arr = new int[](5);

are equivalent, so dealing with just single dimension arrays does not
prepare you properly for dealing with multi-dimensional arrays. Arguably, it
would have been better to just force using the parens, though that would
make the most common case more verbose, so it's debatable.

- Jonathan M Davis

Re: State of D 2018 Survey

[Bill Baxter via Digitalmars-d-announce]

Just don't overlook the fact that people who fill out 30 minute surveys
right away after being told about them are a self-selected group of people
who apparently have way too much time on their hands.
Which also suggests they would likely also have more free time to go chase
down and fix breaks in their legacy code caused by new compilers.

--bb


On Thu, Mar 1, 2018 at 1:19 PM, bauss via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 28 February 2018 at 20:37:36 UTC, Seb wrote:
>
>> On Wednesday, 28 February 2018 at 20:24:00 UTC, JN wrote:
>>
>>> On Wednesday, 28 February 2018 at 20:01:16 UTC, Seb wrote:
>>>
 Thanks! I hope so too!

>>>
>>> Is there some way to access the results without retaking the survey?
>>>
>>
>> Yeah the link TypeForm generates at the end is permanent:
>>
>> https://dlang.typeform.com/report/H1GTak/PY9NhHkcBFG0t6ig
>>
>> though for some reason it doesn't show full-text answers (I have opened a
>> support ticket for that a while ago).
>> Anyhow, as Mike said we will look at all answers and do a summary once
>> the survey concluded.
>>
>
> Interesting results. 80% in favor for breaking changes.
>
> Maybe it's time to not care too much about making D better and leave old
> legacy stuff that stops D from evolving behind curtains.
>

Assigning to slice of array

[Jamie via Digitalmars-d-learn]

I'm trying to understand arrays and have read a lot of the 
information about them on this forum. I think I understand that 
they are set-up like Type[], so that int[][] actually means an 
array of int[].


I create an array as per the following:
auto arr = new int[3][2][1];
which produces:
[[0, 0, 0], [0, 0, 0]]
(for each of the following assignments, assume that the array is 
set back to zeros)


and I can change the 2nd element of the 1st array using:
arr[0][1] = 4;
which produces:
[[0, 4, 0], [0, 0, 0]]

and I can change the entire 1st array using:
arr[0][0 .. 3] = 5;
which produces:
[[5, 5, 5], [0, 0, 0,]]

however when I try and change elements across arrays rather than 
within arrays my understanding breaks down.. when I try
arr[0 .. 2][0] = 3;   // which I think is equivalent to 
arr[0][0] and arr[1][0]

I'm expecting:
[[3, 0, 0], [3, 0, 0]]
but it produces:
[[3, 3, 3], [0, 0, 0]]
showing that arr[0][0 .. 2] is making the same index as arr[0 .. 
3][0] ?


Instead of using [0 .. 2] I can use the actual indices to get the 
result I desired:

arr[0][0] = 3;
arr[1][0] = 3;
which produces:
[[3, 0, 0], [3, 0, 0]]

Could I just get some help with understanding how the slice [0 .. 
2] actually works? Thanks

Re: State of D 2018 Survey

[bauss via Digitalmars-d-announce]

On Wednesday, 28 February 2018 at 20:37:36 UTC, Seb wrote:

On Wednesday, 28 February 2018 at 20:24:00 UTC, JN wrote:

On Wednesday, 28 February 2018 at 20:01:16 UTC, Seb wrote:

Thanks! I hope so too!


Is there some way to access the results without retaking the 
survey?


Yeah the link TypeForm generates at the end is permanent:

https://dlang.typeform.com/report/H1GTak/PY9NhHkcBFG0t6ig

though for some reason it doesn't show full-text answers (I 
have opened a support ticket for that a while ago).
Anyhow, as Mike said we will look at all answers and do a 
summary once the survey concluded.


Interesting results. 80% in favor for breaking changes.

Maybe it's time to not care too much about making D better and 
leave old legacy stuff that stops D from evolving behind curtains.

Re: Is the following well defined and allowed?

[Jonathan M Davis via Digitalmars-d]

On Thursday, March 01, 2018 16:01:08 Steven Schveighoffer via Digitalmars-d 
wrote:
> On 3/1/18 3:24 PM, ag0aep6g wrote:
> > On Thursday, 1 March 2018 at 20:14:07 UTC, Steven Schveighoffer wrote:
> >> dmd -version=dosafe -noboundscheck -run testarrayoverlap.d => no
> >> error, undefined behavior
> >> dmd -run testarrayoverlap.d => error
> >>
> >> @safe has nothing to do with it.
> >
> > @safe has everything to do with. @safe guarantees that there's no
> > undefined behavior. If you can trigger UB in @safe code, that's a bug.
> > The guarantee must hold whether asserts are enabled or not.
> > -noboundscheck does not just disable asserts, it undermines @safe,
> > rendering it meaningless.
>
> Yeah, it seems like -noboundscheck should never be used.

IMHO, it was a mistake to ever add it.

> > For just disabling asserts (without affecting @safe), there's -release.
> > With your same code, `dmd -release` => UB, but `dmd -release
> > -version=dosafe` => Error.
>
> I was unaware that it would work this way. I thought it would be the
> same whether you used @safe or not with -release.

That depends on the feature. It's true for array bounds checking, but it's
not true for stuff like final switch statements - or apparently, this
situation. I don't know if that should be changed or not. Probably.

- Jonathan M Davis

Re: Is the following well defined and allowed?

[Steven Schveighoffer via Digitalmars-d]

On 3/1/18 3:24 PM, ag0aep6g wrote:

On Thursday, 1 March 2018 at 20:14:07 UTC, Steven Schveighoffer wrote:
dmd -version=dosafe -noboundscheck -run testarrayoverlap.d => no 
error, undefined behavior

dmd -run testarrayoverlap.d => error

@safe has nothing to do with it.


@safe has everything to do with. @safe guarantees that there's no 
undefined behavior. If you can trigger UB in @safe code, that's a bug. 
The guarantee must hold whether asserts are enabled or not. 
-noboundscheck does not just disable asserts, it undermines @safe, 
rendering it meaningless.


Yeah, it seems like -noboundscheck should never be used.

It's undefined behavior if the check is disabled. How you get the check 
disabled may be affected by @safe, but whether it's UB or not has 
nothing to do with @safe. It has to do with "I turned off the checks". 
Basically, in D, if your program *would have* thrown an Error, but 
didn't because you turned it off, the compiler is free to assume UB.




For just disabling asserts (without affecting @safe), there's -release. 
With your same code, `dmd -release` => UB, but `dmd -release 
-version=dosafe` => Error.


I was unaware that it would work this way. I thought it would be the 
same whether you used @safe or not with -release.


-Steve

Re: Garbage collected pointers?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, March 01, 2018 15:53:08 Steven Schveighoffer via Digitalmars-d-
learn wrote:
> On 3/1/18 3:33 PM, H. S. Teoh wrote:
> > Won't a precise GC scanning for pointers to aligned objects want to skip
> > values that can't be an aligned pointer?  Though in D's case, being
> > required to be conservative would negate this.
>
> int[] x = [1,2,3];
> void[] y = x;
> y = y[1 .. $]; // misaligned pointer.
>
> It's easy to do, and it's done all over the place (buffers anyone?).

Yeah, until recently readText could kill your program because of that, which
I found out the hard way when I had to muck around with some UTF-16 files.
It's an easy mistake to make.

- Jonathan M Davis

Re: Garbage collected pointers?

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/1/18 3:33 PM, H. S. Teoh wrote:

On Thu, Mar 01, 2018 at 02:52:26PM -0500, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
[...]

There are a few in there, which I think are over-the-top. Such as
"don't cast a pointer to a non-pointer",

[...]

Isn't that necessary for a precise GC?


It's not strictly necessary for a precise GC. It's necessary for a 
copying GC. In that case, if the GC decides to move your object and 
update all the references, it would miss that one. And even there, it's 
not necessary that you refrain from casting, it's just necessary to 
refrain from using that as an actual pointer in the future. I can't see 
how you might print a pointer value without casting it to an integer ;)


What is more important is that you don't use that as the ONLY reference 
to the object.




Also, AIUI the current GC already does not scan size_t[] blocks for
pointers, so if you cast a pointer to size_t and put it in such an array
with no other references to your object, you stand the chance of the GC
collecting your object while it is still live.


Again, the key is "no other references". The document referenced above 
just says you can't cast.



or "Do not take advantage of alignment of pointers to store bit flags
in the low order bits".

[...]

Won't a precise GC scanning for pointers to aligned objects want to skip
values that can't be an aligned pointer?  Though in D's case, being
required to be conservative would negate this.


int[] x = [1,2,3];
void[] y = x;
y = y[1 .. $]; // misaligned pointer.

It's easy to do, and it's done all over the place (buffers anyone?).

-Steve

Re: Garbage collected pointers?

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

On Thu, Mar 01, 2018 at 02:52:26PM -0500, Steven Schveighoffer via 
Digitalmars-d-learn wrote:
[...]
> There are a few in there, which I think are over-the-top. Such as
> "don't cast a pointer to a non-pointer",
[...]

Isn't that necessary for a precise GC?

Also, AIUI the current GC already does not scan size_t[] blocks for
pointers, so if you cast a pointer to size_t and put it in such an array
with no other references to your object, you stand the chance of the GC
collecting your object while it is still live.


> or "Do not take advantage of alignment of pointers to store bit flags
> in the low order bits".
[...]

Won't a precise GC scanning for pointers to aligned objects want to skip
values that can't be an aligned pointer?  Though in D's case, being
required to be conservative would negate this.


T

-- 
There are three kinds of people in the world: those who can count, and those 
who can't.

Re: Is the following well defined and allowed?

[ag0aep6g via Digitalmars-d]

On Thursday, 1 March 2018 at 20:14:07 UTC, Steven Schveighoffer 
wrote:
dmd -version=dosafe -noboundscheck -run testarrayoverlap.d => 
no error, undefined behavior

dmd -run testarrayoverlap.d => error

@safe has nothing to do with it.


@safe has everything to do with. @safe guarantees that there's no 
undefined behavior. If you can trigger UB in @safe code, that's a 
bug. The guarantee must hold whether asserts are enabled or not. 
-noboundscheck does not just disable asserts, it undermines 
@safe, rendering it meaningless.


For just disabling asserts (without affecting @safe), there's 
-release. With your same code, `dmd -release` => UB, but `dmd 
-release -version=dosafe` => Error.

Re: I have a patch to let lldb demangle D symbols ; help welcome to improve it

[Luís Marques via Digitalmars-d]

On Tuesday, 27 February 2018 at 11:23:02 UTC, timotheecour wrote:
On Tuesday, 27 February 2018 at 05:28:41 UTC, Timothee Cour 
wrote:

https://github.com/llvm-mirror/lldb/pull/3
+
https://github.com/timotheecour/dtools/blob/master/dtools/lldbdplugin.d


on OSX, it works great except when encountering large symbols 
which

cause segfault when GC does a collection (triggered inside
core.demangle.demangle);
Help is welcome to improve that (or more generally to improve D
support in lldb, which I started in
https://github.com/llvm-mirror/lldb/pull/3)
NOTE: lldb doesn't accept github PR's but easier to work with 
PR's for

whoever wants to help on tha in the meantime


Specifically, the issue I'm facing is: 
https://github.com/timotheecour/dtools/issues/2 (a crash occurs 
when _d_arraysetlengthiT is called)


any help would be greatly appreciated


Thanks for working on this. I'll try to look into this in the 
next few days. (If you have further progress on this please 
provide an update here).

[Issue 14927] GDB cannot be used to debug D programs on OS X

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

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

Luís Marques  changed:

   What|Removed |Added

 CC||l...@luismarques.eu

--

Re: Is the following well defined and allowed?

[Steven Schveighoffer via Digitalmars-d]

On 3/1/18 3:06 PM, ag0aep6g wrote:

On Thursday, 1 March 2018 at 19:05:26 UTC, Steven Schveighoffer wrote:
Yes it behaves just like array bounds. No it's not well-defined if you 
disable asserts.


Right. So it's defined to throw an Error in @safe code, and it has 
undefined behavior in @system code. The spec should say this.


No.


version(dosafe)
{
void main() @safe
{
int[4] arr;
arr[0 .. 3] = arr[1 .. 4];
}
}
else
{
void main()
{
int[4] arr;
arr[0 .. 3] = arr[1 .. 4];
}
}
---

dmd -version=dosafe -noboundscheck -run testarrayoverlap.d => no error, 
undefined behavior

dmd -run testarrayoverlap.d => error

@safe has nothing to do with it.

-Steve

Re: Garbage collected pointers?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, March 01, 2018 14:52:26 Steven Schveighoffer via Digitalmars-d-
learn wrote:
> On 3/1/18 2:04 PM, Jonathan M Davis wrote:
> > On Thursday, March 01, 2018 10:55:34 Steven Schveighoffer via
> > Digitalmars-d->
> > learn wrote:
> >> It should really say that it's up to the GC implementation whether it's
> >> UB or not.
> >
> > Well, that arguably makes it UB in general then, because it can't be
> > relied on. By putting restrictions on the GC in general based on what
> > types of GCs theoretically could be used, it makes it so that D code in
> > general could theoretically work with any GC that fits the bill,
> > whereas if the rules of what was allowed changed depending on the GC
> > being used, what was valid D would effectively change depending on the
> > GC.
>
> There are a few in there, which I think are over-the-top. Such as "don't
> cast a pointer to a non-pointer", or "Do not take advantage of alignment
> of pointers to store bit flags in the low order bits". I can't conceive
> of any GC that would have fits with either of these things without
> breaking pretty much everything. While I can't conceive of it, it
> doesn't mean there isn't a reason for it. But clearly the reason isn't
> currently implemented.

It would not surprise me in the least if the list of what's allowed and
isn't allowed in there needs an overhaul. I just think that saying that
something is okay with one GC and not with another such that whether the
code is valid or not depends on which GC is being used is begging for
trouble. The approach of saying what's allowed or not in general makes more
sense, even if the exact list needs work. And D and the plans for D have
changed enough over time that the current list could be making assumptions
about what's reasonable that actually aren't at all reasonable at this
point, particularly as it's become clearer over time that certain types of
GCs probably aren't reasonable, and if officially disallowing some of them
simplified things, then that may be a good idea. It hasn't mattered much in
practice though, because the work on alternative GCs has been minimal. There
have been some, but thus far, we haven't really ended up in a situation
where choosing which GC you're doing to use is much of a thing.

- Jonathan M Davis

Re: Is the following well defined and allowed?

[ag0aep6g via Digitalmars-d]

On Thursday, 1 March 2018 at 19:05:26 UTC, Steven Schveighoffer 
wrote:
Yes it behaves just like array bounds. No it's not well-defined 
if you disable asserts.


Right. So it's defined to throw an Error in @safe code, and it 
has undefined behavior in @system code. The spec should say this.

Re: D for microservices

[Jacob Carlborg via Digitalmars-d]

On 2018-02-25 17:51, yawniek wrote:


Q: what would be needed to build a single binary (a la golang) that
works in a FROM SCRATCH docker container?


Build a completely statically linked binary by compiling using LDC and 
add the "-static" flag.


--
/Jacob Carlborg

Re: Garbage collected pointers?

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/1/18 2:04 PM, Jonathan M Davis wrote:

On Thursday, March 01, 2018 10:55:34 Steven Schveighoffer via Digitalmars-d-
learn wrote:

It should really say that it's up to the GC implementation whether it's UB
or not.


Well, that arguably makes it UB in general then, because it can't be relied
on. By putting restrictions on the GC in general based on what types of GCs
theoretically could be used, it makes it so that D code in general could
theoretically work with any GC that fits the bill, whereas if the rules of
what was allowed changed depending on the GC being used, what was valid D
would effectively change depending on the GC.


There are a few in there, which I think are over-the-top. Such as "don't 
cast a pointer to a non-pointer", or "Do not take advantage of alignment 
of pointers to store bit flags in the low order bits". I can't conceive 
of any GC that would have fits with either of these things without 
breaking pretty much everything. While I can't conceive of it, it 
doesn't mean there isn't a reason for it. But clearly the reason isn't 
currently implemented.


-Steve

[Issue 18543] Comments inside string mixin silently short-circuit code

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

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #2 from Jonathan M Davis  ---
Yeah, remember that string mixins are basically like pasting code in place. So,
it's going to act like you pasted that code into your editor, and adding a
comment with // is therefore going to have exactly the same effect as it would
if you pasted code after a //, which means that it's going to be part of the
comment.

--

Re: Opt-in non-null class references?

[Jonathan M Davis via Digitalmars-d]

On Thursday, March 01, 2018 14:59:38 aliak via Digitalmars-d wrote:
> On Wednesday, 28 February 2018 at 23:58:44 UTC, Jonathan M Davis
>
> wrote:
> > On Wednesday, February 28, 2018 19:43:07 Kagamin via
> >
> > Digitalmars-d wrote:
> >> On Wednesday, 28 February 2018 at 14:05:19 UTC, Jonathan M
> >> Davis
> >>
> >> wrote:
> >> > [...]
> >>
> >> Doesn't difficulty depend on what exactly to get right? It's
> >> not a spherical problem in vacuum.
> >
> > Feel free to discuss any code-flow analysis issues with Walter,
> > but he's consistently been against using it for much of
> > anything whenever I've seen him discuss it. Not even stuff like
> > VRP covers multiple lines of code, because doing so would
> > require code-flow analysis. And he's specifically said that
> > he's against using it for detecting when a null pointer is
> > dereferenced. IIRC, he's stated that dmd's optimizer uses
> > code-flow analysis for some stuff, but for anything that
> > involves putting it in the frontend where the behavior would
> > have to be encoded in the spec, he's been against it.
> >
> > - Jonathan M Davis
>
> Isn't DIP1000 [1] basically code flow analysis and implemented
> (kinda?) in dmd with -dip1000 now?
>
> [1] https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

DIP 1000 operates based on the type. As I understand it, it looks at the
fact that something is scope or not and then determines whether a particular
operation is valid or not based on whether the operation could result in a
reference to the data escaping. An operation is then valid or not regardless
of what other lines in the code are doing. As such, if I understand
correctly, code-flow analysis isn't really necessary, just like code-flow
analysis isn't necessary to determine what's valid or not when const is
involved.

- Jonathan M Davis

Re: Is the following well defined and allowed?

[Steven Schveighoffer via Digitalmars-d]

On 3/1/18 12:31 PM, ag0aep6g wrote:

On Thursday, 1 March 2018 at 17:06:48 UTC, Steven Schveighoffer wrote:

On 3/1/18 11:48 AM, ag0aep6g wrote:

[...]
Does that mean it has undefined behavior and should not be allowed in 
@safe code?


No, it means it's a runtime error.


But then it's well-defined, like going beyond array bounds, no?


Yes it behaves just like array bounds. No it's not well-defined if you 
disable asserts.


-Steve

Re: Garbage collected pointers?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, March 01, 2018 10:55:34 Steven Schveighoffer via Digitalmars-d-
learn wrote:
> It should really say that it's up to the GC implementation whether it's UB
> or not.

Well, that arguably makes it UB in general then, because it can't be relied
on. By putting restrictions on the GC in general based on what types of GCs
theoretically could be used, it makes it so that D code in general could
theoretically work with any GC that fits the bill, whereas if the rules of
what was allowed changed depending on the GC being used, what was valid D
would effectively change depending on the GC.

- Jonathan M Davis

Re: How to stringify a template instantiation expression?

[Simen Kjærås via Digitalmars-d]

On Thursday, 1 March 2018 at 16:46:30 UTC, Yuxuan Shui wrote:

On Wednesday, 28 February 2018 at 15:49:25 UTC, aliak wrote:
On Wednesday, 28 February 2018 at 15:09:56 UTC, Yuxuan Shui 
wrote:
For a template instantiation expression like A!(B, C!(D, E)), 
I want to get a string "A!(B, C!(D, E))", better if A, B, C, 
D, E is replaced by fully qualified name.


Is this possible?


A!(B, C!(D, E)).stringof I guess. Will print the former.

There's a Learn forum as well btw :)

Cheers


Did you actually try that? With dmd 2.079-rc1, this:

template A(T...) {}
struct B {}
struct D {}
struct E {}
template C(T...) {}
pragma(msg, (A!(B, C!(D, E))).stringof);

Prints:

A!(B, __T1CTS2ax1DTSQh1EZ)

When compiled


string TemplateStringOf(T...)()
if (T.length == 1)
{
import std.traits : TemplateOf, TemplateArgsOf;
import std.meta : AliasSeq, staticMap;
import std.string : indexOf;
import std.conv : text;
static if (is(typeof({ alias a = TemplateOf!T; })))
{
alias Tmp = TemplateOf!T;
alias Args = TemplateArgsOf!T;

enum tmpFullName = Tmp.stringof;
enum tmpName = tmpFullName[0..tmpFullName.indexOf('(')];

alias AddCommas(T...) = AliasSeq!(T, ", ");
alias ArgNames = staticMap!(.TemplateStringOf, Args);
alias SeparatedArgNames = staticMap!(AddCommas, 
ArgNames)[0..$-1];


return text(tmpName, "!(", SeparatedArgNames, ")");
}
else
{
return T[0].stringof;
}
}

unittest {
template A(T...) {}
struct B {}
struct D {}
struct E {}
template C(T...) {}

assert(TemplateStringOf!(A!(B, C!(D, E))) == "A!(B, C!(D, 
E))");

}

unittest {
template A(T) { template A(T) {} }

assert(TemplateStringOf!(A!int) == "A!(int)");
}

Probably still some corner cases I haven't thought of, but it 
seems to cover what you're asking for.


One thing I didn't bother with is disambiguation - if B exists in 
modules foo and bar, the above will not specify which foo it's 
referring to. This is left as an exercise for the reader.


--
  Simen

Re: Is the following well defined and allowed?

[ag0aep6g via Digitalmars-d]

On Thursday, 1 March 2018 at 17:06:48 UTC, Steven Schveighoffer 
wrote:

On 3/1/18 11:48 AM, ag0aep6g wrote:

[...]
Does that mean it has undefined behavior and should not be 
allowed in @safe code?


No, it means it's a runtime error.


But then it's well-defined, like going beyond array bounds, no?

Just a few thoughts on traits

[Luís Marques via Digitalmars-d]

Not very important, but I was reminded of a few things yesterday 
while filling out the survey.


1) I remember reading somewhere a long time ago that __traits had 
that ugly name because it wasn't supposed to be used directly; 
you'd instead generally use something nicer like std.traits (or 
maybe I'm misremembering the argument for naming __gshared). But 
many of things that you can do with __traits still aren't in 
std.traits. Is this intentional, or is there a will to make 
std.traits the go to place for all things traity? BTW, one 
advantage of using std.traits instead of equivalent __traits is 
that you can use UFCS.


2) I also remember when I first used __traits allMembers that I 
was surprised it returned strings instead of references to the 
members. First of all, it's not named allMembersStrings. Second, 
it seemed like if you wanted a string you could use .stringof or 
something similar, and getting the member itself was the normal 
case, so what you'd optimize for. In any case, even if the 
__trait itself is never changed, that's probably a case where we 
could add a higher-level wrapper in std.traits that returns the 
references. Related to that, I saw this code mentioned in the 
d-idioms:


BuildSettings dup() const
{
BuildSettings ret;

foreach (m; __traits(allMembers, BuildSettings))
{
static if (is(typeof(__traits(getMember, ret, m) = 
__traits(getMember, this, m).dup)))
__traits(getMember, ret, m) = __traits(getMember, 
this, m).dup;
else static if (is(typeof(__traits(getMember, ret, m) = 
__traits(getMember, this, m
__traits(getMember, ret, m) = __traits(getMember, 
this, m);

}
return ret;
}

This is pretty intimidating code (and ugly IMO) for someone who 
isn't very familiar with the more advanced D features. I think 
what makes this harder to read for the uninitiated is that it's 
directly written in terms of lower-level features, instead of 
using nicer wrappers like hasSomeProperty!X. The wrapper has the 
advantage of both documenting the intent and making it easier to 
study how SomeProperty is detected using __traits, since you 
aren't simultaneously trying to understand *what* the code is 
testing and *how*. Documenting the intent in terms of a wrapper 
also makes it easier to catch bugs in code review, without having 
having to add actual code comments.

Re: How do you get comfortable with Dlang.org's Forum?

[0xFFFFFFFF via Digitalmars-d]

On Friday, 23 February 2018 at 13:47:16 UTC, biocyberman wrote:

Want to learn something from you guys.

forum.dlang.org is by far the biggest gathering point for Dlang 
users. So, even though I wanted to get away with using 
stackoverflow.com, I have to come back here. However, to me it 
easier for me, I would like to know how you guys get 
comfortable with using the forum?


[...]


As for me, I would like more activity on Reddit.

Re: Is the following well defined and allowed?

[Steven Schveighoffer via Digitalmars-d]

On 3/1/18 11:48 AM, ag0aep6g wrote:

On 03/01/2018 04:34 PM, David Nadlinger wrote:

On Thursday, 1 March 2018 at 14:54:41 UTC, Shachar Shemesh wrote:

I.e. - is it well defined to copy between overlapping slices?


No: https://dlang.org/spec/arrays.html#overlapping-copying


Does that mean it has undefined behavior and should not be allowed in 
@safe code?


No, it means it's a runtime error.

https://run.dlang.io/is/xdiKxx

-Steve

Re: How to stringify a template instantiation expression?

[Yuxuan Shui via Digitalmars-d]

On Thursday, 1 March 2018 at 16:46:30 UTC, Yuxuan Shui wrote:

On Wednesday, 28 February 2018 at 15:49:25 UTC, aliak wrote:
On Wednesday, 28 February 2018 at 15:09:56 UTC, Yuxuan Shui 
wrote:
For a template instantiation expression like A!(B, C!(D, E)), 
I want to get a string "A!(B, C!(D, E))", better if A, B, C, 
D, E is replaced by fully qualified name.


Is this possible?


A!(B, C!(D, E)).stringof I guess. Will print the former.

There's a Learn forum as well btw :)

Cheers


Did you actually try that? With dmd 2.079-rc1, this:

template A(T...) {}
struct B {}
struct D {}
struct E {}
template C(T...) {}
pragma(msg, (A!(B, C!(D, E))).stringof);

Prints:

A!(B, __T1CTS2ax1DTSQh1EZ)

When compiled


Even worse, if the template instantiation yields another 
template, e.g:


template A(T) { template A(T) {} }

A!int.stringof returns "A(T)", which is not useful at all.

[Issue 18545] New: Casting away const with cast() triggers alias this, but returns the supertype anyway

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

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

  Issue ID: 18545
   Summary: Casting away const with cast() triggers alias this,
but returns the supertype anyway
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: default_357-l...@yahoo.de

const Nullable!string a;

Nullable!string b = a; /* This works. */

Nullable!string c = cast() a; /* This asserts in get. */

// Alright, so I guess cast() mistakenly follows the alias this?

// No!

static assert(is(typeof(cast() a) == Nullable!string));

// It follows the alias get this in Nullable, but it returns a Nullable anyway.

// Why!!

--

Re: How to stringify a template instantiation expression?

[Yuxuan Shui via Digitalmars-d]

On Wednesday, 28 February 2018 at 15:49:25 UTC, aliak wrote:
On Wednesday, 28 February 2018 at 15:09:56 UTC, Yuxuan Shui 
wrote:
For a template instantiation expression like A!(B, C!(D, E)), 
I want to get a string "A!(B, C!(D, E))", better if A, B, C, 
D, E is replaced by fully qualified name.


Is this possible?


A!(B, C!(D, E)).stringof I guess. Will print the former.

There's a Learn forum as well btw :)

Cheers


Did you actually try that? With dmd 2.079-rc1, this:

template A(T...) {}
struct B {}
struct D {}
struct E {}
template C(T...) {}
pragma(msg, (A!(B, C!(D, E))).stringof);

Prints:

A!(B, __T1CTS2ax1DTSQh1EZ)

When compiled

Re: Is the following well defined and allowed?

[ag0aep6g via Digitalmars-d]

On 03/01/2018 04:34 PM, David Nadlinger wrote:

On Thursday, 1 March 2018 at 14:54:41 UTC, Shachar Shemesh wrote:

I.e. - is it well defined to copy between overlapping slices?


No: https://dlang.org/spec/arrays.html#overlapping-copying


Does that mean it has undefined behavior and should not be allowed in 
@safe code?

[Issue 18544] Thread-safety of "proto" GC before initialisation

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

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

--- Comment #2 from Steven Schveighoffer  ---
Hm.. actually that doesn't work, because one thread could be adding roots while
the other one is initializing the GC, causing a race.

There may just have to be some sort of lock, even if it's a simple/spin lock.

--

Re: Opt-in non-null class references?

[aliak via Digitalmars-d]

On Wednesday, 28 February 2018 at 15:25:40 UTC, SimonN wrote:
My gripe is that the necessarily-nullable class reference 
doesn't express the intent.
Either a codebase must rely on silent conventions or every 
function with asserts.


I've put up a little experiment that you may be interested in for 
this part of the problem at least, also a little bit of compile 
time help because D treats dot on pointers and non pointers the 
same, it makes for some nice syntax:


class C {
int i = 3;
}

auto a = no!C;

if (auto c = a.unwrap) {
writeln("not here: ", c.i);
}
a.dispatch.i; // not ideal, but is at least safe no op.

a = some(new C());

if (auto c = a.unwrap) {
writeln("here: ", c.i);
}

If you're interested: https://github.com/aliak00/optional

Syntax allowing:
Optional!C = null;

is not there yet, but I think is doable because typeof(null) is 
distinguishable. So with an optional type this can be well 
defined as "none" internally as well


Not ideal I know, but maybe a start to see where it can go?

It's merely sad to see D, with all its powerful static 
inspection, rely on runtime tests for nulls while other 
languages (Kotlin, Zig, and 2017 C#) rule null out at 
compile-time, as if it's the most natural thing in the world.


Yeah, I whole heartedly agree with this. Maybe is an exposure 
thing? I remember seeing a talk (by I think the kickstarter 
people) that said after migrating to swift (from objective-c) 
their crash reports because dropped significantly (my brain for 
some reason remembers this to be zero, but I'm not sure and I 
can't figure out which talk this was).


Cheers,
- Ali

[Issue 18544] Thread-safety of "proto" GC before initialisation

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
A thought on a potential fix: once you detect ranges being added/removed from
independent threads, then you initialize the GC.

You should be able to do this with an atomic read, and then CAS to a ProtoGC
instance variable that stores the "main thread" id.

The atomic read should be negligible compared to manipulating the roots/ranges
arrays.

--

Re: C++ launched its community survey, too

[German Diago via Digitalmars-d]

On Tuesday, 27 February 2018 at 17:33:52 UTC, 12345swordy wrote:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei 
Alexandrescu wrote:

https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

Andrei


I have submitted, already. My major complaints boils down to 
the fact that they refuse to deprecated features due to 
religious like devotions to backwards compatibility support.


Well, not religious but... they are removing things too slow. 
There is a paper about stability and velocity of C++ that 
proposes to widen things to move forward faster and... btw I 
complained about exactly that as well. Things are getting bigger 
and bigger, just discard things. I also complained about the 
following:


1.- everyone is saying stop the preprocessor... modules support 
no preprocessor after import... ok, then, why feature test 
macros? They should be enums or constexpr but never a 
preprocessor macro.
2.- the single thing that bothers me the most... initialization 
is a mess, especially after adding {} vs (). With good intention, 
but the cognitive overhead and room for surprises is too big.
3.- if constexpr cannot simply compete with static if. I 
suggested adding: if constexpr that does not require a template 
function, and some alternative if constexpr mechanism (I do not 
care about the name or if it is a separate feature) that can 
conditionally compile structs or block scopes a la version() in 
D. This feature is needed to kill the preprocessor if they really 
want to take that seriously, especially with modules on its way.


BTW, I have been trying a bit of D lately and I like how flexible 
things such as opDispatch and static if are. I love modules as 
well. I like a lot also the fact that you do not need to be 
prefixing all things all the time because of potential hijacking. 
The static reflection has also been useful for me. I was just 
coding a SNES ROM parser but that was enough already to show some 
of the advantages.

Re: Function template declaration mystery...

[Robert M. Münch via Digitalmars-d-learn]

On 2018-03-01 12:01:19 +, Steven Schveighoffer said:


Ok, here it is: https://pastebin.com/tKACi488

See lines 81-84 for how I call it. And the problem I have is that 
doSubscribe returns "something" I'm not sure what I can do with. But if 
the scope ends, my subscription seems to be deleted and hence is not 
called when a message is coming in (see line: 118)




Looking through the rx package, it seems that it returns a class 
instance. That class implements the Disposable interface.


Yes, AFAIU this can be kept around for reference. Seems to be intended 
for later access to the observers.


I'm guessing from this observation that the class instance will 
unregister the subscription if it's destroyed, and because you aren't 
keeping a reference to that instance, the GC comes along and destroys 
it at some point.


That was my guess too. But it's not the case. The unary is kept, hence 
I can just ignore the return value.


What bite me here was a Windows effect. I subscribed my observer after 
the call to RegisterClass/CreateWindow. But Windows sometimes calls the 
window-procedure directly, without going through the message loop. And 
the messages I want to trigger on, are exactly ones that go directly.


So, my code was never triggered because it just wasn't there. And after 
it was there, no more messages flow in. :-/


After rearranging things a bit it's working. But anyway, learned a lot 
while digging through the code and your feedback helped too.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Garbage collected pointers?

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/1/18 10:35 AM, John Burton wrote:

On Thursday, 1 March 2018 at 12:20:08 UTC, Steven Schveighoffer wrote:

On 3/1/18 7:05 AM, Gary Willoughby wrote:

On Thursday, 1 March 2018 at 10:10:27 UTC, John Burton wrote:
My question is how do I tell if a pointer is "garbage collected" or 
not?


You could try `GC.addrOf()` or `GC.query()` in core.memory.


I was going to say this, but then I realized, it's not that the 
pointer points at GC-allocated memory, but that the pointer itself is 
stored in a location that is scanned by the GC. That's not as easy to 
figure out, as you have to look at stacks, added ranges, etc.


Ah it's where the pointer is stored. That makes some sense.
Thanks


Yes, the text isn't exactly clear. For instance, C rules apply for a 
pointer stored in a block allocated by C malloc, even if it points at a 
GC piece of memory -- as long as the block hasn't been added as a root 
or range to the GC.


Also note that realistically, even though the document talks about a 
"copying GC", this probably will never happen. Many things that are 
identified as "undefined behavior" in that doc, are probably going to be 
fine. I really wish it didn't say UB for a lot of those things. It 
should really say that it's up to the GC implementation whether it's UB 
or not.


-Steve

[Issue 18544] New: Thread-safety of "proto" GC before initialisation

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

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

  Issue ID: 18544
   Summary: Thread-safety of "proto" GC before initialisation
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: c...@klickverbot.at

https://github.com/dlang/druntime/pull/2057 was merged without thread safety
concerns being addressed.

The code needs to be checked carefully for its behaviour when several threads
are accessing the GC before the ProtoGC has been swapped out with the real
implementation
(https://github.com/dlang/druntime/pull/2057#discussion_r168910433).

If threads are created using the standard "auto t = new Thread(...); […]"
idiom, this is of course not going to be an issue, because the GC will already
have been initialised when the child thread is spawned. However, it is
conceivable that two independent C threads concurrently start to use D(runtime)
code.

--

Re: Garbage collected pointers?

[John Burton via Digitalmars-d-learn]

On Thursday, 1 March 2018 at 12:20:08 UTC, Steven Schveighoffer 
wrote:

On 3/1/18 7:05 AM, Gary Willoughby wrote:

On Thursday, 1 March 2018 at 10:10:27 UTC, John Burton wrote:
My question is how do I tell if a pointer is "garbage 
collected" or not?


You could try `GC.addrOf()` or `GC.query()` in core.memory.


I was going to say this, but then I realized, it's not that the 
pointer points at GC-allocated memory, but that the pointer 
itself is stored in a location that is scanned by the GC. 
That's not as easy to figure out, as you have to look at 
stacks, added ranges, etc.


-Steve


Ah it's where the pointer is stored. That makes some sense.
Thanks

Re: Is the following well defined and allowed?

[David Nadlinger via Digitalmars-d]

On Thursday, 1 March 2018 at 14:54:41 UTC, Shachar Shemesh wrote:

I.e. - is it well defined to copy between overlapping slices?


No: https://dlang.org/spec/arrays.html#overlapping-copying

 —David

Re: How do you get comfortable with Dlang.org's Forum?

[Basile B. via Digitalmars-d]

On Tuesday, 27 February 2018 at 20:09:22 UTC, Patrick Schluter 
wrote:

On Tuesday, 27 February 2018 at 07:33:05 UTC, Basile B. wrote:
On Saturday, 24 February 2018 at 19:30:52 UTC, Patrick 
Schluter wrote:
On Saturday, 24 February 2018 at 18:46:50 UTC, Steven 
Schveighoffer wrote:

On 2/24/18 7:00 AM, Patrick Schluter wrote:

[...]


Wow, that's insane. I would be interested in seeing it.

It's in the history of my work PC, may be I will find it on 
monday.


I'm french, i'm interested to know what the hell you talked 
about. Google search gave nothing. Do you referred to the 
journalist who was harassed by people on a gamer forum ?


No, it was not the Nadia Daam thing, she is probably too 
incompetent to pull that trick off.
As for the link, I checked but haven't found it. It was part of 
a longer youtube video but I don't remember which. Sorry.


Patrick, you should keep these kind of things out of there.
Right now you look like a guy who

1. either has been influebced by bullshits from the extreme right 
wing: read-believe-propagate.

2. or is a direct source of bullshits.

For the record: 
https://forum.dlang.org/post/upiiglzypphvaprll...@forum.dlang.org


That's not nice.

Re: How do you get comfortable with Dlang.org's Forum?

[rikki cattermole via Digitalmars-d]

On 02/03/2018 3:08 AM, Nick Sabalausky (Abscissa) wrote:

On 02/28/2018 12:48 PM, Vang Le wrote:
I don't mean to go into the good vs bad direction. What I was saying 
is that it is hard to get comfortable and use the forum the most 
effective/convenient ways. The forum should not be a technical barrier 
for members to communicate conveniently.


With that said, I am glad that I put up the questions and got a bunch 
of useful tips to use the forums. FYI, the most useful one is to 
install a NNTP client and use the 'forum' the way it is, a NNTP server 
with a web interface.


Speaking of which, and I apologize if this is inappropriate context, but 
has anyone found a good Android NNTP reader for this? I wasn't really 
able to find much when I looked, so I just use DFeed when I'm on the go, 
which is great (fantastic, really!) as far as web interfaces go, but a 
proper native reader would be really nice if anyone has any good tips!


I've used[0] in the past to read, but not for writing.

[0] https://play.google.com/store/apps/details?id=net.piaohong.newsgroup

Re: Opt-in non-null class references?

[aliak via Digitalmars-d]

On Wednesday, 28 February 2018 at 23:58:44 UTC, Jonathan M Davis 
wrote:
On Wednesday, February 28, 2018 19:43:07 Kagamin via 
Digitalmars-d wrote:
On Wednesday, 28 February 2018 at 14:05:19 UTC, Jonathan M 
Davis


wrote:
> [...]

Doesn't difficulty depend on what exactly to get right? It's 
not a spherical problem in vacuum.


Feel free to discuss any code-flow analysis issues with Walter, 
but he's consistently been against using it for much of 
anything whenever I've seen him discuss it. Not even stuff like 
VRP covers multiple lines of code, because doing so would 
require code-flow analysis. And he's specifically said that 
he's against using it for detecting when a null pointer is 
dereferenced. IIRC, he's stated that dmd's optimizer uses 
code-flow analysis for some stuff, but for anything that 
involves putting it in the frontend where the behavior would 
have to be encoded in the spec, he's been against it.


- Jonathan M Davis


Isn't DIP1000 [1] basically code flow analysis and implemented 
(kinda?) in dmd with -dip1000 now?


[1] https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

Re: Slide - what does withPartial do?

[Seb via Digitalmars-d-learn]

On Thursday, 1 March 2018 at 08:31:05 UTC, Piotr Mitana wrote:

For some reason this is true:

slide!(Yes.withPartial)([1, 2, 3, 4, 5], 3).array == [[1, 2, 
3], [2, 3, 4], [3, 4, 5]]


Shouldn't it rather return [[1], [1, 2], [1, 2, 3], [2, 3, 4], 
[3, 4, 5], [4, 5], [5]], or at least [[1, 2, 3], [2, 3, 4], [3, 
4, 5], [4, 5], [5]]?


I can see no difference on the result when withPartial is on 
and off.


Is it a bug or I don't understand it correctly?


No it's not a bug.
Yes.withPartial (the default) means that if the last element in 
the range doesn't have the full size it still gets printed, with 
No.withPartial it's not part of the range.

It's gets clearer with a different step size:

---
foreach (i; 5 .. 10)
slide!(Yes.withPartial)(i.iota, 3, 4).writeln;
---


---
[[0, 1, 2], [4]]
[[0, 1, 2], [4, 5]]
[[0, 1, 2], [4, 5, 6]]
[[0, 1, 2], [4, 5, 6]]
[[0, 1, 2], [4, 5, 6], [8]]
---


---
foreach (i; 5 .. 10)
slide!(No.withPartial)(i.iota, 3, 4).writeln;
---

---
[[0, 1, 2]]
[[0, 1, 2]]
[[0, 1, 2], [4, 5, 6]]
[[0, 1, 2], [4, 5, 6]]
[[0, 1, 2], [4, 5, 6]]
---

https://run.dlang.io/is/x8Q5x8

In fact for the default step size of 1, this only has effect if 
the windowSize is larger than the range size.
BTW as a recent addition to std.range, it comes with a ton of 
unittests:


https://github.com/dlang/phobos/blob/master/std/range/package.d#L7755

(though I agree that the public documentation could explain 
No.withPartial better.)



> Shouldn't it rather return [[1], [1, 2], [1, 2, 3], [2, 3, 4],
[3, 4, 5], [4, 5], [5]], or at least [[1, 2, 3], [2, 3, 4], [3, 
4, 5], [4, 5], [5]]?



That wouldn't be a sliding window / rolling window operator.
The idea of a sliding / rolling window operator is that all 
windows have the same size. withPartial just allows you to pick 
the behavior for how the final element.


That's also how other languages implement this.
For examples, here's how sliding from Scala's standard library 
behaves:


---
(1 to 5).iterator.sliding(6).withPartial(false).toList // List()
(1 to 5).iterator.sliding(6).withPartial(true).toList //
List(List(1, 2, 3, 4, 5))


(1 to 5).iterator.sliding(3, 4).withPartial(false).toList // 
List(List(1, 2, 3))
(1 to 5).iterator.sliding(3, 4).withPartial(true).toList // 
List(List(1, 2, 3), List(5))

---

https://scastie.scala-lang.org/pR5pH6DRTWuiVR7GNUTbJA

Is the following well defined and allowed?

[Shachar Shemesh via Digitalmars-d]

a[0..10][] = a[5..15][];

I.e. - is it well defined to copy between overlapping slices? Does it 
matter if, in the copy, the source is overlapping the end or the 
beginning of the destination?

Re: How do you get comfortable with Dlang.org's Forum?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/28/2018 12:48 PM, Vang Le wrote:
I don't mean to go into the good vs bad direction. What I was saying is 
that it is hard to get comfortable and use the forum the most 
effective/convenient ways. The forum should not be a technical barrier 
for members to communicate conveniently.


With that said, I am glad that I put up the questions and got a bunch of 
useful tips to use the forums. FYI, the most useful one is to install a 
NNTP client and use the 'forum' the way it is, a NNTP server with a web 
interface.


Speaking of which, and I apologize if this is inappropriate context, but 
has anyone found a good Android NNTP reader for this? I wasn't really 
able to find much when I looked, so I just use DFeed when I'm on the go, 
which is great (fantastic, really!) as far as web interfaces go, but a 
proper native reader would be really nice if anyone has any good tips!

[Issue 18543] Comments inside string mixin silently short-circuit code

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

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

--

[Issue 18543] Comments inside string mixin silently short-circuit code

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

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

Andrea Fontana  changed:

   What|Removed |Added

 CC||trik...@gmail.com

--- Comment #1 from Andrea Fontana  ---
Just because you're mixin a single line.
Adding \n will solve the problem

import std.stdio;

void main(string[] args)
{
mixin(""
~"writeln(\"Hello\");"
~"// Some comment\n"
~"assert(0);"
);  
}

your code sounds like:

void main()
{
writeln("hello"); // Some comment assert(0)
}

--

[Issue 18543] New: Comments inside string mixin silently short-circuit code

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

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

  Issue ID: 18543
   Summary: Comments inside string mixin silently short-circuit
code
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: edi33...@gmail.com

I have recently stumbled upon the following wrong behaviour inside string
mixins.

If you use a single line style comment (//) inside a string mixin, this will
silently short-circuit the code, leading to unexpected behaviour, as you can
see in the example bellow:

import std.stdio;

void main(string[] args)
{
mixin(""
~"writeln(\"Hello\");"
~"// Some comment"  
~"assert(0);"
);  
}

The assert will never get triggered.

If you use multi-line comments (/* */) those are correctly recognized and
everything works as expected.

--

[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"

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

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

--- Comment #5 from Steven Schveighoffer  ---
Note that == will shortcut and return true if the two instances are the same
object.

--

[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"

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

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

--- Comment #4 from Steven Schveighoffer  ---
All I'm saying is that I don't think we need to enforce this. There are reasons
to use ==.

--

[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"

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

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

--- Comment #3 from Basile B.  ---
With this dll stuff it's hardly applicable...

--

[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"

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

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

--- Comment #2 from Basile B.  ---
(In reply to Steven Schveighoffer from comment #1)
> I thought in the cases of DLLs, the typeids from different object files
> could be identical, but different instances.

Nobody has said you're wrong. It's even a case where the lowering is invalid.

--

Re: Garbage collected pointers?

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/1/18 7:05 AM, Gary Willoughby wrote:

On Thursday, 1 March 2018 at 10:10:27 UTC, John Burton wrote:

My question is how do I tell if a pointer is "garbage collected" or not?


You could try `GC.addrOf()` or `GC.query()` in core.memory.


I was going to say this, but then I realized, it's not that the pointer 
points at GC-allocated memory, but that the pointer itself is stored in 
a location that is scanned by the GC. That's not as easy to figure out, 
as you have to look at stacks, added ranges, etc.


-Steve

[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
I thought in the cases of DLLs, the typeids from different object files could
be identical, but different instances.

--

Re: Garbage collected pointers?

[Gary Willoughby via Digitalmars-d-learn]

On Thursday, 1 March 2018 at 10:10:27 UTC, John Burton wrote:
My question is how do I tell if a pointer is "garbage 
collected" or not?


You could try `GC.addrOf()` or `GC.query()` in core.memory.

Re: Function template declaration mystery...

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/28/18 3:36 PM, Robert M. Münch wrote:
Yes, that's what the docs state. And I can imagin this. Bit this 
sentence is a bit hard to understand: "If fun is not a string, unaryFun 
aliases itself away to fun." Whatever this means.


It means that it simply becomes the alias you passed in. It means, 
there's no extra overhead in calling that unaryFun. But if you pass it 
something that needs some wrapping, it will do the wrapping.




This question is a little harder to understand. Perhaps you have real 
code that shows what you are confused about?


Ok, here it is: https://pastebin.com/tKACi488

See lines 81-84 for how I call it. And the problem I have is that 
doSubscribe returns "something" I'm not sure what I can do with. But if 
the scope ends, my subscription seems to be deleted and hence is not 
called when a message is coming in (see line: 118)




Looking through the rx package, it seems that it returns a class 
instance. That class implements the Disposable interface.


And the question is now, what do I have to do that subscriptions that 
are done anywhere in the code survive the scope where they have been 
created?


I'm guessing from this observation that the class instance will 
unregister the subscription if it's destroyed, and because you aren't 
keeping a reference to that instance, the GC comes along and destroys it 
at some point.


What I would recommend is you have to keep a reference to that class 
somewhere. Start out by just assigning it to a global. If that fixes 
your problem, I suggest you reach out to the author of rx, or read 
through the docs to see how you should properly use it, and where you 
need to keep that subscription (and for what purpose).


If that *doesn't* fix your problem, then I'm not understanding what is 
happening, and you should definitely contact the rx author. File an 
issue in the github project.


-Steve

[Issue 1654] Array concatenation result should be implicitly castable between mutable and immutable if the elements support it.

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

Summary|Array concatenation should  |Array concatenation result
   |result in mutable or|should be implicitly
   |invariant depending on  |castable between mutable
   |usage   |and immutable if the
   ||elements support it.

--

[Issue 1654] Array concatenation should result in mutable or invariant depending on usage

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

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

--- Comment #31 from Steven Schveighoffer  ---
I expect at some point for concatenation to be a fully lowered template
function, and at that point, we have all the tools to do this.

You can leave it open if you want, I was just looking through issues I had
reported, and this one just struck me as being very stale, not just in time but
in light of all the developments that have happened in D since 2007.

--

[Issue 18542] New: DMD could generate better assembly for common range check idioms

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

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

  Issue ID: 18542
   Summary: DMD could generate better assembly for common range
check idioms
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

DMD could generate better assembly for common range check idioms. Take this
program:

---
bool isUpper(dchar c) @safe pure nothrow @nogc
{
// Identical code to current std.ascii : isUpper.
return c <= 'Z' && 'A' <= c;
}
​
void main(string[] args)
{
}
---

Compiled with dmd -O -release, the code for isUpper is:
pushRBP
mov RBP,RSP
cmp EDI,05Ah
ja  LE
cmp EDI,041h
jae L12
LE: xor EAX,EAX
jmp short   L17
L12:mov EAX,1
L17:pop RBP
ret

Compiled with ldc2 -O1, the code for isUpper is:
addl$-65, %edi
cmpl$26, %edi
setb%al
retq

--

Re: State of D 2018 Survey

[Russel Winder via Digitalmars-d-announce]

On Wed, 2018-02-28 at 13:41 +, Mike Parker via Digitalmars-d-
announce wrote:
> About a month ago, Sebastian Wilzbach sent an email out to a few 
> of the core D folks asking for feedback on a survey he had put 
> together. He thought it would be useful for the Foundation to use 
> in order to make decisions about where to expend development 
> efforts. Eventually Andrei gave his stamp of approval, the survey 
> questions were tweaked, and then it was ready to roll.
> 
> Of course I would love for you to read my blog post announcing 
> it, but if you want to skip the prose and go straight to the good 
> stuff, here's the survey link:
> 
> https://seb134.typeform.com/to/H1GTak
> 

All the 1 to 5 scale questions have the label a over each of the five
options so it is not entirely obvious what to choose.

Firefox 58.0.1 on Debian Sid.
 
-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

[Issue 18541] New: comparison `==` of two typeid() should always be rewritten as a "is"

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

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

  Issue ID: 18541
   Summary: comparison `==` of two typeid() should always be
rewritten as a "is"
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

I cant see why anyone would want a full bit per bit comparison of the result of
two `typeid()` since `typeid()` returns static instances, shared for each stuff
of a given type. The idea is to have an AST rewrite of

`typeid(T1) == typeid(T2)`  

as 

`typeid(T1) is typeid(T2)`


which is compiled as faster code.

--

Re: Garbage collected pointers?

[Dmitry Olshansky via Digitalmars-d-learn]

On Thursday, 1 March 2018 at 10:10:27 UTC, John Burton wrote:

In the language spec here :-
https://dlang.org/spec/garbage.html#pointers_and_gc

It refers to a distinction between pointers to garbage 
collected memory and pointers that are not. In particular it 
says that with a non garbage collected pointer you can do 
anything  that is legal in C but with a garbage collected 
pointer there are a lot of undefined behaviors if you don't 
follow some restrictions.


Basically you can do whatever you want with pointers, you may 
twart ability of GC to free an object b/c you constructed some 
value that points to GC heap. That’s pretty much it.


Second side is loosing pointers to GC owned object, this happens 
when you put pointers into eg malloced chunk of memory.


Calling GC.addRange/removeRange you can let GC know that you 
stored pointers to GC heap in some place other then stack or GC 
heap.