Re: full path to source file __FILE__

[fdgdsgf via Digitalmars-d-learn]

On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:
Is there a way to get the full path of the current source file? 
Something like:


__FILE_FULL_PATH__

I'm asking because I'm rewriting a batch script in D, meant to 
be ran with rdmd.  However, the script needs to know it's own 
path.  The original batch script uses the %~dp0 variable for 
this, but I'm at a loss on how to do this in D.  Since rdmd 
compiles the executable to the %TEMP% directory, thisExePath 
won't work.


BATCH
-
echo "Directory of this script is " %~dp0


DLANG
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}


What's wrong with __FILE__.dirName ?

Re: New __FILE_DIR__ trait?

[rikki cattermole via Digitalmars-d]

On 22/07/2016 2:08 PM, Jonathan Marler wrote:

I've got some batch scripts I wanted to convert to D.  I'd like users to
run them using rdmd, so it's obvious where the source code lives and
easy to modify.  The problem is that the batch scripts I want to convert
rely on the %~dp0 variable, which contains the path to the batch script
itself.  Note that this variable is different then the current
directory.  I haven't been able to find a nice way to do this in D.
(Note that thisExePath won't work because rdmd compiles the code to a
temporary directory, which makes sense.)

Having known about the special __FILE__ and __LINE__ traits, I figured
there might be a trait for the file directory as well, but it appears
there is none.  I'd like to see what people think about adding a new
trait for this.  Maybe something like __FILE_DIR__?  This would contain
the directory of the source-code file it appears in.  Also if this trait
was added, one could argue that a trait containing the path and the
filename should also be added, maybe something like __FILE_FULL_PATH__?


P.S. If you know of an existing solution to this problem please let me
know.


Temporary work around:
Write a program that on calls to rdmd but before that it appends an enum 
called that, on after it removes it by shrinking the file.

Re: union initalization

[Rufus Smith via Digitalmars-d-learn]

On Friday, 22 July 2016 at 02:08:06 UTC, Ali Çehreli wrote:

On 07/21/2016 06:48 PM, Rufus Smith wrote:
> I would like to combine two types
>
>
> template Foo(A, B = 4)
> {
>  union
>  {
> byte b = B;
> int a = A << 8;
>  }
> }
>
> This packs a and b together in to an int bytes, saving an
int(rather
> than storing a and b in an int each) and makes it easier to
access.

Bitfields may actually be useful in this case:

  https://dlang.org/phobos/std_bitmanip.html#.bitfields



They don't allow default assignment though?


> I get an error about overlapping default initialization. They
don't
> actually overlap in this case because of the shift.

The following at least compiles:

struct Foo(int A, byte B = 4)
{
union
{
byte b = void;
int a = void;
uint __both = (A << 8) | B;
}
}

void main() {
auto f = Foo!(42)();
}

Ali


Maybe... I don't like extra member. Bitfields seem like it would 
be the best way but I require default initialization. I want to 
hide as details of the work on unpacking as possible.

Re: full path to source file __FILE__

[Jonathan Marler via Digitalmars-d-learn]

On Thursday, 21 July 2016 at 22:57:06 UTC, Jonathan M Davis wrote:
On Thursday, July 21, 2016 18:39:45 Steven Schveighoffer via 
Digitalmars-d- learn wrote:

[...]


It would be pretty terrible actually to put the executable in 
the source path, and in many cases, the user wouldn't even have 
the permissions for it. For instance, what if the script were 
in /usr/local/bin? They won't have the permissions for the 
executable to end up there, and it would just cause a bunch of 
clutter in /usr/local/bin, since you'd get a new executable 
every time it decided that it needed to rebuild it (and you 
wouldn't want it to delete the executable every time, otherwise 
it would have to rebuild it every time, making it so that it 
would _always_ have to compile your script when it runs instead 
of just sometimes). Right now, the executable ends up in a temp 
directory, which makes a lot of sense.


Maybe it would make sense to have such a flag for very rare 
cases, but in general, it seems like a terrible idea.


- Jonathan M Davis


