[Issue 15660] break "immutable" with pure function and mutable reference params

[via Digitalmars-d-bugs]

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

--- Comment #4 from Steven Schveighoffer  ---
(In reply to Iakh from comment #3)
> (In reply to Steven Schveighoffer from comment #2)
> Even this works:
> import std.stdio;
> 
> int[] f(void[] a) @safe pure
> {
> return cast(int[])a;
> }

In this case, you are using a cast. The compiler pretty much gives up trying to
ensure anything when you cast, so I think it's OK to allow that.

Although, I thought such a cast wouldn't work in @safe code.

--

Re: How to warn of unused imports?

[Basile B. via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 17:54:30 UTC, Basile B. wrote:

On Tuesday, 9 February 2016 at 15:21:59 UTC, Basile B. wrote:

On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote:

On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:

Otherwise, it sounds like a decent enhancement request for 
DMD. I know other compilers who do this warning.


It definitely does sound like a decent enhancement request. I 
didn't know it wasn't implemented yet, but it should be 
pretty straightforward, since within DMD you can access the 
AST. Alternatively, implementing DIP50 might let you do it 
outside the compiler.


http://wiki.dlang.org/DIP50


DIP50 is a "golem"

It looks usefull, and it will help in many cases...but after a 
while it'll become a problem.


If you don't understand what's a "golem":

AlquiaDa was the golem of the CIA (in the 80's while russians 
were fighting in Afgnan). Useful until a certain point.


Useful until a certain point...


It's time for me to leave...once again alcool drives me crazy...
Latest weeks I've been ofensive against two guys: kinsley and 
lopatim...it's time for me to leave.


https://www.youtube.com/watch?v=6ixdPnLFVIo

seeya.

[Issue 7054] std.format.formattedWrite uses code units count as width instead of characters count

[via Digitalmars-d-bugs]

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

Marco Leise  changed:

   What|Removed |Added

 CC||marco.le...@gmx.de

--- Comment #6 from Marco Leise  ---
Graphemes work until you meet full-width characters.
Ｇｒａｐｈｅｍｅｓ  ｗｏｒｋ  ｕｎｔｉｌ  ｙｏｕ  ｍｅｅｔ  ｆｕｌｌ－ｗｉｄｔｈ  ｃｈａｒａｃｔｅｒｓ．

>From Wikipedia: "With fixed-width fonts, a halfwidth character occupies half
the width of a fullwidth character, hence the name."

https://en.wikipedia.org/wiki/Halfwidth_and_fullwidth_forms

We need UTF decoding, grapheme clustering, character categorizing,
super-cow-power width specifiers in our writeln.

--

Re: Safe cast away from immutable

[Iakh via Digitalmars-d]

On Tuesday, 9 February 2016 at 16:32:07 UTC, Steven Schveighoffer 
wrote:
I think the rules at the moment are that the compiler allows 
implicit conversion if the return value could not have come 
from any of the parameters. But what it may not consider is if 
the parameters could be return values themselves via a 
reference!


AFAIK it just traverse members and search for exactly match with 
return
type. Even more there is different checks for "pure" and "unique 
owned

result".

import std.stdio;

int[] f(void[] a) @safe pure
{
return cast(int[])a;
}

void main() @safe
{
int[] a = new int[4];

immutable b = a.f();
writeln(b);
a[0] = 1;
writeln(b);
}

This works until you change void[] to int[].
And error message is about casting to immutable not about purity.

This is terribly because if there is a code:

int[] f(SophisticatedClass a){...}
immutable a = f(new SophisticatedClass);

that was working last 100 years but then somebody adds member
of type int[] into SophisticatedClass.field.field.field
You take sort of this:
Error: cannot implicitly convert expression (f(a)) of type int[] 
to immutable(int[])


It's hard to prove that result is unique. So maybe don't try to 
do?

Re: Release vibe.d 0.7.27

[extrawurst via Digitalmars-d-announce]

On Tuesday, 9 February 2016 at 19:16:49 UTC, Sönke Ludwig wrote:

This release brings some larger changes:

 - The library has been split up into sub packages: code, 
utils, data,
   http, mail, diet, mongodb, redis and web. This is an 
intermediate
   step to moving the individual packages out to separate 
repositories

   with independent version numbers.

[...]


Awesome! Thanks for all the hard work.

--Stephan

Release vibe.d 0.7.27

[Sönke Ludwig via Digitalmars-d-announce]

This release brings some larger changes:

 - The library has been split up into sub packages: code, utils, data,
   http, mail, diet, mongodb, redis and web. This is an intermediate
   step to moving the individual packages out to separate repositories
   with independent version numbers.

 - A lot of work went into performance tuning. Single-core performance
   of the HTTP server is improved by about +50% and multi-core
   performance scales properly again after excessive lock contention
   sneaked in in one of the previous releases. The number of worker
   threads is now also properly determined on all systems (including
   multi-CPU), which should fix the numbers for multi-threaded
   benchmarks (an update to the TechEmpower benchmark suite is on the
   way).

 - The REST interface generator now supports modelling collections with
   native D syntax using Collection!T. It also adds support for CORS.

 - The std.concurrency integration has been fixed and re-enabled - you
   can now use std.concurrency without worrying about blocking the
   event loop. In case of problems (std.concurrency doesn't support
   passing certain kinds of values), the old implementation can still
   be accessed as sendCompat/receiveCompat/...

 - Compiles on 2.066.0 up to 2.070.0. Note that this will be the last
   release that supports the 2.066.x frontend. The next release will
   require at least 2.067.0 or maybe even 2.068.0 (still TBD). This may
   unfortunately rule out GDC for the time being.

 - Full list of changes: http://vibed.org/blog/posts/vibe-release-0.7.27

Homepage: http://vibed.org/
DUB package: http://code.dlang.org/packages/vibe-d
GitHub: https://github.com/rejectedsoftware/vibe.d

[Issue 15665] New: Templated scope class with constructor don't compile

[via Digitalmars-d-bugs]

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

  Issue ID: 15665
   Summary: Templated scope class with constructor don't compile
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: mathias.l...@sociomantic.com
CC: pub...@dicebot.lv

The following code:

```
scope class Foo (V)
{
this () {}
}

void main ()
{
scope f = new Foo!(Object);
}
```

Results in:
```
scope_class.d(3): Error: functions cannot return scope scope_class.Foo!(Object)
scope_class.d(8): Error: template instance scope_class.Foo!(Object) error
instantiating
```

Which is obviously wrong. Not providing a constructor, or making the class a
non-template works as expected. That's a D1 regression.

Tested with 2.066, 2.069, 2.070

--

Re: Release vibe.d 0.7.27

[Nick B via Digitalmars-d-announce]

On Tuesday, 9 February 2016 at 19:16:49 UTC, Sönke Ludwig wrote:

This release brings some larger changes:

 - A lot of work went into performance tuning. Single-core 
performance

   of the HTTP server is improved by about +50% and multi-core
   performance scales properly again after excessive lock 
contention
   sneaked in in one of the previous releases. The number of 
worker
   threads is now also properly determined on all systems 
(including

   multi-CPU), which should fix the numbers for multi-threaded
   benchmarks (an update to the TechEmpower benchmark suite is 
on the

   way).

I look forward to reading the numbers, and seeing how it 
compares, to other web servers :)


Nick

why mkdir can't create tree of dirs?

[Suliman via Digitalmars-d-learn]

It's look like that I can only create one nesting level sub 
folder, for example there is exists dir: D:\foo

I can't create dir D:\foo\bar\baz I can only create D:\foo\bar

D:\foo\bar

Is it's rational limit or it is bug? Here is error when I tried 
to folder in folder thet do not exists.


It's not very handy to write all levels by hands...

td.windows.syserror.WindowsException@C:\D\dmd2\windows\bin\..\..\src\phobos\stdfile.d(2048):
 F:\foo\imgs_projected\jma_vis\1602\123: ╨б╨╕╤Б╤В╨╡╨╝╨╡ ╨╜╨╡ ╤Г╨┤╨╨╡╤В╤Б╤П 
╨╜╨░╨╣╤В╨╕ ╤Г╨║╨░╨╖╨░╨╜╨╜╤Л╨╣ ╨┐╤Г╤В╤М. (error 3)

Re: An IO Streams Library

[Kagamin via Digitalmars-d]

On Monday, 8 February 2016 at 20:21:31 UTC, Jason White wrote:
Reads and writes are not guaranteed to fill/write the entire 
buffer you throw at it. This is what readExactly/writeExactly 
are for. Those will throw an exception if the entire read/write 
cannot be done.


You mean posix non-blocking IO?

[Issue 15663] writefln("%#o", 0) should yield "0" instead of "00"

[via Digitalmars-d-bugs]

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

Marco Leise  changed:

   What|Removed |Added

Summary|writefln("%#o", 0); -> "00" |writefln("%#o", 0) should
   ||yield "0" instead of "00"

--

Re: Is this a bug in std.typecons.Tuple.slice?

[Marc Schütz via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 09:05:58 UTC, Ola Fosheim Grøstad 
wrote:
IMO one shouldn't be able to take the reference of a tuple, to 
ensure that it can be kept in registers.


No need to restrict the language here, there's nothing stopping a 
decent compiler from storing tuples (actually _anything_) in 
registers, in some cases even if references are taken. I'm pretty 
sure LLVM can handle this.

[Issue 15663] New: writefln("%#o", 0); -> "00"

[via Digitalmars-d-bugs]

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

  Issue ID: 15663
   Summary: writefln("%#o", 0); -> "00"
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: trivial
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: marco.le...@gmx.de

The #-flag should prefix %o, %x and %X with '0', '0x' and '0X' respectively, IF
the input is different from 0. While the hex printout matches printf(), the
octal output is "00" instead of "0".

--

Re: Is this a bug in std.typecons.Tuple.slice?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 08:35:21 UTC, tsbockman wrote:
When faced with a judgment call like this, we really ought to 
err on the side of maintaining backwards compatibility - 
especially since this does not preclude adding a separate 
by-value version of `Tuple.slice`, as well. It was going to 
need a new name anyway.


I suggest lobbying for proper builtin tuple support. IMO one 
shouldn't be able to take the reference of a tuple, to ensure 
that it can be kept in registers. Modern desktop CPUs have maybe 
512 bytes of register space. In most cases a tuple will be within 
8 bytes * 16 or something like that.

Re: Is this a bug in std.typecons.Tuple.slice?

[tsbockman via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 06:22:55 UTC, Marco Leise wrote:
As mentioned I never used the feature myself and wont vote for 
one or the other. Three people with no source code to exemplify 
current use of .slice! is indeed not much to base decisions 
on...


The mere fact that all I had to do to find people who use and 
care about the `ref`-ness of `Tuple.slice` was ask, and then wait 
a few hours, strongly suggests that there are other such people 
among the D user base.


When faced with a judgment call like this, we really ought to err 
on the side of maintaining backwards compatibility - especially 
since this does not preclude adding a separate by-value version 
of `Tuple.slice`, as well. It was going to need a new name anyway.

[Issue 15661] [REG2.067.0] Destructor called while object still alive

[via Digitalmars-d-bugs]

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

--- Comment #3 from Kenji Hara  ---
Introduced in: https://github.com/D-Programming-Language/dmd/pull/4078

--

Re: Is this a bug in std.typecons.Tuple.slice?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 13:43:16 UTC, Marc Schütz wrote:
So what? Using that argument, you could just as well forbid 
taking the address of any variable. What's so special about 
tuples, in contrast to structs and arrays?


Some key common qualities for a tuple:

1. They are primarily used for multiple return values from 
functions.


2. Tuples use structural typing, not nominal typing.

3. They are identity-less. If you can take reference and compare, 
they no longer are identity-less.



Tuples should be considered immutable constants (think 
functional programming), not in-memory storage.


Again, why?


Because that is how a tuple is commonly defined, for performance 
and semantic reasons.




Tuple's can serve as a good approximation to SIMD registers.


What relation does that have to the above?


You don't want to spill out SIMD registers to the stack if you 
can avoid it. You want to do the changes within the CPU pipeline, 
i.e. using copies (and register renaming).

[Issue 15664] New: incorrect initialisation of member of an immutable struct

[via Digitalmars-d-bugs]

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

  Issue ID: 15664
   Summary: incorrect initialisation of member of an immutable
struct
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: abu...@club-internet.fr

[code]
import std.stdio;

struct Data
{
int a[2];
int b[2][2];
int c;
};

immutable Data d = {[ 1, 2], [[ 3, 4], [5, 6]], 7};

unittest
{
assert(d.c == 7);
}

void main()
{
writeln(d);
}
[/code]

Compiled with dmd x86_64 (version 2.62.2 & 2.70.0) on linux (fedora), it gives
the incorrect following output:
immutable(Data)([1, 2], [[3, 4], [5, 6]], 3)
the expected output is:
immutable(Data)([1, 2], [[3, 4], [5, 6]], 7)
Optimization compilation flags does not have any impact on the output.
The -unittest flag triggers the assert.

--

Re: Things that keep D from evolving?

[Laeeth Isharc via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 13:01:29 UTC, NX wrote:

On Monday, 8 February 2016 at 22:21:50 UTC, Laeeth Isharc wrote:
The GC itself may still be far from perfect but its much 
better than it was, and there are more options now.  I have 
found emsi containers (built on top of Andrei's allocator) 
pretty nice myself for my own use.


Well, GC being better than it used to be doesn't change the 
fact it's still the worst of it's kind. I don't know if this[1] 
work actually got released or merged but looks like it's 
abandoned. Pretty sad as it seemed very promising.


Anyway, I was expecting a lot more people to tell their 
specific problems, like "bla bla design desicion makes ARC 
incredibly dangerous and we can't properly interface with 
Objective-C without that" or like "bla bla D feature overlaps 
with some other stuff and requires redesign to be solved" or 
maybe "being unsafe (@system) by default breaks the deal"...
GC is just one of the hundreds of problems with D and it was an 
example rather than the main point in this thread but thanks 
for anyone who replied.



[1] 
http://forum.dlang.org/thread/mailman.655.1399956110.2907.digitalmar...@puremagic.com


Thanks for pointing this one out. Opportunity comes dressed in 
work clothes,and I guess that until someone takes the initiative 
to integrate this with the newest version of the runtime / GC 
then nothing will happen. It's not true that there are no 
professional opportunities in D,  as some people say, and I can 
say that for some people at least impressive contributions to the 
language and community have paid off personally even though it 
was a labour of love and not motivated by that.  Good programmers 
don't grow on trees, and one benefit of the current size of the D 
community is that it's easier to make an impact and easier to 
stand out than in a much more crowded and mature domain where one 
person can only hope to achieve incremental progress.


My impression is that barriers to adoption are fairly well 
understood by now and it's a matter of time and hard work for 
them to be addressed step by step. It's not only addressing 
negatives but also completing positive things that will help.   
Ndslice and porting BLAS on the numerical side and the interface 
with R will both increase the attractiveness of D on finance,  
not a small area.   It's not yet mature,  but knowing one can use 
all the R libraries is already a big win.

Re: Just because it's a slow Thursday on this forum

[Andrei Alexandrescu via Digitalmars-d]

On 02/09/2016 06:25 AM, Marc Schütz wrote:

On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu wrote:

On 2/7/16 7:11 PM, John Colvin wrote:

alias dump = dumpTo!stdout;
alias errDump = dumpTo!stderr;


I'm hoping for something with a simpler syntax, a la dump!(stdout,
"x") where stdout is optional. -- Andrei


Why would `stdout` need to be a template argument?


It needn't! -- Andrei

Re: Things that keep D from evolving?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote:
There are several reasons I want to use D rather than C# / Go / 
something else:

- Interfacing with native API without jumping through hoops


Well, but the hoops are there to get safe and fast GC.


- Incredibly high abstraction and meta-programming 
possibilities with relatively easier syntax + semantics.


Not incredibly high level abstraction... But I get what you mean. 
It is fairly high level for a low level language.




- Having GC (but not a horribly slow one)


So you want this to be worked on (as D has a horribly slow one)?


- Not bound to a specific platform (unlike C#, easier to do 
cross-platform work in many cases)


Doesn't C# work just as well as D (or better) with most platforms?

Re: How do you reference variables in an AA of Variants?

[Wyatt via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 03:49:11 UTC, Enjoys Math wrote:

This:   
double b = 1.0;

Variant[string] aa = ["b": ];

writeln(aa["b"]);

fails with:

Error: cannot implicitly convert expression(["b":]) of type 
double*[string] to VariantN!20u[string]


Helps please!


I've found bugbears like this are distressingly common in 
std.variant.  Another one you might find yourself dealing with is 
https://issues.dlang.org/show_bug.cgi?id=10223, which applies to 
AAs as much as regular arrays.  It's actually why I stopped using 
it in favour of Adam Ruppe's arsd.jsvar.


-Wyatt

[Issue 15661] [REG2.067.0] Destructor called while object still alive

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #4 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5431

--

[Issue 15661] [REG2.067.0] Destructor called while object still alive

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||wrong-code

--

Re: Just because it's a slow Thursday on this forum

[Andrei Alexandrescu via Digitalmars-d]

On 02/09/2016 07:46 AM, Jakob Ovrum wrote:



void main()
{
 import std.stdio : stdout;

 int a = 42;
 string b = "foo";
 float c = 3.14;

 dump!(a, b, c)(); // a = 42, b = foo, c = 3.14
 stdout.dump!(a, b, c)(" | "); // a = 42 | b = foo | c = 3.14
}


I think this is good stuff and should go in Phobos. Where particularly? 
-- Andrei

Re: Things that keep D from evolving?

[jmh530 via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 13:01:29 UTC, NX wrote:
Well, GC being better than it used to be doesn't change the 
fact it's still the > worst of it's kind. I don't know if 
this[1] work actually got released or merged but looks like 
it's abandoned. Pretty sad as it seemed very promising.
[1] 
http://forum.dlang.org/thread/mailman.655.1399956110.2907.digitalmar...@puremagic.com


It looks like interesting stuff, but the guy last posted in 2014. 
In other posts, people asked him for the code and I don't see 
anything on the forum indicating that he provided it. Probably an 
important step to improving the GC...


DMD 2.067 had some garbage collector improvements, but I'm not 
sure how influenced those would have been by this.

Re: Just because it's a slow Thursday on this forum

[Jakob Ovrum via Digitalmars-d]

On Tuesday, 9 February 2016 at 14:38:23 UTC, Andrei Alexandrescu 
wrote:

On 02/09/2016 07:46 AM, Jakob Ovrum wrote:



void main()
{
 import std.stdio : stdout;

 int a = 42;
 string b = "foo";
 float c = 3.14;

 dump!(a, b, c)(); // a = 42, b = foo, c = 3.14
 stdout.dump!(a, b, c)(" | "); // a = 42 | b = foo | c = 
3.14

}


I think this is good stuff and should go in Phobos. Where 
particularly? -- Andrei


I can't really see the applications beyond a role as a simple 
lowtech debugging aid, but since it uses std.stdio I guess that's 
an OK place to put it.

Re: How to warn of unused imports?

[Basile B. via Digitalmars-d-learn]

On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote:

On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:

Otherwise, it sounds like a decent enhancement request for 
DMD. I know other compilers who do this warning.


It definitely does sound like a decent enhancement request. I 
didn't know it wasn't implemented yet, but it should be pretty 
straightforward, since within DMD you can access the AST. 
Alternatively, implementing DIP50 might let you do it outside 
the compiler.


http://wiki.dlang.org/DIP50


DIP50 is a "golem"

It looks usefull, and it will help in many cases...but after a 
while it'll become a problem.

Re: Printing a C "string" with write(f)ln

[Daniel Kozak via Digitalmars-d-learn]

V Tue, 09 Feb 2016 12:46:59 +
Whirlpool via Digitalmars-d-learn 
napsáno:

> Hello,
> 
> When you are using a C function (from an external library) that 
> returns a pointer on char which is the beginning of a string (I 
> know that C does not have a string type, that they are just 
> arrays of chars ended by '\0'), is there a simple way to print 
> that string with D's write(f)ln, should I use C's printf, or 
> something else ? What is the best way ? Because if I do
> writefln("... %s", *pString);
> it only displays the first character of the string, the value 
> that pString points to
> 
> Thanks

http://dlang.org/phobos/std_string.html#.fromStringz

[Issue 7032] OpAssign is not called when this(this) is disabled

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

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

--- Comment #1 from Kenji Hara  ---
OpAssign never work when a variable is initialized. In this line:

>   Fail b = a;

'b' is yet not born, but opAssign needs a living 'this' instance. Therefore,
the variable 'b' initialization with an lvalue 'a' always tries to copy 'a',
then rejected by @disable this(this).

--

Re: Is this a bug in std.typecons.Tuple.slice?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 10:54:42 UTC, Marc Schütz wrote:
No need to restrict the language here, there's nothing stopping 
a decent compiler from storing tuples (actually _anything_) in 
registers, in some cases even if references are taken. I'm 
pretty sure LLVM can handle this.


If you don't restrict the language people will write code that 
the optimizer will struggle with.  LLVM can only handle what goes 
on within a compilation unit, and not if there are stores, 
because those are visible in other threads.


Tuples should be considered immutable constants (think functional 
programming), not in-memory storage.


Tuple's can serve as a good approximation to SIMD registers.

Re: Printing a C "string" with write(f)ln

[Jakob Ovrum via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 12:46:59 UTC, Whirlpool wrote:

Hello,

When you are using a C function (from an external library) that 
returns a pointer on char which is the beginning of a string (I 
know that C does not have a string type, that they are just 
arrays of chars ended by '\0'), is there a simple way to print 
that string with D's write(f)ln, should I use C's printf, or 
something else ? What is the best way ? Because if I do

writefln("... %s", *pString);
it only displays the first character of the string, the value 
that pString points to


Thanks


writefln et al sensibly does *not* assume that a pointer to char 
is a C string, for memory safety purposes.


Print the result of std.string.fromStringz[1] instead:

writeln(fromStringz(pString));
writefln("%s", fromStringz(pString));

[1] http://dlang.org/phobos/std_string#fromStringz

Re: Is this a bug in std.typecons.Tuple.slice?

[Marc Schütz via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 11:38:14 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 9 February 2016 at 10:54:42 UTC, Marc Schütz wrote:
No need to restrict the language here, there's nothing 
stopping a decent compiler from storing tuples (actually 
_anything_) in registers, in some cases even if references are 
taken. I'm pretty sure LLVM can handle this.


If you don't restrict the language people will write code that 
the optimizer will struggle with.


So what? Using that argument, you could just as well forbid 
taking the address of any variable. What's so special about 
tuples, in contrast to structs and arrays?


LLVM can only handle what goes on within a compilation unit, 
and not if there are stores, because those are visible in other 
threads.


Tuples should be considered immutable constants (think 
functional programming), not in-memory storage.




Again, why?


Tuple's can serve as a good approximation to SIMD registers.


What relation does that have to the above?

Re: Things that keep D from evolving?

[NX via Digitalmars-d-learn]

On Monday, 8 February 2016 at 17:51:02 UTC, Ola Fosheim Grøstad 
wrote:
C++ compilers have lots of optional warnings/errors, so it is 
quite possible. But I suppose those that want it would rather 
use Go, C# or some other GC language than can do ahead of time 
compilation.


There are several reasons I want to use D rather than C# / Go / 
something else:

- Interfacing with native API without jumping through hoops
- Incredibly high abstraction and meta-programming possibilities 
with relatively easier syntax + semantics.
- It's harder to reverse engineer native code than byte code 
equivalent.

- Trading off anything according to your needs.
- Expressiveness and purity, immutablity concepts.
- Having GC (but not a horribly slow one)
- Syntactic sugars (associtive arrays, powerful foreach, 
slices...)

- Compile times
- Not bound to a specific platform (unlike C#, easier to do 
cross-platform work in many cases)



I wish D could be better. I really want it with all of my heart...

[Issue 15661] [REG2.067.0] Destructor called while object still alive

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Hardware|x86_64  |All
Summary|Destructor called while |[REG2.067.0] Destructor
   |object still alive  |called while object still
   ||alive

--- Comment #2 from Kenji Hara  ---
Also happens with Win32.

--

Re: Just because it's a slow Thursday on this forum

[Marc Schütz via Digitalmars-d]

On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu 
wrote:

On 2/7/16 7:11 PM, John Colvin wrote:

alias dump = dumpTo!stdout;
alias errDump = dumpTo!stderr;


I'm hoping for something with a simpler syntax, a la 
dump!(stdout, "x") where stdout is optional. -- Andrei


Why would `stdout` need to be a template argument?

Printing a C "string" with write(f)ln

[Whirlpool via Digitalmars-d-learn]

Hello,

When you are using a C function (from an external library) that 
returns a pointer on char which is the beginning of a string (I 
know that C does not have a string type, that they are just 
arrays of chars ended by '\0'), is there a simple way to print 
that string with D's write(f)ln, should I use C's printf, or 
something else ? What is the best way ? Because if I do

writefln("... %s", *pString);
it only displays the first character of the string, the value 
that pString points to


Thanks

Re: Printing a C "string" with write(f)ln

[y via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 12:46:59 UTC, Whirlpool wrote:

Hello,

When you are using a C function (from an external library) that 
returns a pointer on char which is the beginning of a string (I 
know that C does not have a string type, that they are just 
arrays of chars ended by '\0'), is there a simple way to print 
that string with D's write(f)ln, should I use C's printf, or 
something else ? What is the best way ? Because if I do

writefln("... %s", *pString);
it only displays the first character of the string, the value 
that pString points to


Thanks


sure:
http://dlang.org/phobos/std_string.html#.fromStringz

import std.string;
string dstring = my_c_string.fromStringz;

Re: Things that keep D from evolving?

[NX via Digitalmars-d-learn]

On Monday, 8 February 2016 at 22:21:50 UTC, Laeeth Isharc wrote:
The GC itself may still be far from perfect but its much better 
than it was, and there are more options now.  I have found emsi 
containers (built on top of Andrei's allocator) pretty nice 
myself for my own use.


Well, GC being better than it used to be doesn't change the fact 
it's still the worst of it's kind. I don't know if this[1] work 
actually got released or merged but looks like it's abandoned. 
Pretty sad as it seemed very promising.


Anyway, I was expecting a lot more people to tell their specific 
problems, like "bla bla design desicion makes ARC incredibly 
dangerous and we can't properly interface with Objective-C 
without that" or like "bla bla D feature overlaps with some other 
stuff and requires redesign to be solved" or maybe "being unsafe 
(@system) by default breaks the deal"...
GC is just one of the hundreds of problems with D and it was an 
example rather than the main point in this thread but thanks for 
anyone who replied.



[1] 
http://forum.dlang.org/thread/mailman.655.1399956110.2907.digitalmar...@puremagic.com

[Issue 15662] Cannot move struct with defined opAssign due to @disabled post-blit

[via Digitalmars-d-bugs]

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

--- Comment #1 from Kenji Hara  ---
This is expected behavior. Appending element to array would cause reallocation
if there's no array.capacity. It's not related whether the appended element is
unique.

D's built-in array is a view of original memory. The viewed memory is not owned
by the array slice, so we cannot destroy the original elements freely.
Therefore, when the reallocation happens, the original elements will be copied
to a newly allocated memory (its size is enough larger than the original
array.length), then the old elements are copied into it _by using postblit_.
Finally the unique element will be moved into the allocated room.

During compilation, compiler cannot know whether the appending won't cause
reallocation, so it's conservatively rejected because of @disable-d postblit.

--

Re: D's equivalent to C++'s std::move?

[Hara Kenji via Digitalmars-d]

On Tuesday, 9 February 2016 at 00:25:33 UTC, Matt Elkins wrote:
On Thursday, 4 February 2016 at 02:33:06 UTC, Andrei 
Alexandrescu wrote:
Got it, thanks. That's a bug in the implementation, no two 
ways about it. No copy should occur there, neither 
theoretically nor practically. Please report it to bugzilla at 
http://issues.dlang.org. Thanks very much! -- Andrei


Done (sorry for the delay): 
https://issues.dlang.org/show_bug.cgi?id=15662


I've replied to issue 15662.

The point of that issue is, an array concatenation or appending 
may cause the elements' copy.
The copy occurrence is determined by the runtime situation, so 
compiler needs to reject such the operation for the @disable 
this(this) elements conservatively.


Kenji Hara

Re: Just because it's a slow Thursday on this forum

[Jakob Ovrum via Digitalmars-d]

On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu 
wrote:

On 2/7/16 7:11 PM, John Colvin wrote:

alias dump = dumpTo!stdout;
alias errDump = dumpTo!stderr;


I'm hoping for something with a simpler syntax, a la 
dump!(stdout, "x") where stdout is optional. -- Andrei


This works:

---

import std.stdio : File;
static import std.ascii;

template dump(symbols...)
{
import std.stdio : File;

void dump(Separator, Terminator)(
File file,
Separator separator = ", ",
Terminator terminator = std.ascii.newline)
{
foreach(i, symbol; symbols[0 .. $ - 1])
			file.write(__traits(identifier, symbols[i]), " = ", symbol, 
separator);
		file.write(__traits(identifier, symbols[$ - 1]), " = ", 
symbols[$ - 1], terminator);

}

void dump(Separator, Terminator)(
Separator separator = ", ",
Terminator terminator = std.ascii.newline)
if (!is(Separator == File))
{
import std.stdio : stdout;
.dump!symbols(stdout, separator, terminator);
}
}

void main()
{
import std.stdio : stdout;

int a = 42;
string b = "foo";
float c = 3.14;

dump!(a, b, c)(); // a = 42, b = foo, c = 3.14
stdout.dump!(a, b, c)(" | "); // a = 42 | b = foo | c = 3.14
}

---

I'm not a fan of non-trivial string mixins except in extenuating 
circumstances. I tried compressing it to a single call to `write` 
like your `print` except using staticMap, but like I often do I 
ran into "template instance foo cannot use local 'bar' as 
parameter to non-global template baz" errors.

Re: Just because it's a slow Thursday on this forum

[ixid via Digitalmars-d]

On Tuesday, 9 February 2016 at 12:46:34 UTC, Jakob Ovrum wrote:
I'm not a fan of non-trivial string mixins except in 
extenuating circumstances.


This is something Steven Schveighoffer commented on in these 
discussions as well. As this is a fundamental D feature and it's 
currently rather clunky and hard to use it would suggest this 
needs improvement. What should be done with it if anything and 
with what methods?

Re: std.concurrency: ownerTid vs thisTid

[Ali Çehreli via Digitalmars-d-learn]

On 02/09/2016 07:52 AM, Daniel Kozak via Digitalmars-d-learn wrote:

It is OK, I guess the output is just mixed


Yes, that's an important point but it is not the reason. (Just tested.)

I think this is just an issue with how Tid objects are printed. 
Otherwise, everything works as expected and although they print the same 
value, "worker1 != worker2" is true as well.


Ali

Re: std.concurrency: ownerTid vs thisTid

[Daniel Kozak via Digitalmars-d-learn]

OK it seems wierd

On Tue, Feb 9, 2016 at 4:52 PM, Daniel Kozak  wrote:

> It is OK, I guess the output is just mixed
>
> On Tue, Feb 9, 2016 at 4:35 PM, miazo via Digitalmars-d-learn <
> digitalmars-d-learn@puremagic.com> wrote:
>
>> Hi,
>>
>> The following simple program:
>>
>> import std.stdio, std.concurrency;
>>
>> void f1() {
>> writeln("owner: ", ownerTid);
>> writeln("worker: ", thisTid);
>> }
>>
>> void main() {
>> writeln("owner: ", thisTid);
>> writeln("worker: ", spawn());
>> }
>>
>> Gives me the following result:
>>
>> owner: Tid(18fd58)
>> worker: Tid(18fd58)
>> owner: Tid(24afe38)
>> worker: Tid(24afe38)
>>
>> Is it correct? My expectation was that:
>> - thisTid called from main will be the same as ownerTid called from f1
>> - thisTid called from f1 will be the same as value returned by spawn()
>>
>> Thank you for your help.
>>
>>
>

Re: Just because it's a slow Thursday on this forum

[Nick Sabalausky via Digitalmars-d]

On 02/08/2016 02:15 PM, Nick Sabalausky wrote:


I'd wanted to do a non-mixin version, but that hasn't been possible.


Well, wasn't possible at the time, anyway.

Re: std.concurrency: ownerTid vs thisTid

[miazo via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 15:55:34 UTC, Ali Çehreli wrote:
On 02/09/2016 07:52 AM, Daniel Kozak via Digitalmars-d-learn 
wrote:

It is OK, I guess the output is just mixed


Yes, that's an important point but it is not the reason. (Just 
tested.)


I think this is just an issue with how Tid objects are printed. 
Otherwise, everything works as expected and although they print 
the same value, "worker1 != worker2" is true as well.


Ali


Well, I'm not concerned about the order of the output but the 
actual values of these ids. Shouldn't it be rather:


owner: Tid(18fd58)
worker: Tid(24afe38)
owner: Tid(18fd58)
worker: Tid(24afe38)

or

owner: Tid(24afe38)
worker: Tid(18fd58)
owner: Tid(24afe38)
worker: Tid(18fd58)

?

std.concurrency: ownerTid vs thisTid

[miazo via Digitalmars-d-learn]

Hi,

The following simple program:

import std.stdio, std.concurrency;

void f1() {
writeln("owner: ", ownerTid);
writeln("worker: ", thisTid);
}

void main() {
writeln("owner: ", thisTid);
writeln("worker: ", spawn());
}

Gives me the following result:

owner: Tid(18fd58)
worker: Tid(18fd58)
owner: Tid(24afe38)
worker: Tid(24afe38)

Is it correct? My expectation was that:
- thisTid called from main will be the same as ownerTid called 
from f1
- thisTid called from f1 will be the same as value returned by 
spawn()


Thank you for your help.

Re: std.concurrency: ownerTid vs thisTid

[Daniel Kozak via Digitalmars-d-learn]

https://github.com/D-Programming-Language/phobos/blob/v2.070.0/std/concurrency.d#L340

formattedWrite(sink, "Tid(%x)", );

should be:

formattedWrite(sink, "Tid(%x)", cast(void *)mbox);

On Tue, Feb 9, 2016 at 5:25 PM, Daniel Kozak  wrote:
> You are right:
> import std.stdio, std.concurrency;
> import std.concurrency : MessageBox;
>
> struct MyTid
> {
> MessageBox mbox;
> }
>
> static void f1() {
> auto tT = cast(MyTid)thisTid;
> auto oT = cast(MyTid)ownerTid;
> writeln("F1:worker: ", cast(void*)tT.mbox);
> writeln("F1:owner: ", cast(void*)oT.mbox);
> }
>
> void main() {
> auto tT = cast(MyTid)thisTid();
> auto sT = cast(MyTid)spawn();
> writeln("Main:worker: ", cast(void *)sT.mbox);
> writeln("Main:owner: ", cast(void *)tT.mbox);
> }
>
>
> On Tue, Feb 9, 2016 at 4:55 PM, Ali Çehreli
>  wrote:
>>
>> On 02/09/2016 07:52 AM, Daniel Kozak via Digitalmars-d-learn wrote:
>>>
>>> It is OK, I guess the output is just mixed
>>
>>
>> Yes, that's an important point but it is not the reason. (Just tested.)
>>
>> I think this is just an issue with how Tid objects are printed. Otherwise,
>> everything works as expected and although they print the same value,
>> "worker1 != worker2" is true as well.
>>
>> Ali
>>
>

Re: std.concurrency: ownerTid vs thisTid

[Daniel Kozak via Digitalmars-d-learn]

It is OK, I guess the output is just mixed

On Tue, Feb 9, 2016 at 4:35 PM, miazo via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:

> Hi,
>
> The following simple program:
>
> import std.stdio, std.concurrency;
>
> void f1() {
> writeln("owner: ", ownerTid);
> writeln("worker: ", thisTid);
> }
>
> void main() {
> writeln("owner: ", thisTid);
> writeln("worker: ", spawn());
> }
>
> Gives me the following result:
>
> owner: Tid(18fd58)
> worker: Tid(18fd58)
> owner: Tid(24afe38)
> worker: Tid(24afe38)
>
> Is it correct? My expectation was that:
> - thisTid called from main will be the same as ownerTid called from f1
> - thisTid called from f1 will be the same as value returned by spawn()
>
> Thank you for your help.
>
>

Re: Is this a bug in std.typecons.Tuple.slice?

[Marc Schütz via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 14:28:35 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 9 February 2016 at 13:43:16 UTC, Marc Schütz wrote:
So what? Using that argument, you could just as well forbid 
taking the address of any variable. What's so special about 
tuples, in contrast to structs and arrays?


Some key common qualities for a tuple:

1. They are primarily used for multiple return values from 
functions.


As you said, primarily. There's no reason not to use them for 
something else.




2. Tuples use structural typing, not nominal typing.


This has no relevance for the question at hand.



3. They are identity-less. If you can take reference and 
compare, they no longer are identity-less.




Like value types in general, nothing special about tuples here.



Tuples should be considered immutable constants (think 
functional programming), not in-memory storage.


Again, why?


Because that is how a tuple is commonly defined, for 
performance and semantic reasons.


I believe it's more because the concept is more frequently used 
in functional programming languages, for which immutability is 
not surprising. Other languages do have mutable tuples, e.g. 
Swift and C++11 (std::tuple).






Tuple's can serve as a good approximation to SIMD registers.


What relation does that have to the above?


You don't want to spill out SIMD registers to the stack if you 
can avoid it. You want to do the changes within the CPU 
pipeline, i.e. using copies (and register renaming).


As said above, wanting to avoid spilling is not a reason to 
disallow spilling. Besides, fixed-size arrays seem more similar 
to SIMD registers, and they don't have the restrictions you 
tuples to have.

Re: std.concurrency: ownerTid vs thisTid

[Daniel Kozak via Digitalmars-d-learn]

You are right:
import std.stdio, std.concurrency;
import std.concurrency : MessageBox;

struct MyTid
{
MessageBox mbox;
}

static void f1() {
auto tT = cast(MyTid)thisTid;
auto oT = cast(MyTid)ownerTid;
writeln("F1:worker: ", cast(void*)tT.mbox);
writeln("F1:owner: ", cast(void*)oT.mbox);
}

void main() {
auto tT = cast(MyTid)thisTid();
auto sT = cast(MyTid)spawn();
writeln("Main:worker: ", cast(void *)sT.mbox);
writeln("Main:owner: ", cast(void *)tT.mbox);
}


On Tue, Feb 9, 2016 at 4:55 PM, Ali Çehreli <
digitalmars-d-learn@puremagic.com> wrote:

> On 02/09/2016 07:52 AM, Daniel Kozak via Digitalmars-d-learn wrote:
>
>> It is OK, I guess the output is just mixed
>>
>
> Yes, that's an important point but it is not the reason. (Just tested.)
>
> I think this is just an issue with how Tid objects are printed. Otherwise,
> everything works as expected and although they print the same value,
> "worker1 != worker2" is true as well.
>
> Ali
>
>

[Issue 15660] breack "immutable" with pure function and mutable params

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 CC||schvei...@yahoo.com
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #2 from Steven Schveighoffer  ---
This doesn't require member functions.

int[] f(ref void[] m) pure
{
auto result = new int[5];
m = result;
return result;
}

void main()
{
void[] v;
immutable x = f(v);
}

One significant problem here is that the compiler may not consider the
parameter to f in these cases to be a *return* avenue, only a parameter. The
compiler should take into account references to ensure that they cannot escape
the same data that is being returned.

Fixing this may break a lot of code, but probably for the better. May need a
deprecation cycle for this.

--

Re: Printing a C "string" with write(f)ln

[Daniel Kozak via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 16:58:03 UTC, Daniel Kozak wrote:
On Tuesday, 9 February 2016 at 16:52:09 UTC, Gary Willoughby 
wrote:

On Tuesday, 9 February 2016 at 12:50:27 UTC, Jakob Ovrum wrote:
writefln et al sensibly does *not* assume that a pointer to 
char is a C string, for memory safety purposes.


Print the result of std.string.fromStringz[1] instead:

writeln(fromStringz(pString));
writefln("%s", fromStringz(pString));

[1] http://dlang.org/phobos/std_string#fromStringz


Or use `to` like this:

import std.conv;
writefln("%s", pString.to!(string));


this will allocate new string which can be performance problem.
Maybe:

writefln("%s", pString.to!(char[]));

But I do not know if this works and does not allocate


void main() {
char[] chars = cast(char[])"Ahoj svete";

char* cstr = chars.ptr;
auto s1 = to!string(cstr);
auto s2 = to!(char[])(cstr);
auto s3 = fromStringz(cstr);

writeln(cstr);   //46D310
writeln(s1.ptr); //7F0062EF1000
writeln(s2.ptr); //7F0062EF1010
writeln(s3.ptr); //46D310
}

[Issue 15662] Cannot move struct with defined opAssign due to @disabled post-blit

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #2 from Steven Schveighoffer  ---
we should create a moveAppend function that allows this (would destroy old
elements if they have to be moved).

--

[Issue 15660] break "immutable" with pure function and mutable reference params

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

Summary|breack "immutable" with |break "immutable" with pure
   |pure function and mutable   |function and mutable
   |params  |reference params

--

Re: Printing a C "string" with write(f)ln

[Daniel Kozak via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 16:52:09 UTC, Gary Willoughby 
wrote:

On Tuesday, 9 February 2016 at 12:50:27 UTC, Jakob Ovrum wrote:
writefln et al sensibly does *not* assume that a pointer to 
char is a C string, for memory safety purposes.


Print the result of std.string.fromStringz[1] instead:

writeln(fromStringz(pString));
writefln("%s", fromStringz(pString));

[1] http://dlang.org/phobos/std_string#fromStringz


Or use `to` like this:

import std.conv;
writefln("%s", pString.to!(string));


this will allocate new string which can be performance problem.
Maybe:

writefln("%s", pString.to!(char[]));

But I do not know if this works and does not allocate

Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library

[earthfront via Digitalmars-d-announce]

On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote:

What's new:


Enjoy!

Atila


Thanks! What is the relevant link?

Re: Safe cast away from immutable

[Steven Schveighoffer via Digitalmars-d]

On 2/8/16 4:48 PM, Jonathan M Davis wrote:


One of the most useful things that the compiler can do if a function is
pure is that if it can guarantee that the return value did not get
passed in as an argument or was otherwise obtained via an argument, then
it knows that the argument was created within the function and that
therefore the return value is the only reference to that data, and so
it's safe to alter its mutability - e.g. change a mutable array to an
immutable one. Exactly which conditions under which that can be
determined to be safe are not exactly straightforward. The simplest is
when all of the arguments were immutable, but there are others, some of
which are much more complicated (and under some circumstances, const can
help with that, whereas in others, it can't - it really depends on the
types involved). I don't know how sophisticated the compiler is in
determining that right now, but clearly, what it currently has is buggy,
because it failed to take the invisible this pointer/reference into
account in your example and thus incorrectly determined that it was not
possible for another reference to the same data to exist after the
function returned.


I'm not so sure. I think there is something we never considered, and the 
compiler might be more clever than it should be.


I tested this out:

int[] f(ref void[] m) pure
{
auto result = new int[5];
m = result;
return result;
}

void main()
{
void[] v;
immutable x = f(v);
}

Compiles.

I think the rules at the moment are that the compiler allows implicit 
conversion if the return value could not have come from any of the 
parameters. But what it may not consider is if the parameters could be 
return values themselves via a reference!


What I think is happening is that the compiler is saying "Well, there is 
no way that int[] could come from m (without a cast), so I'm going to 
assume it's unique". However, we can see it's not. m actually is 
generated from it!


I'll amend the bug.

-Steve

Re: Printing a C "string" with write(f)ln

[Gary Willoughby via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 12:50:27 UTC, Jakob Ovrum wrote:
writefln et al sensibly does *not* assume that a pointer to 
char is a C string, for memory safety purposes.


Print the result of std.string.fromStringz[1] instead:

writeln(fromStringz(pString));
writefln("%s", fromStringz(pString));

[1] http://dlang.org/phobos/std_string#fromStringz


Or use `to` like this:

import std.conv;
writefln("%s", pString.to!(string));

Re: Printing a C "string" with write(f)ln

[Jakob Ovrum via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 16:52:09 UTC, Gary Willoughby 
wrote:

On Tuesday, 9 February 2016 at 12:50:27 UTC, Jakob Ovrum wrote:
writefln et al sensibly does *not* assume that a pointer to 
char is a C string, for memory safety purposes.


Print the result of std.string.fromStringz[1] instead:

writeln(fromStringz(pString));
writefln("%s", fromStringz(pString));

[1] http://dlang.org/phobos/std_string#fromStringz


Or use `to` like this:

import std.conv;
writefln("%s", pString.to!(string));


to!string behaving like that was a poor design choice[1]. Please 
use fromStringz.


[1] https://github.com/D-Programming-Language/phobos/pull/1607

Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library

[earthfront via Digitalmars-d-announce]

On Tuesday, 9 February 2016 at 17:07:15 UTC, earthfront wrote:

On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote:

What's new:


Enjoy!

Atila


Thanks! What is the relevant link?


First link on DuckGo: https://github.com/atilaneves/unit-threaded

[Issue 15660] break "immutable" with pure function and mutable reference params

[via Digitalmars-d-bugs]

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

--- Comment #5 from Iakh  ---
(In reply to Steven Schveighoffer from comment #4)

> In this case, you are using a cast. The compiler pretty much gives up trying
> to ensure anything when you cast, so I think it's OK to allow that.
> 
> Although, I thought such a cast wouldn't work in @safe code.

Me too. Casting of array types does in reinterpret_cast manner. So it's a
bug in @safe definition.

--

Re: why mkdir can't create tree of dirs?

[anonymous via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 20:20:59 UTC, Suliman wrote:
It's look like that I can only create one nesting level sub 
folder, for example there is exists dir: D:\foo

I can't create dir D:\foo\bar\baz I can only create D:\foo\bar


http://dlang.org/phobos/std_file.html#.mkdirRecurse


td.windows.syserror.WindowsException@C:\D\dmd2\windows\bin\..\..\src\phobos\stdfile.d(2048):
 F:\foo\imgs_projected\jma_vis\1602\123: ╨б╨╕╤Б╤В╨╡╨╝╨╡ ╨╜╨╡ ╤Г╨┤╨╨╡╤В╤Б╤П 
╨╜╨░╨╣╤В╨╕ ╤Г╨║╨░╨╖╨░╨╜╨╜╤Л╨╣ ╨┐╤Г╤В╤М. (error 3)


What's up with that garbled text?

code-debug 0.3.0 released (GDB for vscode)

[WebFreak001 via Digitalmars-d-announce]

I recently started with a GDB extension for debugging D code in 
visual studio code and now its in a pretty ready state supporting 
most things GDB can do, covering nearly everything the vscode UI 
allows me to do. It supports debugging, attaching to processes & 
gdbserver and debugging over SSH + X11 forwarding.


I've used it quite a lot now and it works great with D on linux. 
I will add more debuggers in the future (also lldb and others 
that support MI command syntax).


If you have visual studio code, just run `ext install debug` and 
follow the instructions in the README


Source code for those of you who are interested: 
https://github.com/WebFreak001/code-debug

Re: Printing a C "string" with write(f)ln

[Gary Willoughby via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 16:58:03 UTC, Daniel Kozak wrote:

Or use `to` like this:

import std.conv;
writefln("%s", pString.to!(string));


this will allocate new string which can be performance problem.


Which is good in most cases. It's better to have the GC take care 
of the D string instead of worrying about the lifetime of pString.

algorithm's .filter!() by range key

[Charles via Digitalmars-d-learn]

This seems to be true of any range function really... is there a 
way to access the key within my range?


Example of what I want to do:

auto x = [1,2,3,4,5];
x.filter( x_key % 2 == 1 ).sum(); // sum odd elements in array

UFCS on Enum in Member Function

[jmh530 via Digitalmars-d-learn]

I have been working with some C error codes that are organized in 
an enum. I noticed that if I tried to write a function that 
processes these error codes within a struct, then I could not use 
a UFCS-style call.


For instance, in the code below, I could use Baz but not Caz. It 
seems to work when I use the alternate version of Caz calling a 
non-member function.


Bug?


enum X
{
A = 1,
}

struct Foo
{
X Bar(X x)
{
return x;
}

X Baz()
{
auto result = X.A;
return Bar(result);
}

/*
X Caz()
{
auto result = X.A;
return result.Bar();
}
*/

X Caz_alt()
{
auto result = X.A;
return result.Bar_alt();
}
}

X Bar_alt(X x)
{
return x;
}

void main()
{
auto foo = Foo();
auto result = foo.Baz();
//auto result2 = foo.Caz();
auto result3 = foo.Caz_alt();
}

Re: Sublime Text 3 Gets Better D Support

[TheGag96 via Digitalmars-d-announce]

Just got the new update, and when I reloaded my files, any source 
code inside a class has every variable name and all punctuation 
colored according to my theme: http://i.imgur.com/RxqTqoP.png


If I'm remembering right Java files look like the right half of 
the image as well, though I'm not sure what parameter in my theme 
I'm supposed to change to make this go back to what it was 
before, though... As it is it's a little eye-searing. Is this 
just a result of Sublime parsing D better now?

Re: UFCS on Enum in Member Function

[anonymous via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 21:05:50 UTC, jmh530 wrote:
For instance, in the code below, I could use Baz but not Caz. 
It seems to work when I use the alternate version of Caz 
calling a non-member function.


Bug?


No bug; works as intended. UFCS can only be used with free 
functions, not with methods.

Offering Access to Parser

[cy via Digitalmars-d]

I know macros are an unpopular subject in D, but I think there's 
a way to get mostly equivalent capabilities to macros, without 
changing the language at all, simply by standardizing access to 
the compiler's own D language parser.


There are already 10 separate parsers for D here:
http://wiki.dlang.org/Lexers_Parsers

All these parsers are pretty much written from scratch (one even 
forked from dmd itself) and they all do pretty much the same 
thing: take a string of code, and turn it into an AST. Turning 
that AST back into valid D code is itself a rather difficult and 
error prone process, but if you could, then you could simply do 
something like:


import some.parser;
string foo(string bar) = 
unparse(IfDeclaration(parse(bar),parse(q{writeln("yay")}),parse(q{writeln("boo")}));


void main() {
  mixin foo!"true";
  mixin foo!"false";
}

D isn't a particularly hard to parse language, so it's not too 
hard to implement these parsers, but they're definitely 
reinventing the wheel, and there's no assurance that future 
language features won't break them. But within each D compiler 
(I'm pretty sure?) there is already a parser, that produces (and 
manipulates) an AST. For DMD, the parser is written in D itself! 
Using it would (in theory) be as simple as copying all the ddmd 
modules into your source directory and importing ddmd.parse. 
Eliminating the need to maintain all those third party parsers is 
as simple as having the compiler itself provide the parser as a 
module.


There is additionally a huge advantage to code being able to use 
the compiler's D parser, that third party parsers cannot match. 
The D compiler actually uses the AST generated by its parser. 
With the other parsers, you have to somehow figure out how to 
"unparse" their AST into an opaque string of D code, before you 
can supply that new code as a mixin, but if you used the 
compiler's own parser, it could accept an AST as a mixin omitting 
the "parse" step it normally does on mixins.


So the above would end up more like:

import std.parser;
AST foo(string bar) = IfDeclaration(parse(bar), 
parse(q{writeln("yay")}), parse(q{writeln("boo")}));



void main() {
  mixin foo!"true";
  mixin foo!"false";
}

omitting the complicated and error prone "unparse()" step 
entirely, not to mention removing the degradation in compilation 
speed if you have to unparse, and then re-parse an AST.


I'm not sure if it would be possible to have the parser available 
at runtime, but it seems like you could compile it into the 
program just like any other module.

Re: algorithm's .filter!() by range key

[Charles via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 20:44:34 UTC, cym13 wrote:

On Tuesday, 9 February 2016 at 20:40:44 UTC, Charles wrote:
This seems to be true of any range function really... is there 
a way to access the key within my range?


Example of what I want to do:

auto x = [1,2,3,4,5];
x.filter( x_key % 2 == 1 ).sum(); // sum odd elements in array


x.filter!(x_key => x_key % 2 == 1).sum();


Oh man, I really messed up my example, and did a poor one at that.

Better example:

auto x = [2,4,6,8,10];
x.filter( x_key => x_key % 2 == 1 ).sum(); // sums 2 + 6 + 10 == 
18

Safe cast of arrays

[Iakh via Digitalmars-d]

https://dlang.org/spec/function.html#function-safety
Current definition of safety doesn't mention cast of arrays.
E.g this code allowed by DMD

int[] f(void[] a) @safe pure
{
return cast(int[])a;
}

But same void* to int* cast is forbidden.
So we need some rules for dynamic arrays casting.
e.g allow only cast(void[]) as for pointers was done.

And definition of safety should be changed.

Re: Proposal: Database Engine for D

[Zardoz via Digitalmars-d]

On Monday, 8 February 2016 at 13:36:09 UTC, Mengu wrote:


i don't mind if it's an ORM or something else. my point was 
that instead of complaining about stuff, we need a safe, stable 
and extendable database library supporting sqlite, mysql, 
postgresql, mssql and oracle dbs and we need it like yesterday. 
nothing fancy. people can get creative and fancy over that 
standard api and users get to choose.


Something like JDBC on D ... --> 
https://code.dlang.org/packages/ddbc

Re: why mkdir can't create tree of dirs?

[Wyatt via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 20:20:59 UTC, Suliman wrote:
It's look like that I can only create one nesting level sub 
folder, for example there is exists dir: D:\foo

I can't create dir D:\foo\bar\baz I can only create D:\foo\bar


http://dlang.org/phobos/std_file.html#.mkdirRecurse

-Wyatt

Re: Support for D in VSCode

[WebFreak001 via Digitalmars-d]

On Tuesday, 9 February 2016 at 22:06:37 UTC, bitwise wrote:

After receiving 1000+ votes on Visual Studio User Voice
[1], Microsoft has added D to their Wiki for requested VSCode 
extensions[2]. I'm not sure if support was initially available 
for adding custom extensions to VSCode, but it seems to be 
now[3]. I've been using VSCode for a couple of months now(C#) 
and it seems pretty good. I'm not sure how soon Microsoft will 
actually get around to implementing a D extension, but it 
doesn't seem like it would be very difficult to create one for 
someone who already has experience with this sort of thing[4].



[1] 
http://visualstudio.uservoice.com/forums/293070-visual-studio-code/suggestions/7763160-support-the-d-programming-language
[2] 
https://github.com/Microsoft/vscode/wiki/Requested-Extensions

[3] https://code.visualstudio.com/Docs/extensions/overview
[4] https://code.visualstudio.com/Docs/customization/colorizer

Bit


Sounds awesome for the community! But for me this will probably 
be a real downside as we put so much work into our vscode 
extension already.


In case someone didn't know: me and Wild made a D extension for 
vscode supporting dub (build, run, linting) + dub.json 
completion, dfmt, dscanner, dcd, DlangUI Markup Language syntax + 
auto complete, SDL syntax, arsd.script syntax, jade syntax, 
upload to dpaste and D snippets: https://github.com/Pure-D/code-d

Re: algorithm's .filter!() by range key

[Charles via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 20:48:01 UTC, Steven Schveighoffer 
wrote:

On 2/9/16 3:40 PM, Charles wrote:
This seems to be true of any range function really... is there 
a way to

access the key within my range?

Example of what I want to do:

auto x = [1,2,3,4,5];
x.filter( x_key % 2 == 1 ).sum(); // sum odd elements in array


An array is not an indexed range. It only works with foreach by 
key because of special foreach behavior.


What you want is std.range.enumerate



Exactly! Thanks!

Interestingly, hackerrank doesn't seem to have it. They're using 
2.067.0-b1 on Ubuntu 14.04.

Re: Sublime Text 3 Gets Better D Support

[Brian Schott via Digitalmars-d-announce]

On Wednesday, 27 January 2016 at 17:34:35 UTC, Jack Stouffer 
wrote:
Sublime Text is a very popular text editor, and for a while now 
it's had marginal D support. What has changed recently is 
updated syntax highlighting to support all the new keywords 
that have come in the last couple of years and UDAs 
https://github.com/sublimehq/Packages/commit/b9026cf6ab8ccd05e3704d21b2d5d5cc21450aca.


Syntax highlighting was mostly based on D1 before, but now it 
supports every thing to pure and nothrow to correctly 
highlighting number literals with underscores.


In order to use this, you can either wait until a version of 
sublime is released with these changes, or you can download the 
dev version here https://www.sublimetext.com/3dev, and then 
install the new packages as described here 
https://github.com/sublimehq/Packages#installation.


Bumping this thread because these new features are no longer in 
beta: build 3103 is out.


https://www.sublimetext.com/3

Support for D in VSCode

[bitwise via Digitalmars-d]

After receiving 1000+ votes on Visual Studio User Voice
[1], Microsoft has added D to their Wiki for requested VSCode 
extensions[2]. I'm not sure if support was initially available 
for adding custom extensions to VSCode, but it seems to be 
now[3]. I've been using VSCode for a couple of months now(C#) and 
it seems pretty good. I'm not sure how soon Microsoft will 
actually get around to implementing a D extension, but it doesn't 
seem like it would be very difficult to create one for someone 
who already has experience with this sort of thing[4].



[1] 
http://visualstudio.uservoice.com/forums/293070-visual-studio-code/suggestions/7763160-support-the-d-programming-language

[2] https://github.com/Microsoft/vscode/wiki/Requested-Extensions
[3] https://code.visualstudio.com/Docs/extensions/overview
[4] https://code.visualstudio.com/Docs/customization/colorizer

Bit

Re: Printing a C "string" with write(f)ln

[Gary Willoughby via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 17:02:28 UTC, Jakob Ovrum wrote:
to!string behaving like that was a poor design choice[1]. 
Please use fromStringz.


[1] https://github.com/D-Programming-Language/phobos/pull/1607


It's not a poor design choice. It ensures the string is handled 
by the D GC instead of the C side freeing it. `fromStringz` and 
`to!(String)` are for different cases.

Re: algorithm's .filter!() by range key

[cym13 via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 20:40:44 UTC, Charles wrote:
This seems to be true of any range function really... is there 
a way to access the key within my range?


Example of what I want to do:

auto x = [1,2,3,4,5];
x.filter( x_key % 2 == 1 ).sum(); // sum odd elements in array


x.filter!(x_key => x_key % 2 == 1).sum();

Visual studio official d support

[Steven Schveighoffer via Digitalmars-d]

A while ago there was a movement to get d included officially in 
visual studio. Just got this email:


 An idea you supported has been closed. Thank you for your 
feedback.


Message:
This is a great candidate for a language service extension. Moved 
to newly created wiki for requested extensions.


https://github.com/Microsoft/vscode/wiki/Requested-Extensions

Re: Release vibe.d 0.7.27

[Dicebot via Digitalmars-d-announce]

On 02/09/2016 09:16 PM, Sönke Ludwig wrote:
> This release brings some larger changes:
> 
> ...

Changelog looks very exciting, good work!

[Issue 1448] UTF-8 output to console is seriously broken

[via Digitalmars-d-bugs]

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

--- Comment #13 from Martin Krejcirik  ---
Final note, as this is unlikely to be fixed: use -m32mscoff and Microsoft VS
linker.

--

uefi-d: Booting to D

[Jakub Szewczyk via Digitalmars-d-announce]

I have started developing a hobbyist OS, I decided I want it to 
be written in D, but the only possibility to write code that can 
be ran by the UEFI chips that replaced BIOS in modern computers 
was to use either assembler or C. (For example: 
http://wiki.osdev.org/UEFI or 
http://wiki.osdev.org/UEFI_Bare_Bones) That's why I'm working on 
creating a D binding for the UEFI specifications (official SDK is 
at http://www.tianocore.org/), right now the project is in the 
stage, where it can be used for real applications, but only the 
most important headers have corresponding modules, I'm gradually 
porting more and more parts of the SDK to D.
I have included a sample, working, hello world application with a 
build script that works on x86-64-bit linux in the project. I 
don't have the time and resources to extensively test the 
correctness of these bindings, so if anyone else is interested in 
UEFI programming, I'm willing to cooperate :-).


Github link: https://github.com/kubasz/uefi-d

Code.dlang.org project: http://code.dlang.org/packages/uefi-d

Proof of this working on real hardware: 
https://raw.githubusercontent.com/kubasz/uefi-d/ded021fe036eccdf2ae377bc75df057e76c90198/sample/photo.jpg


Useful wiki with a good documentation of the API: 
http://wiki.phoenix.com/wiki/index.php/Category:UEFI_2.0

Re: Just because it's a slow Thursday on this forum

[Andrei Alexandrescu via Digitalmars-d]

On 02/09/2016 10:34 AM, ixid wrote:

On Tuesday, 9 February 2016 at 12:46:34 UTC, Jakob Ovrum wrote:

I'm not a fan of non-trivial string mixins except in extenuating
circumstances.


This is something Steven Schveighoffer commented on in these discussions
as well. As this is a fundamental D feature and it's currently rather
clunky and hard to use it would suggest this needs improvement. What
should be done with it if anything and with what methods?


An alternate solution is liable to be too clever for its own good. 
Everybody and their cat understands string concatenation. What we need 
here is better tactical tools, e.g. a simple string 
template/interpolation engine. -- Andrei

Re: D's equivalent to C++'s std::move?

[Andrei Alexandrescu via Digitalmars-d]

On 2/8/16 7:25 PM, Matt Elkins wrote:

On Thursday, 4 February 2016 at 02:33:06 UTC, Andrei Alexandrescu wrote:

Got it, thanks. That's a bug in the implementation, no two ways about
it. No copy should occur there, neither theoretically nor practically.
Please report it to bugzilla at http://issues.dlang.org. Thanks very
much! -- Andrei


Done (sorry for the delay): https://issues.dlang.org/show_bug.cgi?id=15662


Thx! -- Andrei

Re: dpaste and the wayback machine

[Andrei Alexandrescu via Digitalmars-d]

On 2/8/16 11:44 AM, Wyatt wrote:

On Sunday, 7 February 2016 at 21:59:00 UTC, Andrei Alexandrescu
wrote:

Dpaste currently does not expire pastes by default. I was thinking
it would be nice if it saved them in the Wayback Machine such that
they are archived redundantly.

I'm not sure what's the way to do it - probably linking the
newly-generated paste URLs from a page that the Wayback Machine
already knows of.

I just saved this by hand: http://dpaste.dzfl.pl/2012caf872ec (when
 the WM does not see a link that is search for, it offers the
option to archive it) obtaining
https://web.archive.org/web/20160207215546/http://dpaste.dzfl.pl/2012caf872ec.




Thoughts?


You want it in Wayback?  Sounds like you need some WARC [0]. Since
anyone can upload to IA (using a nice S3-like API, even [1]), this
should be pretty uncomplicated.  If you can get a list of all the
paste URLs, you can use wget [2] to build the WARC fairly trivially.
[3]  Then I'd suggest getting a dlang account and make an item [4]
out of it. Just make sure it's set to mediatype:web and it should get
ingested by Wayback.

After that?  Generate a WARC when a paste is made and use the dlang
S3 keys to add it to the previous item (or maybe just do it daily or
weekly so as to not stress the derive queue too much). I'm pretty
sure that's all that's needed.


That's intense. I think a simple page (or chained linked collection of
pages) containing links to all pastes defined would suffice. For example
consider defining dpaste.dzfl.pl containing a link to
dpaste.dzfl.pl/today.html. That would contain e.g. the links generated
today and a button "More" linked to dpaste.dzfl.pl/2016-02-08.html
(which would be yesterday). That in turn would contain links to
yesterday's pastes and a link to the day before etc.

My understanding is this is enough to have wayback archive all pastes.


I'm pretty sure that's Andrei's thought, too. It's a pastebin; people
use it to make web links to pasted things. If it were to disappear, a
lot of links would break very permanently because Heritrix has no way
to index and crawl the site.


Yah.


Andrei

Poodinis (DI framework) 6.1.0 released

[Mike Bierlee via Digitalmars-d-announce]

Poodinis 6.1.0 has been released!

Poodinis is a dependency injection framework for the D 
programming language. It is heavily inspired by the Spring 
Framework.


Most notable in this release is the ability to autowire private 
and protected members. Now you can have proper encapsulation 
again.


Thanks to Extrawurst for implementing this!

(Other) notable changes in this release:
- Added ability to register a type while resolving it.
- Added ability to autowire private fields (Thanks to Extrawurst).
- Fixed registration of application contexts with non-public 
members

More can be found in the changelog.

You can find the project at:
Github: https://github.com/mbierlee/poodinis
D package registry: http://code.dlang.org/packages/poodinis

Re: Support for D in VSCode

[bitwise via Digitalmars-d]

On Tuesday, 9 February 2016 at 23:27:08 UTC, WebFreak001 wrote:

On Tuesday, 9 February 2016 at 23:17:48 UTC, bitwise wrote:

You can add it here if you want:
http://wiki.dlang.org/IDEs


Its already on http://wiki.dlang.org/List_of_Text_editors

Also, can you create an install-wizard or zip/package with the 
extension and all dependencies? I don't really have time to 
figure out how to install everything separately.


Good idea, would make everything easier


Awesome. Can't wait to try it out!

It would be nice to have an editor that could deal with DMD 
properly(half C++, half D). I don't expect to be able to jump 
between symbols in different languages, but at least use "Go To 
Definition" for one language at a time, in the same editor. That 
would be awesome.


Bit

Re: Visual studio official d support

[bitwise via Digitalmars-d]

On Tuesday, 9 February 2016 at 22:11:12 UTC, Steven Schveighoffer 
wrote:
A while ago there was a movement to get d included officially 
in visual studio. Just got this email:


 An idea you supported has been closed. Thank you for your 
feedback.


Message:
This is a great candidate for a language service extension. 
Moved to newly created wiki for requested extensions.


https://github.com/Microsoft/vscode/wiki/Requested-Extensions


http://forum.dlang.org/thread/rfixfspmybtolmzhr...@forum.dlang.org =)

   Bit

[Issue 15662] Cannot move struct with defined opAssign due to @disabled post-blit

[via Digitalmars-d-bugs]

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

Dicebot  changed:

   What|Removed |Added

 CC||pub...@dicebot.lv

--- Comment #3 from Dicebot  ---
(In reply to Steven Schveighoffer from comment #2)
> we should create a moveAppend function that allows this (would destroy old
> elements if they have to be moved).

This seems quite fitting for a `Buffer` concept which we are switching to from
built-in arrays to keep D1 array stomping behavior (effectively a wrapper over
array which owns that array and calls `assumeSafeAppend` each time length is
changed).

--

Re: D's equivalent to C++'s std::move?

[Matt Elkins via Digitalmars-d]

On Tuesday, 9 February 2016 at 13:45:13 UTC, Hara Kenji wrote:

On Tuesday, 9 February 2016 at 00:25:33 UTC, Matt Elkins wrote:
On Thursday, 4 February 2016 at 02:33:06 UTC, Andrei 
Alexandrescu wrote:
Got it, thanks. That's a bug in the implementation, no two 
ways about it. No copy should occur there, neither 
theoretically nor practically. Please report it to bugzilla 
at http://issues.dlang.org. Thanks very much! -- Andrei


Done (sorry for the delay): 
https://issues.dlang.org/show_bug.cgi?id=15662


I've replied to issue 15662.

The point of that issue is, an array concatenation or appending 
may cause the elements' copy.
The copy occurrence is determined by the runtime situation, so 
compiler needs to reject such the operation for the @disable 
this(this) elements conservatively.


Kenji Hara


I see. Unfortunate. But thanks for the explanation!

Re: Release vibe.d 0.7.27

[Andrei Alexandrescu via Digitalmars-d-announce]

On 2/9/16 2:16 PM, Sönke Ludwig wrote:

  - Full list of changes: http://vibed.org/blog/posts/vibe-release-0.7.27

Homepage: http://vibed.org/
DUB package: http://code.dlang.org/packages/vibe-d
GitHub: https://github.com/rejectedsoftware/vibe.d


Congrats!! -- Andrei

[Issue 15666] New: Grammar does not allow member function attributes on static constructors

[via Digitalmars-d-bugs]

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

  Issue ID: 15666
   Summary: Grammar does not allow member function attributes on
static constructors
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/spec/grammar.html
OS: All
Status: NEW
  Keywords: spec
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: briancsch...@gmail.com
Blocks: 10233

StaticConstructor:
static this ( ) ;
static this ( ) FunctionBody

StaticDestructor:
static ~ this ( ) MemberFunctionAttributesopt ;
static ~ this ( ) MemberFunctionAttributesopt FunctionBody

SharedStaticConstructor:
shared static this ( ) ;
shared static this ( ) FunctionBody

SharedStaticDestructor:
shared static ~ this ( ) MemberFunctionAttributesopt ;
shared static ~ this ( ) MemberFunctionAttributesopt FunctionBody

According to the grammar static and shared static destructors can have
attributes, but constructors cannot.

The compiler, as well as the contributors to std.socket, seem to be unaware of
this fact:
https://github.com/D-Programming-Language/phobos/blob/5978ca7831443cec69430da6b3ccd315aae1878c/std/socket.d#L303

--

Re: Support for D in VSCode

[Gerald via Digitalmars-d]

On Tuesday, 9 February 2016 at 22:23:49 UTC, WebFreak001 wrote:
Sounds awesome for the community! But for me this will probably 
be a real downside as we put so much work into our vscode 
extension already.


In case someone didn't know: me and Wild made a D extension for 
vscode supporting dub (build, run, linting) + dub.json 
completion, dfmt, dscanner, dcd, DlangUI Markup Language syntax 
+ auto complete, SDL syntax, arsd.script syntax, jade syntax, 
upload to dpaste and D snippets: 
https://github.com/Pure-D/code-d


Maybe I'm reading this wrong, but all MS has done is move it to a 
wiki requesting an extension from the community for it. I don't 
see anything that indicates that they will do any work on this. 
You've already done what has been requested IMHO, it would be 
great if there was a way to update the issue/wiki to point to 
your extension.


I've been using your extension for awhile now while and it's been 
great, I'm finding vscode coupled with code-d to be much more 
productive for me then other toolchains I've chained.

Re: Support for D in VSCode

[bitwise via Digitalmars-d]

On Tuesday, 9 February 2016 at 22:23:49 UTC, WebFreak001 wrote:

On Tuesday, 9 February 2016 at 22:06:37 UTC, bitwise wrote:

[...]


Sounds awesome for the community! But for me this will probably 
be a real downside as we put so much work into our vscode 
extension already.


In case someone didn't know: me and Wild made a D extension for 
vscode supporting dub (build, run, linting) + dub.json 
completion, dfmt, dscanner, dcd, DlangUI Markup Language syntax 
+ auto complete, SDL syntax, arsd.script syntax, jade syntax, 
upload to dpaste and D snippets: 
https://github.com/Pure-D/code-d


How did I not know about this!?

Total awesomeness.

You can add it here if you want:
http://wiki.dlang.org/IDEs

Also, can you create an install-wizard or zip/package with the 
extension and all dependencies? I don't really have time to 
figure out how to install everything separately.


Thanks!
   Bit

Automatic range creation for class or struct?

[Peka via Digitalmars-d-learn]

Hi!

I have class (or struct) which realises .length() and 
.opIndex(size_t) methods.


It is possible to create from this class some sort of range using 
template from std? (I mean that internal counter, .popFront(), 
.empty() etc methods should be added by template.)

Re: Is this a bug in std.typecons.Tuple.slice?

[tsbockman via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 09:05:58 UTC, Ola Fosheim Grøstad 
wrote:

I suggest lobbying for proper builtin tuple support.


Built-in tuple support would be great (although to my mind, 
mostly because the current syntax is clunky). But that is a 
long-term goal, and `Tuple.slice` is corrupting data *right now*.


Some sort of short-term fix should be merged in the next release 
of D.

Re: Automatic range creation for class or struct?

[cym13 via Digitalmars-d-learn]

On Wednesday, 10 February 2016 at 00:05:36 UTC, Peka wrote:

Hi!

I have class (or struct) which realises .length() and 
.opIndex(size_t) methods.


It is possible to create from this class some sort of range 
using template from std? (I mean that internal counter, 
.popFront(), .empty() etc methods should be added by template.)


I don't think anything like that exists in phobos but it's not 
hard to pull it out using mixin templates:



mixin template Rangify(T)
if (__traits(hasMember, T, "length")
 && __traits(hasMember, T, "opIndex")) {

ulong _counter;

bool empty() {
return _counter == this.length;
}

auto front() {
return this[_counter];
}

auto popFront() {
_counter++;
}
}

struct S {
int[] arr;

mixin Rangify!S;

auto length() {
return arr.length;
}

int opIndex(size_t i) {
return arr[i];
}
}

void main(string[] args) {
import std.stdio: writeln;

auto s = S();
s.arr = [1, 2, 3];

foreach (x ; s)
writeln(x);
}