I agree this isn't a very good solution for the problem at hand.  
Putting the executable in a temporary directory makes sense in 
any cases I can think of. I posted an idea for another potential 
solution 
(http://forum.dlang.org/thread/cmydxneeghtjqjrox...@forum.dlang.org), please let me know your thoughts.  Thanks.

Re: full path to source file __FILE__

[Jonathan Marler via Digitalmars-d-learn]

On Friday, 22 July 2016 at 01:52:57 UTC, Adam D. Ruppe wrote:
On Thursday, 21 July 2016 at 22:47:42 UTC, Jonathan Marler 
wrote:
I explain in the original post. Any ideas Adam? Thanks in 
advance.


But why does the batch script use it? Since you are rewriting 
anyway, maybe you can find an easier/better way to achieve the 
goal.


The script depends on other files relative to where it exists on 
the file system.  I couldn't think of a better design to find 
these files then knowing where the script exists, can you?

New __FILE_DIR__ trait?

[Jonathan Marler via Digitalmars-d]

I've got some batch scripts I wanted to convert to D.  I'd like 
users to run them using rdmd, so it's obvious where the source 
code lives and easy to modify.  The problem is that the batch 
scripts I want to convert rely on the %~dp0 variable, which 
contains the path to the batch script itself.  Note that this 
variable is different then the current directory.  I haven't been 
able to find a nice way to do this in D.  (Note that thisExePath 
won't work because rdmd compiles the code to a temporary 
directory, which makes sense.)


Having known about the special __FILE__ and __LINE__ traits, I 
figured there might be a trait for the file directory as well, 
but it appears there is none.  I'd like to see what people think 
about adding a new trait for this.  Maybe something like 
__FILE_DIR__?  This would contain the directory of the 
source-code file it appears in.  Also if this trait was added, 
one could argue that a trait containing the path and the filename 
should also be added, maybe something like __FILE_FULL_PATH__?



P.S. If you know of an existing solution to this problem please 
let me know.

Re: union initalization

[Ali Çehreli via Digitalmars-d-learn]

On 07/21/2016 06:48 PM, Rufus Smith wrote:
> I would like to combine two types
>
>
> template Foo(A, B = 4)
> {
>  union
>  {
> byte b = B;
> int a = A << 8;
>  }
> }
>
> This packs a and b together in to an int bytes, saving an int(rather
> than storing a and b in an int each) and makes it easier to access.

Bitfields may actually be useful in this case:

  https://dlang.org/phobos/std_bitmanip.html#.bitfields

> I get an error about overlapping default initialization. They don't
> actually overlap in this case because of the shift.

The following at least compiles:

struct Foo(int A, byte B = 4)
{
union
{
byte b = void;
int a = void;
uint __both = (A << 8) | B;
}
}

void main() {
auto f = Foo!(42)();
}

Ali

How do I use the ScopedAllocator?

[Yuxuan Shui via Digitalmars-d]

Is it OK to use makeArray with ScopedAllocator to allocate 
something with a destructor?


Because the destructor is not called when ScopedAllocator goes 
out of scope. And if I manually call dispose, I get a double free 
error:


struct A {
int a;

~this() nothrow {
}
}
void test(){
import std.experimental.allocator.mallocator : Mallocator;
		import 
std.experimental.allocator.building_blocks.scoped_allocator : 
ScopedAllocator;

import std.experimental.allocator;
ScopedAllocator!Mallocator alloc;

auto b = alloc.makeArray!A(10, A(1));
auto c = alloc.makeArray!A(2, A(2));


alloc.dispose(b);
alloc.dispose(c);

}

void main() {
test();
}

Re: full path to source file __FILE__

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

On Thursday, 21 July 2016 at 22:47:42 UTC, Jonathan Marler wrote:
I explain in the original post. Any ideas Adam? Thanks in 
advance.


But why does the batch script use it? Since you are rewriting 
anyway, maybe you can find an easier/better way to achieve the 
goal.

union initalization

[Rufus Smith via Digitalmars-d-learn]

I would like to combine two types


template Foo(A, B = 4)
{
union
{
   byte b = B;
   int a = A << 8;
}
}

This packs a and b together in to an int bytes, saving an 
int(rather than storing a and b in an int each) and makes it 
easier to access.


I get an error about overlapping default initialization. They 
don't actually overlap in this case because of the shift.

Re: Documentation about concurrency and parallelism

[eugene via Digitalmars-d]

On Thursday, 21 July 2016 at 23:09:41 UTC, Ali Çehreli wrote:

On 07/21/2016 03:47 PM, Seb wrote:


There is also an entire chapter at the DTour
http://tour.dlang.org/tour/en/multithreading/thread-local-storage


All of those pages include In-depth sections that list links to 
other resources.


Ali


thanks

Re: Documentation about concurrency and parallelism

[eugene via Digitalmars-d]

On Thursday, 21 July 2016 at 22:47:38 UTC, Seb wrote:

On Thursday, 21 July 2016 at 20:56:07 UTC, eugene wrote:

On Thursday, 21 July 2016 at 20:46:24 UTC, eugene wrote:

Hi everyone,
could you,please, point out where can i find in the 
"Documentation" sections info about concurrency and 
parrallelism preferably with examples?


i didn't find about it in "Language reference" and "Feature 
overview", but found in "Library reference"


It's entirely a library feature, the compiler doesn't need to 
know about it.


There is also an entire chapter at the DTour
http://tour.dlang.org/tour/en/multithreading/thread-local-storage

Or the concurrency chapter from TDPL

http://www.informit.com/articles/article.aspx?p=1609144


thanks

Re: Documentation about concurrency and parallelism

[eugene via Digitalmars-d]

Or the concurrency chapter from TDPL

http://www.informit.com/articles/article.aspx?p=1609144


the book dates back 2010, is it ok?

[Issue 16309] New: DMD segfault with __traits(getProtection)

[via Digitalmars-d-bugs]

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

  Issue ID: 16309
   Summary: DMD segfault with __traits(getProtection)
   Product: D
   Version: D2
  Hardware: x86
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: cauter...@gmail.com

With DMD 2.071.1, the following code segfaults the compiler:

( https://dpaste.dzfl.pl/f46383c7f31b )

import std.digest.crc;
pragma(msg, __traits(getProtection, crcHexString));

The problem seems to revolve around this line:
https://github.com/dlang/dmd/blob/05e9e840e1be228ce0b7db8618d881894977d43e/src/traits.d#L590
This 'crcHexString' symbol has a protection of 'PROTundefined' which causes
'protectionToChars()' to return null. In debug builds, the null triggers the
assertion on the next line; in release builds, it triggers a segfault in 'new
StringExp()'.

Next step is find out why 'crcHexString' has 'PROTundefined'.

--

Re: Documentation about concurrency and parallelism

[Ali Çehreli via Digitalmars-d]

On 07/21/2016 03:47 PM, Seb wrote:


There is also an entire chapter at the DTour
http://tour.dlang.org/tour/en/multithreading/thread-local-storage


All of those pages include In-depth sections that list links to other 
resources.


Ali

Re: DConf Videos

[sarn via Digitalmars-d]

On Thursday, 21 July 2016 at 13:45:28 UTC, Steven Schveighoffer 
wrote:

On 6/6/16 6:40 AM, sarn wrote:
What's the best source of DConf videos at the moment?  Are 
there are any

edited versions released?

I'd like to share some of my favourite talks.


They are starting to arrive! 
https://twitter.com/sociomantic/status/756101557163270144


https://www.youtube.com/watch?v=DwoFb34bxAk

Video looks awesome, nice job!

-Steve


Nice!  Thanks to everyone who put the work into making these 
videos!

Re: full path to source file __FILE__

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, July 21, 2016 19:54:34 Jonathan Marler via Digitalmars-d-learn 
wrote:
> Is there a way to get the full path of the current source file?
> Something like:
>
> __FILE_FULL_PATH__
>
> I'm asking because I'm rewriting a batch script in D, meant to be
> ran with rdmd.  However, the script needs to know it's own path.
> The original batch script uses the %~dp0 variable for this, but
> I'm at a loss on how to do this in D.  Since rdmd compiles the
> executable to the %TEMP% directory, thisExePath won't work.
>
> BATCH
> -
> echo "Directory of this script is " %~dp0
>
>
> DLANG
> -
> import std.stdio;
> int main(string[] args) {
>  writeln("Directory of this script is ", ???);
> }

Well, while it might not be what you want, the obvious solution is to just
compile it as an executable and put that where you want rather than making
it a script.

- Jonathan M Davis

Re: full path to source file __FILE__

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, July 21, 2016 18:39:45 Steven Schveighoffer via Digitalmars-d-
learn wrote:
> On 7/21/16 3:54 PM, Jonathan Marler wrote:
> > Is there a way to get the full path of the current source file?
> > Something like:
> >
> > __FILE_FULL_PATH__
> >
> > I'm asking because I'm rewriting a batch script in D, meant to be ran
> > with rdmd.  However, the script needs to know it's own path.  The
> > original batch script uses the %~dp0 variable for this, but I'm at a
> > loss on how to do this in D.  Since rdmd compiles the executable to the
> > %TEMP% directory, thisExePath won't work.
> >
> > BATCH
> > -
> > echo "Directory of this script is " %~dp0
> >
> >
> > DLANG
> > -
> > import std.stdio;
> > int main(string[] args) {
> >
> > writeln("Directory of this script is ", ???);
> >
> > }
>
> Sure seems like an unwanted limitation.
>
> rdmd does forward all dmd options, but there isn't really an option to
> say "put the exe in the source path".
>
> You should file an enhancement.

It would be pretty terrible actually to put the executable in the source
path, and in many cases, the user wouldn't even have the permissions for it.
For instance, what if the script were in /usr/local/bin? They won't have the
permissions for the executable to end up there, and it would just cause a
bunch of clutter in /usr/local/bin, since you'd get a new executable every
time it decided that it needed to rebuild it (and you wouldn't want it to
delete the executable every time, otherwise it would have to rebuild it
every time, making it so that it would _always_ have to compile your script
when it runs instead of just sometimes). Right now, the executable ends up
in a temp directory, which makes a lot of sense.

Maybe it would make sense to have such a flag for very rare cases, but in
general, it seems like a terrible idea.

- Jonathan M Davis

Re: full path to source file __FILE__

[Jonathan Marler via Digitalmars-d-learn]

On Thursday, 21 July 2016 at 22:39:45 UTC, Steven Schveighoffer 
wrote:

On 7/21/16 3:54 PM, Jonathan Marler wrote:

Is there a way to get the full path of the current source file?
Something like:

__FILE_FULL_PATH__

I'm asking because I'm rewriting a batch script in D, meant to 
be ran
with rdmd.  However, the script needs to know it's own path.  
The
original batch script uses the %~dp0 variable for this, but 
I'm at a
loss on how to do this in D.  Since rdmd compiles the 
executable to the

%TEMP% directory, thisExePath won't work.

BATCH
-
echo "Directory of this script is " %~dp0


DLANG
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}


Sure seems like an unwanted limitation.

rdmd does forward all dmd options, but there isn't really an 
option to say "put the exe in the source path".


You should file an enhancement.

-Steve


An option for rdmd would be good, but then requires the user to 
call rdmd in a particular way. It doesnt allow the script itself 
know where it lives, which is needed in my case.

Re: Documentation about concurrency and parallelism

[Seb via Digitalmars-d]

On Thursday, 21 July 2016 at 20:56:07 UTC, eugene wrote:

On Thursday, 21 July 2016 at 20:46:24 UTC, eugene wrote:

Hi everyone,
could you,please, point out where can i find in the 
"Documentation" sections info about concurrency and 
parrallelism preferably with examples?


i didn't find about it in "Language reference" and "Feature 
overview", but found in "Library reference"


It's entirely a library feature, the compiler doesn't need to 
know about it.


There is also an entire chapter at the DTour
http://tour.dlang.org/tour/en/multithreading/thread-local-storage

Or the concurrency chapter from TDPL

http://www.informit.com/articles/article.aspx?p=1609144

Re: full path to source file __FILE__

[Jonathan Marler via Digitalmars-d-learn]

On Thursday, 21 July 2016 at 22:33:39 UTC, Adam D. Ruppe wrote:

On Thursday, 21 July 2016 at 22:28:39 UTC, zabruk70 wrote:

won't? what this means?


That gives the path to the .exe but he wants the path to the .d.

But why? I would think the current working directory is 
probably adequate and that's easy to get...


I explain in the original post. Any ideas Adam? Thanks in advance.

Re: full path to source file __FILE__

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/21/16 3:54 PM, Jonathan Marler wrote:

Is there a way to get the full path of the current source file?
Something like:

__FILE_FULL_PATH__

I'm asking because I'm rewriting a batch script in D, meant to be ran
with rdmd.  However, the script needs to know it's own path.  The
original batch script uses the %~dp0 variable for this, but I'm at a
loss on how to do this in D.  Since rdmd compiles the executable to the
%TEMP% directory, thisExePath won't work.

BATCH
-
echo "Directory of this script is " %~dp0


DLANG
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}


Sure seems like an unwanted limitation.

rdmd does forward all dmd options, but there isn't really an option to 
say "put the exe in the source path".


You should file an enhancement.

-Steve

Re: full path to source file __FILE__

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

On Thursday, 21 July 2016 at 22:28:39 UTC, zabruk70 wrote:

won't? what this means?


That gives the path to the .exe but he wants the path to the .d.

But why? I would think the current working directory is probably 
adequate and that's easy to get...

Re: full path to source file __FILE__

[zabruk70 via Digitalmars-d-learn]

On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:

thisExePath won't work.


won't? what this means?

this work on my windows


import std.file: thisExePath;
import std.stdio: writeln;

void main()
{
  writeln(thisExePath());
}

Re: Documentation about concurrency and parallelism

[eugene via Digitalmars-d]

On Thursday, 21 July 2016 at 20:46:24 UTC, eugene wrote:

Hi everyone,
could you,please, point out where can i find in the 
"Documentation" sections info about concurrency and 
parrallelism preferably with examples?


i didn't find about it in "Language reference" and "Feature 
overview", but found in "Library reference"

Documentation about concurrency and parallelism

[eugene via Digitalmars-d]

Hi everyone,
could you,please, point out where can i find in the 
"Documentation" sections info about concurrency and parrallelism 
preferably with examples?

Re: The case for small diffs in Pull Requests

[Walter Bright via Digitalmars-d]

On 7/21/2016 11:57 AM, w0rp wrote:

I agree that incremental changes are much more likely too
succeed than large comprehensive changes. However, exceptions do have to be
made, because there are some tasks which just cannot be completely
incrementally, though they may be rare.


There are always exceptions. Any rule needs to be leavened with good judgement, 
not thoughtlessly followed.

std.experimental.allocator and @nogc

[Yuxuan Shui via Digitalmars-d-learn]

I was trying to use allocators in a @nogc function.

I tried FreeList!Mallocator and it works fine. But 
AllocatorList!Mallocator doesn't work. dmd complains that 
AllocatorList.allocate is not @nogc, even when 
BookkeepingAllocator is NullAllocator. But if I add '@nogc' to 
AllocatorList.allocate by hand, it works.


Is this probably a bug in how dmd deduce function properties?

Re: DConf 2016 on YouTube

[Walter Bright via Digitalmars-d-announce]

On 7/21/2016 9:35 AM, Ali Çehreli wrote:

Stealing the opportunity to announce this news... :)

  https://www.youtube.com/playlist?list=PL3jwVPmk_PRyTWWtTAZyvmjDF4pm6EX6z

Reddit:


https://www.reddit.com/r/programming/comments/4txf9w/dconf_2016_video_playlist/

Ali


Yay for the closed captioning!

Re: multithreaded hell, help!

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, July 21, 2016 21:47:09 rikki cattermole via Digitalmars-d-learn 
wrote:
> On 21/07/2016 9:44 PM, Brons wrote:
> > Im trying to access data in a global between threads.
> > So ive set my global to shared, however the object trying to access it
> > needs to also then be shared, but it cant be because its part of a
> > library...
> >
> > Is there any simple way to transfer data from one thread to another?
> >
> > 1. My situation is im reading from a serial port in a thread. Which
> > writes to my global.
> > 2. In a draw thread i need to get that data and draw my output.
> >
> > Cheers
>
> __gshared or cast away shared.

Be _very_ careful of __gshared. It's intended for C-style global variables
only - really, with the idea of using them when linking against C code. The
type system still treats them as thread-local, not shared, so it can do
optimizations based on thread-local which are incompatible with the object
being on multiple threads. You may not have much choice in this case, but
I'd strongly argue that you avoid using __gshared if possible.

An alternative would be marking the object as shared and then casting away
shared while the variable is protected by a mutex (or synchronized block) so
that you can then call non-shared, member functions on the shared object. If
you can do that instead of __gshared, I'd strongly recommend it.

However, the preferred way to share information across threads if possible
is to use std.concurrency to send messages across threads. It's somewhat
limited if you're trying to pass user-defined types across threads if
they're not value types (since they have to be immutable or shared), but if
you need to, you can cast an object to immutable on one side and back to
mutable on the other - so long as you _know_ that there are no other
instances of that object on the original thread. Value types are easy
though, since they can be copied when passed across.

__gshared _might_ be the best choice in your case. However, usually, it's
just the quick and easy way out that gets things working but which risks
subtle bugs down the line. Personally, I would only ever use it when
integrating with a C or C++ library.

- Jonathan M Davis

full path to source file __FILE__

[Jonathan Marler via Digitalmars-d-learn]

Is there a way to get the full path of the current source file? 
Something like:


__FILE_FULL_PATH__

I'm asking because I'm rewriting a batch script in D, meant to be 
ran with rdmd.  However, the script needs to know it's own path.  
The original batch script uses the %~dp0 variable for this, but 
I'm at a loss on how to do this in D.  Since rdmd compiles the 
executable to the %TEMP% directory, thisExePath won't work.


BATCH
-
echo "Directory of this script is " %~dp0


DLANG
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}

Re: The case for small diffs in Pull Requests

[w0rp via Digitalmars-d]

On Monday, 18 July 2016 at 22:30:56 UTC, Walter Bright wrote:

https://medium.com/@kurtisnusbaum/large-diffs-are-hurting-your-ability-to-ship-e0b2b41e8acf#.h3eo1yvqv

I've been advocating for a while now that PRs should be small, 
incremental, encapsulated and focused. This has not been 
without controversy. I hope the referenced article is a bit 
more eloquent and convincing than I have been.


In my experience, the number of commits in a pull request is 
irrelevant. You can always merge the entire pull request with 
`git merge --squash` instead, and if you have the luxury of 
merging via GitHub as I do in my day job, you can even do that 
via GitHub now.


What is definitely relevant is the lines of code. Once a pull 
request becomes too large, the probability that it will be merged 
decreases. At least that has been my experience. I agree that 
incremental changes are much more likely too succeed than large 
comprehensive changes. However, exceptions do have to be made, 
because there are some tasks which just cannot be completely 
incrementally, though they may be rare.


Just my two cents.

Re: Our docs should be more beautiful

[w0rp via Digitalmars-d]

I like this kind of discussion. It's good to make the website 
look as attractive and functional as we can make it. I think we 
just need to remember to file each issue individually, then group 
all of the issues to track all of them. Then each individual 
issue can be tackled, and some work can get done while the rest 
of the issues are discussed.


Maybe I'm just speaking common sense or something, but I think 
it's worth mentioning.

Re: Our docs should be more beautiful

[Charles Hixson via Digitalmars-d]

I think the Python docs looks better and are more useful...but the older 
Python docs were even better.  Sometimes fancier HTML just makes things 
less useful.


That said, I think that when feasible docs should be auto-generated from 
code included within the code files.  More like ddoc or javadoc then 
Sphinx or such.  But this shouldn't necessarily apply to the basic 
frameworks.  The basic D documentation is extremely good, it's when we 
get to the libraries that things become a bit iffy.  (Then again, I 
don't like the template syntax.  I thought the D1 docs were better than 
the D2 docs, but this might be because when they were rewritten they 
assumed things that give me trouble.  I prefer the way that Python 
handles ranges to the way the D does. Etc.  These impact the 
understanding of the documentation of many Phobos files.)



On 07/18/2016 06:41 PM, Andrei Alexandrescu via Digitalmars-d wrote:

On 07/18/2016 09:28 PM, Carl Vogel wrote:

Racket's docs have actually been designed by a professional typographer,
so might be a good reference point. Example:
https://docs.racket-lang.org/reference/flonums.html


They do look nice! -- Andrei

Re: Vision for the D language - stabilizing complexity?

[Kagamin via Digitalmars-d]

On Thursday, 21 July 2016 at 16:21:17 UTC, Andrew Godfrey wrote:
You can lower D to Assembler and analyze that. Assembler is 
simple, isn't it?


Are you trolling? Lowering discards information.


AFAIK, that's what static analysis is built for: to infer 
high-level properties of the code that are not expressed in it.

DConf 2016 on YouTube

[Ali Çehreli via Digitalmars-d-announce]

Stealing the opportunity to announce this news... :)

  https://www.youtube.com/playlist?list=PL3jwVPmk_PRyTWWtTAZyvmjDF4pm6EX6z

Reddit:


https://www.reddit.com/r/programming/comments/4txf9w/dconf_2016_video_playlist/

Ali

Re: Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

On Thursday, 21 July 2016 at 08:40:03 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 16 July 2016 at 13:09:22 UTC, Andrew Godfrey wrote:
ideas that would require a major version change. The thing 
about that is that it can't be done incrementally; it's the 
rare kind of thing that would need to be planned long in 
advance, and would have to amount to a huge improvement to 
justify even considering it.


It does not need to be planned long in advance, it only 
requires official backing as a side project. They could freeze 
current D2 as a stable release and also work on a cleanup.


Instead you get people working on their own forks (myself 
included), or spin-off languages that goes nowhere.  Because 
you need momentum.  As a result neither D or the spin-offs gain 
momentum. And there are several spin-offs (some dead).


You seem to be assuming that everyone already agrees on which set 
of changes should be made to the language. (Otherwise, how could 
you expect anyone to "officially back" a side project?)


But agreeing on which changes to make and, especially, which to 
NOT make, is the hard part. And it's why you'd need a lot of 
planning & discussion up front (if any of us non-founders wanted 
to participate). And many people don't understand this, which IMO 
is behind a lot of hard feelings in the forums.

Re: Stack Overflow Documentation D language page

[David Gileadi via Digitalmars-d]

On 7/21/16 9:20 AM, Bennet Leff wrote:

If you haven't heard, Stack Overflow is starting an open documentation
reference. It's brand new but I've already seen large contributions for
other languages. I've started to get the ball rolling but it seems like
the community would be interested in adding.

Here's the page:
http://stackoverflow.com/documentation/d


Interestingly, Microsoft is going to curate examples from SO's 
Documentation into their own docs [1]. Perhaps we can do something 
similar at some point.


[1] 
https://docs.microsoft.com/teamblog/stackoverflow-documentation-for-microsoft-developers/#futureintegration

Re: Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

On Thursday, 21 July 2016 at 09:35:55 UTC, Kagamin wrote:
On Saturday, 16 July 2016 at 06:36:33 UTC, Ola Fosheim Grøstad 
wrote:

Not sure what you mean.

1. It is more time consuming to write an analysis engine that 
can cover convoluted machinery than simple machinery.


2. It it more difficult to extend complex machinery than 
simple machinery.


3. It is more work to figure out adequate simple machinery to 
describe complex machinery, than just keeping things simple 
from the start.


Not very surprising that experienced language designers try to 
keep the core language as simple as possible?


You can lower D to Assembler and analyze that. Assembler is 
simple, isn't it?


Are you trolling? Lowering discards information.

Stack Overflow Documentation D language page

[Bennet Leff via Digitalmars-d]

If you haven't heard, Stack Overflow is starting an open 
documentation reference. It's brand new but I've already seen 
large contributions for other languages. I've started to get the 
ball rolling but it seems like the community would be interested 
in adding.


Here's the page:
http://stackoverflow.com/documentation/d

Re: DConf Videos

[Mike Parker via Digitalmars-d]

On Thursday, 21 July 2016 at 14:35:23 UTC, Dmitry wrote:



Playlist:
https://www.youtube.com/watch?v=4oDK91E3VKs=PL3jwVPmk_PRyTWWtTAZyvmjDF4pm6EX6z


Reddit: 
https://www.reddit.com/r/programming/comments/4txf9w/dconf_2016_video_playlist/

Re: DConf Videos

[Dmitry via Digitalmars-d]

On Thursday, 21 July 2016 at 13:45:28 UTC, Steven Schveighoffer 
wrote:
They are starting to arrive! 
https://twitter.com/sociomantic/status/756101557163270144


https://www.youtube.com/watch?v=DwoFb34bxAk

Video looks awesome, nice job!

-Steve


Playlist:
https://www.youtube.com/watch?v=4oDK91E3VKs=PL3jwVPmk_PRyTWWtTAZyvmjDF4pm6EX6z

Re: StackOverflow D Documentation tag

[Dmitry via Digitalmars-d]

On Thursday, 21 July 2016 at 12:08:26 UTC, Lodovico Giaretta 
wrote:

Great idea! 1/5 now.


5/5

Complete newbie

[Robert Solomon via Digitalmars-d-debugger]

I bought and downloaded cpp 8.57  I unzipped into c:dm.   I have 
not found how to start the iddm.   The docs only reference 
installing from cd.


Thx

Re: DConf Videos

[Steven Schveighoffer via Digitalmars-d]

On 6/6/16 6:40 AM, sarn wrote:

What's the best source of DConf videos at the moment?  Are there are any
edited versions released?

I'd like to share some of my favourite talks.


They are starting to arrive! 
https://twitter.com/sociomantic/status/756101557163270144


https://www.youtube.com/watch?v=DwoFb34bxAk

Video looks awesome, nice job!

-Steve

Re: Default implementations in inherited interfaces

[Saurabh Das via Digitalmars-d-learn]

On Thursday, 21 July 2016 at 12:42:14 UTC, Adam D. Ruppe wrote:

On Thursday, 21 July 2016 at 09:41:27 UTC, Saurabh Das wrote:
I have an interface A which declares a certain function. A 
second interface B inherits from A and wishes to provide a 
default implementation for that function.


You can't, interfaces cannot have implementations of virtual 
functions. Your code is trying to define two separate functions 
with the same name (the compiler should probably prohibit that, 
since it doesn't do want you want it to do).


Your best bet is to make B an abstract class instead of an 
interface. Then it can override interface functions. Of course, 
it will also tie you down as you can only inherit from one 
class, but it will actually work.


I see.

Java 8 has a 'default' keyword that allows interfaces to provide 
a default implementation and sub-classes can optionally override 
it if needed. The rationale behind it was extending interfaces 
without causing old code to faill. (called "virtual extension 
methods" or "defender methods"). The use case is similar to above.


Is there a way to achieve an equivalent functionality in D?

Thanks,
Saurabh

Re: LDC with ARM backend

[Claude via Digitalmars-d-learn]

On Thursday, 21 July 2016 at 10:30:55 UTC, Andrea Fontana wrote:

On Thursday, 21 July 2016 at 09:59:53 UTC, Claude wrote:
I can build a "Hello world" program on ARM GNU/Linux, with 
druntime and phobos.

I'll write a doc page about that.


It's a good idea :)


Done:

https://wiki.dlang.org/LDC_cross-compilation_for_ARM_GNU/Linux

I based it totally on Kai's previous page for LDC on Android.

It lacks the build for druntime/phobos unit-tests.

[Issue 15768] std.stdio.trustedStdout accesses __gshared data without synchronization.

[via Digitalmars-d-bugs]

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

--- Comment #6 from Sobirari Muhomori  ---
(In reply to Jack Stouffer from comment #2)
> In order for stdout, stdin, and stderr to be shared(File)

1. shared(File) stdio will break code that consumes it as unshared
2. always doing interlocked counting for shared(File) is still slow, consider
this optimization: https://dpaste.dzfl.pl/d8dab5b7aa1f

--

Re: The D Language Foundation has filed for non-profit status

[Andrei Alexandrescu via Digitalmars-d-announce]

On 7/21/16 5:16 AM, John Colvin wrote:

On Thursday, 21 July 2016 at 02:16:55 UTC, Andrei Alexandrescu wrote:

By the Foundation bylaws we defined, the officers of the Foundation
(Walter, Ali, and myself) are not allowed to receive payment for their
work on the Foundation.


You can still claim expenses though, no?


Affirmative. I have personally decided not to as long as I have revenue 
in my own sole proprietorship. -- Andrei

[Issue 16308] New: [ndslice] should always has save primitive

[via Digitalmars-d-bugs]

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

  Issue ID: 16308
   Summary: [ndslice] should always has save primitive
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

The reason is that Slice never calls front/popFront and others
primitives of underlaying range.

--

Re: The D Language Foundation has filed for non-profit status

[Meta via Digitalmars-d-announce]

D is almost becoming respectable ;-)

It's come far from even 2013

Re: D-Man culture

[Meta via Digitalmars-d-announce]

On Thursday, 21 July 2016 at 09:42:54 UTC, Sean Campbell wrote:

I did this about a week ago.


   ___  
  /\   /\
  \_  _/   \_  _/
   / /   \ \
  / / \ \
 / /   \ \
 \ \  /___/\   / /
  \ \ |   __  \ \ / /
   \ \|  | |\  \ / /
\ | /.\| /.\\ /
 \| \_/| \_/ \ \
  |  | |  |  | |
  |  | |  |  | |
  |  | |  |  | |
  |  | |  /  / /
  |  | | /  / /
  |  | |/  / /
  |  |_/  / /
  |__/_/
   / / \ \
  / /   \ \
 / / \ \
 | | | |
 | | | |
 | | | |___
/__| |__\

1 small improvement

Re: Default implementations in inherited interfaces

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

On Thursday, 21 July 2016 at 09:41:27 UTC, Saurabh Das wrote:
I have an interface A which declares a certain function. A 
second interface B inherits from A and wishes to provide a 
default implementation for that function.


You can't, interfaces cannot have implementations of virtual 
functions. Your code is trying to define two separate functions 
with the same name (the compiler should probably prohibit that, 
since it doesn't do want you want it to do).


Your best bet is to make B an abstract class instead of an 
interface. Then it can override interface functions. Of course, 
it will also tie you down as you can only inherit from one class, 
but it will actually work.

[Issue 16307] New: [ndslice] should be safe

[via Digitalmars-d-bugs]

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

  Issue ID: 16307
   Summary: [ndslice] should be safe
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

--

Re: Default implementations in inherited interfaces

[Lodovico Giaretta via Digitalmars-d-learn]

On Thursday, 21 July 2016 at 09:46:10 UTC, Lodovico Giaretta 
wrote:

Interesting.
This is worth a bugzilla issue, IMHO. In fact, if you try the 
other way (i.e.: you provide an implementation of func in class 
C), you get the opposite error, that you are overriding a final 
function (B.func).


Submitted as issue 16306
https://issues.dlang.org/show_bug.cgi?id=16306

[Issue 16306] Interface extending another interface with same method

[via Digitalmars-d-bugs]

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

Lodovico Giaretta  changed:

   What|Removed |Added

 CC||lodov...@giaretart.net

--

[Issue 16306] New: Interface extending another interface with same method

[via Digitalmars-d-bugs]

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

  Issue ID: 16306
   Summary: Interface extending another interface with same method
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: lodov...@giaretart.net

interface A
{
void foo();
}
interface B: A
{
void bar();
final void foo()
{
bar();
}
}

class C: B
{
void bar() {}
} // error: C does not implement A.foo

class D: B
{
void foo() {}
void bar() {}
} // error: cannot override final B.foo

So A.foo is still looked up to guarantee create the vtable, but there's no way
to provide it because B.foo is final. B.foo "hides" A.foo, without overriding
it. Why doesn't B.foo override A.foo?

This should either work as expected (B.foo overrides A.foo) or an error shall
be emitted at the definition of B.foo, because it "hides" A.foo.

See also: http://forum.dlang.org/thread/ajctidcvpndrbsoto...@forum.dlang.org

--

Re: StackOverflow D Documentation tag

[Lodovico Giaretta via Digitalmars-d]

On Thursday, 21 July 2016 at 11:09:58 UTC, Random D Guy wrote:

Hey all,

quite recently StackOverflow started to "ship their biggest 
expansion to Stack Overflow": Documentation.


http://blog.stackoverflow.com/2016/07/introducing-stack-overflow-documentation-beta

Traditionally people rate D down due its minor activity on 
StackOverflow, maybe this might be a way to address this. 
Anyway a proposal for a D Documentation page has been opened 
and if some volunteers want to chim in to back the proposed "D" 
tag for the documentation, your help is highly encouraged as 
five accounts with > 150 rep. are needed for a new proposed 
documentation tag to get accepted.


http://stackoverflow.com/documentation/d


Great idea! 1/5 now.

Re: The case for small diffs in Pull Requests

[Steven Schveighoffer via Digitalmars-d]

On 7/21/16 3:10 AM, qznc wrote:


D uses a bot [0] to do the merging. Afaik the process is that an
authorized person (Walter, Andrei, etc) comment with "Auto-merge toggled
on", then the bot toggles the merge after it ensures that tests pass.


Just FYI, there is a toggle on the auto-tester UI that adds the comment, 
and then merges using that user's id.


-Steve

Re: shuffle a character array

[pineapple via Digitalmars-d-learn]

On Wednesday, 20 July 2016 at 18:32:15 UTC, Jesse Phillips wrote:
I think you mean that your range library treats them as arrays 
of code units, meaning your library will break (some) unicode 
strings.


Right - I disagree with the assessment that all (or even most) 
char[] types are intended to represent unicode strings, rather 
than arrays containing chars.


If you want your array to be interpreted as a unicode string, 
then you should use std.utc's byGrapheme or similar functions.

StackOverflow D Documentation tag

[Random D Guy via Digitalmars-d]

Hey all,

quite recently StackOverflow started to "ship their biggest 
expansion to Stack Overflow": Documentation.


http://blog.stackoverflow.com/2016/07/introducing-stack-overflow-documentation-beta

Traditionally people rate D down due its minor activity on 
StackOverflow, maybe this might be a way to address this. Anyway 
a proposal for a D Documentation page has been opened and if some 
volunteers want to chim in to back the proposed "D" tag for the 
documentation, your help is highly encouraged as five accounts 
with > 150 rep. are needed for a new proposed documentation tag 
to get accepted.


http://stackoverflow.com/documentation/d

Re: LDC with ARM backend

[Andrea Fontana via Digitalmars-d-learn]

On Thursday, 21 July 2016 at 09:59:53 UTC, Claude wrote:
I can build a "Hello world" program on ARM GNU/Linux, with 
druntime and phobos.

I'll write a doc page about that.


It's a good idea :)

Re: LDC with ARM backend

[Claude via Digitalmars-d-learn]

On Wednesday, 20 July 2016 at 16:10:48 UTC, Claude wrote:

R_ARM_TLS_IE32 used with non-TLS symbol ??


Oh, that was actually quite obvious... If I revert the first 
android patch on LLVM sources, and build it back it works!


I can build a "Hello world" program on ARM GNU/Linux, with 
druntime and phobos.

I'll write a doc page about that.

Re: multithreaded hell, help!

[Brons via Digitalmars-d-learn]

On Thursday, 21 July 2016 at 09:47:09 UTC, rikki cattermole wrote:

On 21/07/2016 9:44 PM, Brons wrote:

Im trying to access data in a global between threads.
So ive set my global to shared, however the object trying to 
access it
needs to also then be shared, but it cant be because its part 
of a

library...

Is there any simple way to transfer data from one thread to 
another?


1. My situation is im reading from a serial port in a thread. 
Which

writes to my global.
2. In a draw thread i need to get that data and draw my output.

Cheers


__gshared or cast away shared.


__gshared has done the trick!

Thanks :)

Re: multithreaded hell, help!

[rikki cattermole via Digitalmars-d-learn]

On 21/07/2016 9:44 PM, Brons wrote:

Im trying to access data in a global between threads.
So ive set my global to shared, however the object trying to access it
needs to also then be shared, but it cant be because its part of a
library...

Is there any simple way to transfer data from one thread to another?

1. My situation is im reading from a serial port in a thread. Which
writes to my global.
2. In a draw thread i need to get that data and draw my output.

Cheers


__gshared or cast away shared.

Re: Default implementations in inherited interfaces

[Lodovico Giaretta via Digitalmars-d-learn]

On Thursday, 21 July 2016 at 09:41:27 UTC, Saurabh Das wrote:
I have an interface A which declares a certain function. A 
second interface B inherits from A and wishes to provide a 
default implementation for that function. How can I achieve 
this? I'm facing an error when I try this:


interface A
{
int func(int);
}

interface B : A
{
final int func(int)
{
return 0;
}
}

class C : B
{
}

rdmd it.d:
it.d(14): Error: class it.C interface function 'int func(int)' 
is not implemented


Thanks,
Saurabh


Interesting.
This is worth a bugzilla issue, IMHO. In fact, if you try the 
other way (i.e.: you provide an implementation of func in class 
C), you get the opposite error, that you are overriding a final 
function (B.func).

Re: D-Man culture

[Sean Campbell via Digitalmars-d-announce]

On Thursday, 21 July 2016 at 07:16:53 UTC, Ali Çehreli wrote:

On 07/20/2016 11:24 PM, Ali Çehreli wrote:

On 06/20/2016 07:14 AM, Martin Tschierschke wrote:


I found this link useful: http://dlangcomicstrips.tumblr.com/



D-Man sticks back! (D-Man stickers.)

   https://store.line.me/stickershop/product/1299646

Ali



Can you make a better ASCII D-Man drawing.

o   o
|\
 \ ___   /
  |,-oo\\
  ||||
  ||||
  ||   //
  ||__//
  '---
   \  \
   /  /
   ^  ^

Ali


   ___  
  /\   /\
  \_  _/   \_  _/
   / /   \ \
  / / \ \
 / /   \ \
 \ \  /___/\   / /
  \ \ |   __  \ \ / /
   \ \|  |  \  \ / /
\ | /.\  /.\\ /
 \| \_/  \_/ \ \
  |  ||  | |
  |  ||  | |
  |  ||  | |
  |  |/  / /
  |  |   /  / /
  |  |  /  / /
  |  |_/  / /
  |__/_/
   / / \ \
  / /   \ \
 / / \ \
 | | | |
 | | | |
 | | | |___
/__| |__\

I did this about a week ago.

multithreaded hell, help!

[Brons via Digitalmars-d-learn]

Im trying to access data in a global between threads.
So ive set my global to shared, however the object trying to 
access it needs to also then be shared, but it cant be because 
its part of a library...


Is there any simple way to transfer data from one thread to 
another?


1. My situation is im reading from a serial port in a thread. 
Which writes to my global.

2. In a draw thread i need to get that data and draw my output.

Cheers

Default implementations in inherited interfaces

[Saurabh Das via Digitalmars-d-learn]

I have an interface A which declares a certain function. A second 
interface B inherits from A and wishes to provide a default 
implementation for that function. How can I achieve this? I'm 
facing an error when I try this:


interface A
{
int func(int);
}

interface B : A
{
final int func(int)
{
return 0;
}
}

class C : B
{
}

rdmd it.d:
it.d(14): Error: class it.C interface function 'int func(int)' is 
not implemented


Thanks,
Saurabh

Re: Vision for the D language - stabilizing complexity?

[Kagamin via Digitalmars-d]

On Saturday, 16 July 2016 at 06:36:33 UTC, Ola Fosheim Grøstad 
wrote:

Not sure what you mean.

1. It is more time consuming to write an analysis engine that 
can cover convoluted machinery than simple machinery.


2. It it more difficult to extend complex machinery than simple 
machinery.


3. It is more work to figure out adequate simple machinery to 
describe complex machinery, than just keeping things simple 
from the start.


Not very surprising that experienced language designers try to 
keep the core language as simple as possible?


You can lower D to Assembler and analyze that. Assembler is 
simple, isn't it?

[Issue 16288] splitter() that doesn't eat sentinels

[via Digitalmars-d-bugs]

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

--- Comment #4 from Manu  ---
Wait up. I misread... you say std.regex.splitter.
No, that's not what I'm asking for. I'm interested in
std.algorithm.iterator.splitter. It should be in those.

--

Re: D-Man culture

[Walter Bright via Digitalmars-d-announce]

On 7/21/2016 12:16 AM, Ali Çehreli wrote:

Can you make a better ASCII D-Man drawing.

o   o
|\
 \ ___   /
  |,-oo\\
  ||||
  ||||
  ||   //
  ||__//
  '---
   \  \
   /  /
   ^  ^

Ali



Nope! That one is pretty good!

Re: The D Language Foundation has filed for non-profit status

[John Colvin via Digitalmars-d-announce]

On Thursday, 21 July 2016 at 02:16:55 UTC, Andrei Alexandrescu 
wrote:
By the Foundation bylaws we defined, the officers of the 
Foundation (Walter, Ali, and myself) are not allowed to receive 
payment for their work on the Foundation.


You can still claim expenses though, no?

Re: proposal: private module-level import for faster compilation

[Kagamin via Digitalmars-d]

On Thursday, 21 July 2016 at 08:52:42 UTC, Kagamin wrote:
Not sure if tup can solve this problem. It can if it builds 
full dependency graph for each file instead of having one graph 
for the whole project.


So a solution for make would be -deps reporting full dependency 
graph per file. Would it work for make?

Re: proposal: private module-level import for faster compilation

[Kagamin via Digitalmars-d]

On Wednesday, 20 July 2016 at 09:35:03 UTC, Dicebot wrote:
I think this is a wrong approach patching a problem instead of 
fixing it. Real solution would be to improve and mature .di 
header generation and usage by compilers so that it can become 
the default way to import packages/libraries.


As I see dependency resolution has function granularity, but 
headers have only file granularity. How do you expect headers to 
work on finer granularity level? If a module depends on another 
module, the header must assume it depends on all members of that 
module and if one member indirectly changes due to its private 
dependencies, it must be assumed that all depending modules must 
be recompiled, because they depend on the changed module even if 
they don't depend on the changed member and its private 
dependencies.


Not sure if tup can solve this problem. It can if it builds full 
dependency graph for each file instead of having one graph for 
the whole project.

Re: Vision for the D language - stabilizing complexity?

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 16 July 2016 at 13:09:22 UTC, Andrew Godfrey wrote:
ideas that would require a major version change. The thing 
about that is that it can't be done incrementally; it's the 
rare kind of thing that would need to be planned long in 
advance, and would have to amount to a huge improvement to 
justify even considering it.


It does not need to be planned long in advance, it only requires 
official backing as a side project. They could freeze current D2 
as a stable release and also work on a cleanup.


Instead you get people working on their own forks (myself 
included), or spin-off languages that goes nowhere.  Because you 
need momentum.  As a result neither D or the spin-offs gain 
momentum. And there are several spin-offs (some dead).


In the meantime low level languages like C++, Rust  and semi-high 
level languages like Swift cuts into the D feature set from both 
sides. C++ is clogged up by backwards-compatibility issues, but 
they are also smoothing out the rough edges where D once had 
clear advantages. Especially in the areas of convenience. 
C++14/C++17 are not very exciting in terms of features, but the 
additions are removing what people now seem to call «friction».


In order to stay competitive over time you need something 
significantly better, like stronger typing, which depends on 
static analysis, which requires a simple identifiable core (not a 
simple language, but a simple core language after you remove 
syntactic sugar).


One possible valuable addition would have been restricted 
refinement types, another is solid pointer analysis (without 
false positives).


Neither are incompatible with D as such, but you would probably 
need to attract compiler developers with a theoretical background 
to get it up in reasonable time. Without a clean core they will 
conclude that the it will be too much work and they will go to 
other big languages instead or work on other alternative 
languages that also go nowhere because they lack momentum...

Re: Vision for the D language - stabilizing complexity?

[Kagamin via Digitalmars-d]

That's an interesting outcome that backward compatibility matters 
for hobby users more than for commercial users :)

Re: proposal: private module-level import for faster compilation

[Johnjo Willoughby via Digitalmars-d]

On Wednesday, 20 July 2016 at 19:59:42 UTC, Jack Stouffer wrote:

On Wednesday, 20 July 2016 at 19:11:56 UTC, deadalnix wrote:
Implementation problem should not be "fixed" by changing the 
language.


I concur. If the root problem is slow compilation, then there 
are much simpler, non-breaking changes that can be made to fix 
that.


Three people agree, this could be a first on the internet!

Re: D-Man culture

[Ali Çehreli via Digitalmars-d-announce]

On 07/20/2016 11:24 PM, Ali Çehreli wrote:

On 06/20/2016 07:14 AM, Martin Tschierschke wrote:


I found this link useful: http://dlangcomicstrips.tumblr.com/



D-Man sticks back! (D-Man stickers.)

   https://store.line.me/stickershop/product/1299646

Ali



Can you make a better ASCII D-Man drawing.

o   o
|\
 \ ___   /
  |,-oo\\
  ||||
  ||||
  ||   //
  ||__//
  '---
   \  \
   /  /
   ^  ^

Ali

Re: The case for small diffs in Pull Requests

[qznc via Digitalmars-d]

On Thursday, 21 July 2016 at 06:04:24 UTC, default0 wrote:

On Thursday, 21 July 2016 at 03:30:34 UTC, Walter Bright wrote:

I've looked at many PRs that consisted of multiple commits.

The trouble with them is:

1. they often have nothing in particular to do with each other

2. I may want to pull a subset of the commits, but the only 
option I have is all or nothing


As far as I'm aware git offers the option of cherry picking 
commits. It will not mark the PR as merged or generally not be 
what you are looking for, but maybe it's a usable workaround :)


Git does, but Github does not.

D uses a bot [0] to do the merging. Afaik the process is that an 
authorized person (Walter, Andrei, etc) comment with "Auto-merge 
toggled on", then the bot toggles the merge after it ensures that 
tests pass.


In theory, the bot could be extended to merge only certain 
commits and exclude others. That might solve (2), but it muddles 
the review process.


(1) is not to be solved. If commits have nothing to do with each 
other then the should be in separate pull requests.


[0] https://github.com/braddr/d-tester

Re: D-Man culture

[Ali Çehreli via Digitalmars-d-announce]

On 06/20/2016 07:14 AM, Martin Tschierschke wrote:

On Sunday, 19 June 2016 at 15:01:33 UTC, Seb wrote:

Hi,

I am not sure how much you have heard about the D-Man, but in Japan
there is an entire culture based on the D-Man!
As I learned about this by accident (and even Walter didn't know about
it), I thought I share this great movement with the DLang community!

[...]
Funny stuff!

I found this link useful: http://dlangcomicstrips.tumblr.com/



D-Man sticks back! (D-Man stickers.)

  https://store.line.me/stickershop/product/1299646

Ali

Re: The case for small diffs in Pull Requests

[default0 via Digitalmars-d]

On Thursday, 21 July 2016 at 03:30:34 UTC, Walter Bright wrote:

I've looked at many PRs that consisted of multiple commits.

The trouble with them is:

1. they often have nothing in particular to do with each other

2. I may want to pull a subset of the commits, but the only 
option I have is all or nothing


As far as I'm aware git offers the option of cherry picking 
commits. It will not mark the PR as merged or generally not be 
what you are looking for, but maybe it's a usable workaround :)