Re: dpaste and the wayback machine

[Wyatt via Digitalmars-d]

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.


-Wyatt

[0] http://fileformats.archiveteam.org/wiki/WARC
[1] https://archive.org/help/abouts3.txt
[2] -i,  --input-file=FILE   download URLs found in local or 
external FILE.
[3] 
http://www.archiveteam.org/index.php?title=Wget#Creating_WARC_with_wget
[4] 
https://blog.archive.org/2011/03/31/how-archive-org-items-are-structured/

Re: An IO Streams Library

[Wyatt via Digitalmars-d]

On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote:


This library provides an input and output range interface for 
streams (which is more efficient if the stream is buffered). 
Thus, many of the wonderful range operations from std.range and 
std.algorithm can be used with this.


Ah, grand!  I love the idea and my impression from browsing the 
source a bit is positive enough to say I'm looking forward to 
what comes out of this.


Though I AM a little ambivalent-- I had a series of pretty 
in-depth conversations on this topic with a friend a while back 
and we came to a consensus that stream semantics are a tricky 
thing because of the historical baggage around them and how they 
tend to get conflated with other concepts.


Looking at your API design, I think you've hit close to a lot of 
the same conclusions we reached, but here are the notes I took 
for the sake of providing an additional perspective:
http://radiusic.com/doc/streamNotes (Sorry, I tried just pasting 
them and it was moderately unreadable even in the preview)


I think the most important things we hit upon are:
1. A stream is fundamentally unidirectional.
2. A stream is raw, untyped data that becomes a range through an 
adapter that mediates access.


-Wyatt

Re: Dynamic Ctors ?

[Voitech via Digitalmars-d-learn]

On Monday, 8 February 2016 at 15:09:30 UTC, Kagamin wrote:

http://dpaste.dzfl.pl/1f25ac34c1ee
You need Tuple, not Algebraic. Algebraic stores only one value 
of one type from a set, like Variant.


Thank you for answering. You right if i would want to store all 
types of T.. in an Inner instance. But my conception was bad from 
the beginning. I want to store only one type of value in Inner 
instance. I just wanted to create generic constructor for each of 
Type which is invalid, cause instance holds value of single type 
that's why it is not parametrized by itself.

Re: Things that keep D from evolving?

[NX via Digitalmars-d-learn]

On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote:

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC  
implementations?


Unions and easy type casting prevent precise GC.
Lack of write barriers for reference-type fields prevent fast 
(generational and/or concurrent) GC. Some more detailed 
explanations here:

http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html


I see... By any chance, can we solve this issue with GC managed 
pointers? AFAIK, this is what C++/CLR does: There are 2 different 
pointer types, (*) and (^). (*) is the famous raw pointer, second 
one is GC managed pointer. A GC pointer has write barrier (unlike 
raw pointer) so we can have both raw C performance (if we want) 
and fast generational GC or concurrent GC (which are a magnitude 
better than a mark and sweep GC).
As you realized, there is a major problem with this: classes. The 
desicion of making classes reference-type is actually fine 
(+simplicity), but it doesn't really help with the current 
situation, I expect D to be pragmatic and let me decide. Maybe in 
future... Who knows...

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

[John Colvin 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


How about this, which allows you to specify variables as alias 
parameters (i.e. without strings) as well. It could be a lot 
neater if a static assert is used in the body instead of using 
template constraints, but obviously that has its downsides.


import std.stdio : File;
import std.traits : isSomeString;
import std.meta : allSatisfy;

private template isAlias(a ...)
if (a.length == 1)
{
enum isAlias = __traits(compiles, { alias b = a[0]; })
&& is(typeof(a[0]));
}

private template isStringValue(a ...)
if (a.length == 1)
{
enum isStringValue = isSomeString!(typeof(a[0]));
}

private template isStringOrAlias(a ...)
if (a.length == 1)
{
/* can't use templateOr in the dump template constraints
 * because `Error: template instance F!(a) cannot use local 
'a'

 * as parameter to non-global template templateOr(T...)` */
 * enum isStringOrAlias = isAlias!a || isStringValue!a;
}

mixin template dump(alias file, Args ...)
if (is(typeof(file) == File) && Args.length > 0
&& allSatisfy!(isStringOrAlias, Args))
{
auto _unused_dump = {
import std.traits : Select;
// can put expressions directly in Select with
// 
https://github.com/D-Programming-Language/phobos/pull/3978

enum sep = ", ";
enum term = "\n";
foreach (i, arg; Args)
{
static if (isSomeString!(typeof(arg)))
file.write(arg, " = ", mixin(arg),
Select!(i < Args.length - 1, sep, term));
else
file.write(__traits(identifier, Args[i]), " = ", 
arg,

Select!(i < Args.length - 1, sep, term));
}
return false;
}();
}

mixin template dump(Args ...)
if (Args.length > 0
&& allSatisfy!(isStringOrAlias, Args))
{
import std.stdio : stdout;
mixin .dump!(stdout, Args);
}

unittest
{
import std.stdio;
int a = 3, b = 4;
mixin dump!q{ a + b };
mixin dump!(stderr, "a - b");

mixin dump!a;
mixin dump!(stderr, a, b);
}

Re: An IO Streams Library

[Dejan Lekic via Digitalmars-d]

I think this is a huge task and requires a (huge) DIP, and 
collaborative effort of coming up with a good, really good, API 
for BOTH synchronous and asynchronous IO. As mentioned in the 
previous messages, there is already an asyncio library, although 
I am not sure it is good enough to be in Phobos...


I know people may not like Boost, but Boost.Asio is amazing and 
we should perhaps use it as a guide, if not copy the whole API...

Re: An IO Streams Library

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 8 February 2016 at 09:12:25 UTC, Jakob Ovrum wrote:
I don't think we've used DIPs for library additions before. I 
don't see what it would provide over module documentation.


Probably because a standard library should keep things simple, 
meaning it should unify high level  functionality on aggregates 
as ranges/iterators or a generalization over streams/ranges that 
is as simple as possible across the board.


If not, then why have it in the standard library?

Re: Do D need a popular framework? like ruby's rails? or java 's ssh?

[Eugene Wissner via Digitalmars-d-announce]

On Thursday, 4 February 2016 at 15:37:21 UTC, sigod wrote:

On Tuesday, 19 January 2016 at 13:22:48 UTC, beck wrote:

Do D need a popular framework?
in china ,a little peopel use dlang.
i just  use it do some simple work for myself. yet,i have 
learn d for a week ..
i ask so many friends ,they don't use D at all.we use golang 
more than dlang.


Oh, I thought I'll see here a suggestion to port some popular 
and useful libraries/frameworks from other languages...


Seriously, it might be an interesting idea.


I want to port some parts of PHP Symfony:
https://github.com/caraus-ecms/caraus

I've just started and it is kind of "learning project", I haven't 
written anything in D before. On the other hand I'm writting a 
personal project (kind of CMS/Blog) and this Symfony port is the 
base for this project. Don't know yet if I'll open source 
everything later.

[Issue 15656] broken link in datetime.d documentation

[via Digitalmars-d-bugs]

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

Gerald Jansen  changed:

   What|Removed |Added

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

--- Comment #2 from Gerald Jansen  ---
(In reply to ag0aep6g from comment #1)
> I suppose this is about the ddox pages [1], right? 

Yes. Okay so this is a ddox issue and presumably it is well known so I'll close
this issue.

--

Re: How to warn of unused imports?

[Daniel Kozak via Digitalmars-d-learn]

V Mon, 08 Feb 2016 08:25:09 +
cy via Digitalmars-d-learn  napsáno:

> When I factor out code from my modules, it really, really often 
> leaves import statements that just sit there doing nothing, 
> making it look like my program is more complex than it is. How do 
> I get warned for leaving those, and a list of which ones I can 
> safely remove?

I dont think there is a way right now. But in a future dscanner.
https://github.com/Hackerpilot/Dscanner/issues/134

Re: An IO Streams Library

[Jakob Ovrum via Digitalmars-d]

On Monday, 8 February 2016 at 09:08:53 UTC, Dejan Lekic wrote:
I think this is a huge task and requires a (huge) DIP, and 
collaborative effort of coming up with a good, really good, API 
for BOTH synchronous and asynchronous IO. As mentioned in the 
previous messages, there is already an asyncio library, 
although I am not sure it is good enough to be in Phobos...


I don't think we've used DIPs for library additions before. I 
don't see what it would provide over module documentation.

Re: IDE - Coedit 2 rc1

[Basile Burg via Digitalmars-d-announce]

On Monday, 8 February 2016 at 07:05:15 UTC, Suliman wrote:

On Sunday, 7 February 2016 at 13:18:44 UTC, Basile Burg wrote:

See https://github.com/BBasile/Coedit/releases/tag/2_rc1


Cool! Thanks! But do you have any plans to reimplement it from 
Pascal to D


No.

How to warn of unused imports?

[cy via Digitalmars-d-learn]

When I factor out code from my modules, it really, really often 
leaves import statements that just sit there doing nothing, 
making it look like my program is more complex than it is. How do 
I get warned for leaving those, and a list of which ones I can 
safely remove?

Re: is increment on shared ulong atomic operation?

[Andrea Fontana via Digitalmars-d-learn]

On Sunday, 7 February 2016 at 20:25:44 UTC, Minas Mina wrote:

Just noticed that there's no example.
It's used like

shared(ulong) a;
atomicOp!"+="(a, 1);


Wow, that syntax sucks a lot.



a.atomicOp!"+="(1);

sounds better. You can alias it too.

Re: An IO Streams Library

[Atila Neves via Digitalmars-d]

On Monday, 8 February 2016 at 09:08:53 UTC, Dejan Lekic wrote:
I think this is a huge task and requires a (huge) DIP, and 
collaborative effort of coming up with a good, really good, API 
for BOTH synchronous and asynchronous IO. As mentioned in the 
previous messages, there is already an asyncio library, 
although I am not sure it is good enough to be in Phobos...


I know people may not like Boost, but Boost.Asio is amazing and 
we should perhaps use it as a guide, if not copy the whole 
API...


I like boost. Well, sometimes. I _severely_ dislike boost::asio. 
The new couroutines may make it easier to use, I'd have to try 
1st, but what's the point when vibe.d exists?


Atila

Re: Bug or intended?

[cy via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 14:15:04 UTC, rsw0x wrote:
I was playing around with alias templates and came across this, 
I reduced it to:


---
struct A(alias C c){

  auto foo(){
return c.i;
  }
}

struct B{
  C c;
  A!c a;
}

struct C{
  int i;
}
---

It gives me a "need 'this' for 'i' of type 'int'" error.


I think the "alias C c" you pass actually must be a value "c" of 
some sort. A!c would have to produce a different A struct, for 
every c value. (as opposed to A!C which works fine.) So, if you 
made B with a C with an i = 23, then you'd have an A!(23) and if 
you made another one with i = 42, you'd have an A!(42).


That doesn't seem very useful, for general integers. Maybe if it 
was an enum of finite, limited size it'd make sense.

Re: IDE - Coedit 2 rc1

[John Colvin via Digitalmars-d-announce]

On Monday, 8 February 2016 at 07:25:49 UTC, Dominikus Dittes 
Scherkl wrote:

On Monday, 8 February 2016 at 07:05:15 UTC, Suliman wrote:
Cool! Thanks! But do you have any plans to reimplement it from 
Pascal to В to get it's more native...


B?

What is B?


https://en.wikipedia.org/wiki/B_(programming_language)

but obviously he meant D.

Re: Dynamic Ctors ?

[Voitech via Digitalmars-d-learn]

On Monday, 8 February 2016 at 07:08:58 UTC, Voitech wrote:

On Saturday, 6 February 2016 at 23:35:17 UTC, Ali Çehreli wrote:

On 02/06/2016 10:05 AM, Voitech wrote:

> [...]

You can use string mixins (makeCtor and makeCtors):

string makeCtor(T)() {
import std.string : format;

[...]


Thank you very much for answering.
Cheers


Unfortunately this doesn't work as I'am trying to assign value 
from ctor to member something like:


this(%s value){
this.value=value;
}

it gives me
Error: memcpy cannot be interpreted at compile time, because it 
has no available source code.
Probably this is caused by declaration of member which is also 
parametrized with T...

Member is:
Algebraic!(T) value;

So declaration of this mixin constructors are done before 
variable value is declared (compilation)?


Is there any field in class that would contain ctors ? Something 
like __ctors ?
i could try to init this(T... value) constructors in static 
constructor using delegates/functions. Something like:


template Outer(T...){
class Inner{
Algebraic!(T) value;

alias ctor(Type) =Inner delegate (Type value);
static this(){
foreach(Type;T){
ctor!(Type) c={
this.value=value;
};
__ctors~=c; // ?
}

}

}

Re: Things that keep D from evolving?

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

On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote:

http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html


Well, the latest Intel CPUs have a theoretical throughput of 
30GB/s... so that makes for up to 30MB/ms.


But language changes are needed, I think.

I also don't quite understand how RC can solve the issue with 
pointers to internal fields in classes.

[Issue 15656] broken link in datetime.d documentation

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
I suppose this is about the ddox pages [1], right? The link is broken there,
but it's fine on the ddoc pages [2].

The underscore is there for a reason: Without it, "datetime" would be
highlighted by ddoc, which would garble the URL, breaking the link.

That ddox carries over the underscore literally seems to be a bug, or at least
an incompatibility between ddox and ddoc.

So, fixing this will be more complicated than just removing the underscore,
unfortunately.


[1] ,

[2] ,


--

Re: An IO Streams Library

[Kagamin via Digitalmars-d]

On Sunday, 7 February 2016 at 00:48:54 UTC, Jason White wrote:

GitHub:  https://github.com/jasonwhite/io


In the output stream you compare output data length to the input 
data length. In case of a transcoding stream they can be 
different. Are you trying to account for partial writes?

[Issue 15656] New: broken link in datetime.d documentation

[via Digitalmars-d-bugs]

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

  Issue ID: 15656
   Summary: broken link in datetime.d documentation
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: jansen.ger...@gmail.com

tldr; in std/datetime.d, http://dlang.org/intro-to-_datetime.html should be
http://dlang.org/intro-to-datetime.html

I tried to fix this myself using the "Improve this page" but that mysteriously
took me to an EMPTY datetime.d file in github:
D-Programming-Language/phobos/std/datetime.d, with a warning  "You’re editing a
file in a project you don’t have write access to. Submitting a change to this
file will write it to a new branch in your fork jansengb/phobos, so you can
send a pull request."

Okay, so I fork phobos in github and navigate to datetime.d. Whoa, the file is
1.38 Mb, too big to be viewed/edited in github. Okay, I give up.

--

[Issue 15629] [REG2.066.0] wrong code with "-O -inline" but correct with "-O"

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

Summary|[REG] wrong code with "-O   |[REG2.066.0] wrong code
   |-inline" but correct with   |with "-O -inline" but
   |"-O"|correct with "-O"

--- Comment #4 from Kenji Hara  ---
(In reply to Kenji Hara from comment #3)
> Dustmited case code:

Sorry, the reduced code cannot reproduce exactly same regression with the
original.
I'll open one more issue for that.

Correct minimized code is:

void main()
{
int[] a = [3];
int value = abs(a[0]);
assert(a[0] == 3);
writeln(value, " ", a);
}

Num abs(Num)(Num x)
{
return x >= 0 ? x : -x;
}

struct File
{
struct LockingTextWriter
{
this(File) {}

~this() @trusted {}
}

auto lockingTextWriter()
{
return LockingTextWriter();
}
}

File stdout;

void writeln(T...)(T args)
{
stdout.lockingTextWriter();
}

Introduced in:
https://github.com/D-Programming-Language/dmd/pull/3620
and its fixup PR:
https://github.com/D-Programming-Language/dmd/pull/3656

So this is a regression from 2.066.0.

--

[Issue 15629] [REG2.066.0] wrong code with "-O -inline" but correct with "-O"

[via Digitalmars-d-bugs]

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

--- Comment #5 from Kenji Hara  ---
(In reply to Kenji Hara from comment #4)
> Sorry, the reduced code cannot reproduce exactly same regression with the
> original.
> I'll open one more issue for that.

Ah, I got understanding. The reduced case in comment#3 has generated wrong code
with -inline, since the change by PR#4474:
https://github.com/D-Programming-Language/dmd/pull/4474

However, comment#3 and comment#4 are essentially same. The only one difference
is the parenthesis on stdout.lockingTextWriter(); in writeln template function.
So, this wrong-code issue in the comment#3 case was hidden by issue 14264, and
it's *fixed* by PR#4474. Therefore the two cases can hit this issue with
current master.

--

Re: Things that keep D from evolving?

[thedeemon via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC  
implementations?


Unions and easy type casting prevent precise GC.
Lack of write barriers for reference-type fields prevent fast 
(generational and/or concurrent) GC. Some more detailed 
explanations here:

http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html

[Issue 15656] broken link in datetime.d documentation

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #3 from ag0ae...@gmail.com ---
(In reply to Gerald Jansen from comment #2)
> Yes. Okay so this is a ddox issue and presumably it is well known so I'll
> close this issue.

I don't think it's well known. At least, this is the first time it's been
pointed out to me. This may have to be fixed in ddox, but the broken links are
an issue for phobos/dlang.org. So this is definitely not invalid. Reopening.

--

Re: How is D doing?

[Basile Burg via Digitalmars-d-learn]

On Tuesday, 22 December 2015 at 11:42:42 UTC, bachmeier wrote:
1. Downloads of the DMD compiler have been fluctuating between 
1000 and 1600 per day:


http://erdani.com/d/downloads.daily.png


To this you can add 75dl per day for ldc:

http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc

They'll reach 60K (overlall) this week.

Better Forum view.

[Martin Tschierschke via Digitalmars-d]

Hello,
it took me a while to discover, that there is a possibility to 
change the appearing of the Forum.
Stettings->View mode: Basic, Threadet, Horzontal Split, Vertical 
Split.


I like the "Vertical Split" option in general, but I dislike to 
have it on the Index Page,


So I am very much in favor for changing the behavior of the "View 
Modes" in this direction.


What do others think?
Regards mt.

[Issue 15659] SList: clear() can cause crash

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/b847c5a194f0eea8429c50c8a2539ca82ff2bb55
Fix Issue 15659 - fix crash in SList.clear()

https://github.com/D-Programming-Language/phobos/commit/f62c716072380bb52b9918c8d8d1fd7d3079b7fb
Merge pull request #3980 from sigod/slist-clear-crash

Fix Issue 15659 - fix crash in SList.clear()

--

Problem with release build.

[sanjayss via Digitalmars-d-learn]

In the following sample program (which tries to set terminal to 
raw mode and check for key presses), compiling as usual (dmd 
t.d), the program works, but compiling in release mode (dmd 
-release t.d) and the raw mode doesn't seem to work. Where do I 
start looking to figure this out or if it is obvious, what am I 
doing wrong? (In the release mode output, notice the character 
getting echo-ed before the "Got").


MacBook-Pro:$ dmd --version
DMD64 D Compiler v2.069.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
MacBook-Pro:$ dmd t.d
MacBook-Pro:$ ./t
Got: a
Got: b
Got: c
Got: d
Got: q
MacBook-Pro:$ dmd -release t.d
MacBook-Pro:$ ./t
aGot: a
bGot: b
cGot: c
dGot: d
eGot: e
qGot: q
MacBook-Pro:$ cat t.d
import core.thread;
import core.stdc.stdio;
import core.sys.posix.fcntl;
import core.sys.posix.termios;
import std.stdio : writeln;

int oldf;
termios oldt;

void
makeraw()
{
termios newt;

assert(tcgetattr(0, ) == 0);
newt = oldt;

newt.c_lflag &= ~(ICANON | ECHO | ECHONL | ISIG | IEXTEN);
newt.c_iflag &= ~(IGNBRK | BRKINT | ISTRIP | INLCR | ICRNL | 
IGNCR | IXON | IXOFF);

newt.c_cc[VMIN] = 1;
assert(tcsetattr(0, TCSANOW, ) == 0);

oldf = fcntl(0, F_GETFL, 0);
fcntl(0, F_SETFL, oldf | O_NONBLOCK);
}

void
makecooked()
{
fcntl(0, F_SETFL, oldf);
assert(tcsetattr(0, TCSANOW, ) == 0);
}

void
main(string[] args)
{
int ch;

makeraw();
scope(exit) makecooked();

do
{
while ((ch = fgetc(stdin)) == EOF)
{
Thread.sleep(dur!("seconds")(1));
}
writeln("Got: ", cast(dchar)ch);
} while (ch != 'q');
}

Re: Challenge: fair partition function

[Xinok via Digitalmars-d]

On Monday, 8 February 2016 at 23:25:00 UTC, Andrei Alexandrescu 
wrote:
Consider defining a function that partitions a range around a 
given index like this:


size_t pivotPartition(alias less = (a, b) => a < b, Range)
(Range r, size_t pivot);

Returns x, one of the the indexes that r[pivot] would have if r 
were sorted. Also, r[0 .. x] contains stuff no greater than 
r[x] and r[x + 1 .. $] contains stuff no less than r[x].


The challenge is to implement such a function with fairness: if 
several elements are equal to r[pivot], return the index 
closest to r.length / 2.


The function should be efficient, minimize calls to less and 
swap, etc. A variant that is efficient but does not implement 
fairness is below.


...


Ultimately, I think you're going to have to perform two 
comparisons on *some* elements to check for equality. I thought 
of a few tricks which may or may not help.




(1) Keep your code as is and add a final pass to count the number 
of elements. However, you only need to scan the larger partition 
since it contains the index (r.length / 2) and you're trying to 
move closer to that point. The elements in the smaller partition 
can simply be ignored.




(2) You may have code which looks something like this:

if(less(e, pivot)){ /+ less than +/ }
else if(less(pivot, e)){ /+ greater than +/ }
else{ /+ equal to +/ }}

This is a big win if most of the elements are less than the 
pivot, but also a big loss if most of the elements are greater 
than the pivot. A simple trick is to repeat the code twice but 
swap the order of comparisons so you get:


if(less(pivot, e)){ /+ greater than +/ }
else if(less(e, pivot)){ /+ less than +/ }
else{ /+ equal to +/ }}

This will place us closer to an average 1.5 comparisons per 
element which is better than (1).




(3) Similar to (2) except you only compare each element once so 
you're not checking for equality. You're simply alternating 
between checking if (e < pivot) or if (pivot < e). So the code 
may look something like this:


if(less(pivot, e)){ less }
else{ greater or equal }

if(less(e, pivot)){ greater }
else{ less or equal }

From this, you can group the elements into four partitions:

[LE L G GE]

So you have elements which are definitely less than or greater 
than the pivot but also some elements which *may* be equal to the 
pivot. Combine this with the first trick (1) and you only have to 
scan LE or GE for equality but not both. This is putting us 
closer to an average 1.25 comparisons per element but a 4-way 
partition would also require much more work.

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

[Marco Leise via Digitalmars-d-learn]

Am Tue, 09 Feb 2016 00:38:10 +
schrieb tsbockman :

> On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
> > What I like most about your proposal is that it doesn't break 
> > any existing code that wasn't broken before. That can't be 
> > emphasized enough.
> 
> Although I wish more than 3 people had voted in my poll, two of 
> them did claim to need the `ref`-ness of `Tuple.slice`, so I 
> don't think we can just ditch it. (I did not vote.)
> 
> If you guys want to add a return-by-value version, it should be 
> treated as an enhancement, not a bug fix in my opinion.

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 and both fixes yield unexpected results in
different contexts that warrant bug reports.

-- 
Marco

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

[Basile B. 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!


Use an intermediate to carry the result of &:

double b = 1.0;
Variant vb = 
Variant[string] aa = ["b": vb];
writeln(aa["b"]);

 is a rvalue.
vb is a lvalue.

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

[Ali Çehreli via Digitalmars-d-learn]

On 02/08/2016 07:49 PM, 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!


When initializing the array, you have to use Variant():

import std.stdio;
import std.variant;

void main() {
double b = 1.5;

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

writeln(aa);
writeln(aa["b"]);
writeln(*aa["b"].get!(double*));
}

Prints something like the following:

["b":7FFD0104B100]
7FFD0104B100
1.5

Ali

[Issue 15661] Destructor called while object still alive

[via Digitalmars-d-bugs]

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

--- Comment #1 from Daniel Kozak  ---
in 2.066.1 and before it works as expected

--

Re: Problem with release build.

[sanjayss via Digitalmars-d-learn]

Ignore this -- this is probably due to how I am doing the 
assert(). In the release build, it is getting compiled out and in 
the process compiling out the tcgetattr and the tcsetattr.




On Tuesday, 9 February 2016 at 05:08:20 UTC, sanjayss wrote:
In the following sample program (which tries to set terminal to 
raw mode and check for key presses), compiling as usual (dmd 
t.d), the program works, but compiling in release mode (dmd 
-release t.d) and the raw mode doesn't seem to work. Where do I 
start looking to figure this out or if it is obvious, what am I 
doing wrong? (In the release mode output, notice the character 
getting echo-ed before the "Got").


MacBook-Pro:$ dmd --version
DMD64 D Compiler v2.069.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
MacBook-Pro:$ dmd t.d
MacBook-Pro:$ ./t
Got: a
Got: b
Got: c
Got: d
Got: q
MacBook-Pro:$ dmd -release t.d
MacBook-Pro:$ ./t
aGot: a
bGot: b
cGot: c
dGot: d
eGot: e
qGot: q
MacBook-Pro:$ cat t.d
import core.thread;
import core.stdc.stdio;
import core.sys.posix.fcntl;
import core.sys.posix.termios;
import std.stdio : writeln;

int oldf;
termios oldt;

void
makeraw()
{
termios newt;

assert(tcgetattr(0, ) == 0);
newt = oldt;

newt.c_lflag &= ~(ICANON | ECHO | ECHONL | ISIG | IEXTEN);
newt.c_iflag &= ~(IGNBRK | BRKINT | ISTRIP | INLCR | ICRNL 
| IGNCR | IXON | IXOFF);

newt.c_cc[VMIN] = 1;
assert(tcsetattr(0, TCSANOW, ) == 0);

oldf = fcntl(0, F_GETFL, 0);
fcntl(0, F_SETFL, oldf | O_NONBLOCK);
}

void
makecooked()
{
fcntl(0, F_SETFL, oldf);
assert(tcsetattr(0, TCSANOW, ) == 0);
}

void
main(string[] args)
{
int ch;

makeraw();
scope(exit) makecooked();

do
{
while ((ch = fgetc(stdin)) == EOF)
{
Thread.sleep(dur!("seconds")(1));
}
writeln("Got: ", cast(dchar)ch);
} while (ch != 'q');
}

[Issue 15661] Destructor called while object still alive

[via Digitalmars-d-bugs]

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

Daniel Kozak  changed:

   What|Removed |Added

 CC||kozz...@gmail.com
 OS|Windows |All
   Severity|major   |regression

--

How do you reference variables in an AA of Variants?

[Enjoys Math via Digitalmars-d-learn]

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!

Re: voldemort stack traces (and bloat)

[Steven Schveighoffer via Digitalmars-d]

On 2/8/16 8:19 AM, wobbles wrote:

On Monday, 8 February 2016 at 13:01:44 UTC, Steven Schveighoffer wrote:

On 2/7/16 12:18 AM, Steven Schveighoffer wrote:

I have a library where I was using very many voldemort types a la
std.range.



[snip]


Is there a better way we should be doing this? I'm wondering if
voldemort types are really worth it. They offer a lot of convenience,
and are much DRYer than separate private template types. But the bloat
cost is not really worth the convenience IMO.


I modified all my voldemort-returning functions to return module-level
types.

One of my example programs (compiled optimized/inline) went from 10MB
to 1MB. The other example program went from 2.1MB to 900k.



Just to be sure, you replaced something like this:

auto myFunc(int x){
struct MyStruct{ int a; }
return MyStruct(x);
}

with?

private struct MyStruct{ int a; }
auto myFunc(int x){
 return MyStruct(x);
}



Yes, but with template parameters. It's not so much the moving of the 
struct that reduced the bloat, but the nature of how the template 
parameters are used. Each function that returns one of these structs 
wraps another such struct, so the template bloat is exponential because 
of the repeat of the template parameter for the function argument. By 
moving the struct into the module, there is only one specification of 
the template parameter for the name mangling. Basically, I changed a.b.c 
bloat factor from 2^3 to 1^3.


-Steve

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

[Andrei Alexandrescu via Digitalmars-d]

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

[Issue 15619] [REG 2.066] Floating-point x86_64 codegen regression, when involving array ops

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|[REG 2.068] Floating-point  |[REG 2.066] Floating-point
   |x86_64 codegen regression,  |x86_64 codegen regression,
   |when involving array ops|when involving array ops

--- Comment #2 from Kenji Hara  ---
Both original and reduced code generate wrong result since 2.066.0 (2.065 is
ok).

--

Re: Dynamic Ctors ?

[Kagamin via Digitalmars-d-learn]

http://dpaste.dzfl.pl/1f25ac34c1ee
You need Tuple, not Algebraic. Algebraic stores only one value of 
one type from a set, like Variant.

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

[Atila Neves via Digitalmars-d-announce]

What's new:

Built-in unittest blocks can now have a name with just a string 
UDA:



@("test that does stuff") unittest {... }

Why is this important? If you just want to run unit tests in 
threads and have them named, you don't need to import 
unit_threaded in your source code anymore. I'm going to build on 
this later with a tool to make it so that existing codebases can 
benefit from unit_threaded without using it directly.



Value-parametrized tests


Have you ever written a test that looks like this?

unittest {
foreach(v; [...]) {
//test code
}
}


I have, and when it fails you have no idea which of the values 
caused the failure. Now, you can do this:


@(42, 2, 3)
void testValues(int i) {
(i % 2 == 0).shouldBeTrue;
}

testValues will be run once for each value UDA with the same type 
in its declaration (in this case, int). Each run will be 
considered a different test and reported as such with the value 
that was used. In the above case, the output will contain this:


tests.pass.attributes.testValues.42:
tests.pass.attributes.testValues.2:
tests.pass.attributes.testValues.3:
tests/pass/attributes.d:76 - Expected: true
tests/pass/attributes.d:76 -  Got: false

Test tests.pass.attributes.testValues.3 failed.


Enjoy!

Atila

Re: CTFE thoughts & functional approach

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

On 2016-01-31 13:59:06 +, Robert M. Münch said:


I like CTFE and the meta programming idea for languages like D.

However, I'm wondering why most (everyone?) is trying to do 
meta-programming using the same language as the one getting compiled. 
IMO the use-cases a pretty different and doing CTFE, code-generation 
etc. needs some other approach. If you look at all the strange template 
syntax, strange hacks etc. it's all far from being obvious.


Why not have a CTL (compile-time-language) that has access to some 
compiler internals, that follows a more functional concept? We are 
evaluating sequences of things to generate code, include / exclude code 
etc.


From my experience with the different approaches, functional thinking 
is much better suited and simpler to use for CTFE goals.


IMO that would really be a big step ahead. Because you know a hammer, 
not everything is a nail...


Here is a link http://terralang.org/ where these guys mix Lua and their 
compiled language, to achieve what I was thinking about in the same 
line:


"In this use-case, Lua serves as a powerful meta-programming language. 
You can think of it as a replacement for C++ template metaprogramming3 
or C preprocessor X-Macros4 with better syntax and nicer properties 
such as hygiene5."


Maybe this better explains, where I think it makes sense to seperate 
the two levels: language for the buidling-step, and language for the 
actual solution.


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

Re: voldemort stack traces (and bloat)

[wobbles via Digitalmars-d]

On Monday, 8 February 2016 at 13:01:44 UTC, Steven Schveighoffer 
wrote:

On 2/7/16 12:18 AM, Steven Schveighoffer wrote:
I have a library where I was using very many voldemort types a 
la

std.range.



[snip]


Is there a better way we should be doing this? I'm wondering if
voldemort types are really worth it. They offer a lot of 
convenience,
and are much DRYer than separate private template types. But 
the bloat

cost is not really worth the convenience IMO.


I modified all my voldemort-returning functions to return 
module-level types.


One of my example programs (compiled optimized/inline) went 
from 10MB to 1MB. The other example program went from 2.1MB to 
900k.


-Steve


Just to be sure, you replaced something like this:

auto myFunc(int x){
   struct MyStruct{ int a; }
   return MyStruct(x);
}

with?

private struct MyStruct{ int a; }
auto myFunc(int x){
return MyStruct(x);
}

Re: Google Summer of Code 2016

[CraigDillabaugh via Digitalmars-d]

On Sunday, 7 February 2016 at 12:14:24 UTC, Dragos Carp wrote:
On Saturday, 6 February 2016 at 20:18:57 UTC, Craig Dillabaugh 
wrote:
Anyone interested and capable of mentor a student interested 
in doing FlatBuffers for D.


I could do that. Currently, as a side project, I'm working on 
adding D support for Protocol Buffers v3 [1].


Main goals of the new design:
- integration in the upstream project
- simple readable generated code
- range based solution

Of course, the same can be applied for the FlatBuffers.

[1] https://github.com/dcarp/protobuf/tree/dlang_support


Awesome! Thanks.  I will write up something on the idea's page in 
the next day or two (which you are welcome to edit of course).  
Also, if a student were interested in working on Protocol 
Buffers, would there be opportunities there too?


I also ask Mentor's to write a little bit about themselves on the 
mentor's page:


http://wiki.dlang.org/GSOC_mentors

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

[Tourist 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


dump and fdump, just like printf and fprintf?

Re: How to warn of unused imports?

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

On Monday, 8 February 2016 at 08:25:09 UTC, cy wrote:
How do I get warned for leaving those, and a list of which ones 
I can safely remove?


Remove one, recompile. If it passes, leave it. If not, undo and 
move on to the next one.

Re: voldemort stack traces (and bloat)

[Steven Schveighoffer via Digitalmars-d]

On 2/7/16 12:18 AM, Steven Schveighoffer wrote:

I have a library where I was using very many voldemort types a la
std.range.



[snip]


Is there a better way we should be doing this? I'm wondering if
voldemort types are really worth it. They offer a lot of convenience,
and are much DRYer than separate private template types. But the bloat
cost is not really worth the convenience IMO.


I modified all my voldemort-returning functions to return module-level 
types.


One of my example programs (compiled optimized/inline) went from 10MB to 
1MB. The other example program went from 2.1MB to 900k.


-Steve

[Issue 15657] New: [internal] StructLiteralExp.sinst comparison in constfolding needs to be removed

[via Digitalmars-d-bugs]

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

  Issue ID: 15657
   Summary: [internal] StructLiteralExp.sinst comparison in
constfolding needs to be removed
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: k.hara...@gmail.com

This is a task reminder issue.

https://github.com/D-Programming-Language/dmd/pull/1301/files#r52168903

At least, StructLiteralExp.sinst is a backend-specific field. Using it for
semantic analysis causes a layer violation.

--

Re: Proposal: Database Engine for D

[Mengu via Digitalmars-d]

On Saturday, 6 February 2016 at 13:41:03 UTC, Piotrek wrote:

On Saturday, 6 February 2016 at 00:14:08 UTC, Mengu wrote:
and while we were talking the talk, rust community rolled out 
something good called diesel. check it out at 
http://diesel.rs/.


we need tools that get things done. we do not need tools that 
makes things more complex than they already are.


Almost no one (including me) is interested in ORM for SQL. The 
point is ORM+SQL is limiting and sooner or later you fallback 
to SQL.


Additionally there is no critical mass for this kind of big 
project (combining all the SQL engines - good luck).


Andrei suggested a CTFE sql parser, so people who like SQL (not 
me) can benefit from the D metaprogramming power.


For the rest there is my proposal ;) : a language embedded DB. 
As far as I can tell none of the known PLes has this "killer" 
feature.


Piotrek


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.

Re: Things that keep D from evolving?

[Chris Wright via Digitalmars-d-learn]

On Mon, 08 Feb 2016 11:22:45 +, thedeemon wrote:

> On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
>> What language semantics prevent precise & fast GC implementations?
> 
> easy type casting prevent precise GC.

To expand on this point:

A GC makes a tradeoff between allocating efficiently and deallocating 
efficiently. (And a compiler+runtime makes a tradeoff between generating 
larger binaries that take more time to deal with and being able to 
produce precise garbage collection.)

You can write a GC that allocates each type in its own region of memory. 
Every block has a pointer map associated with it. But this means the 
minimum allocation for each type is one page -- typically 4KB. This is 
bad for applications that have very few instances of each type and many 
types of object allocated.

A simpler thing you can do is write a GC that has two regions of memory, 
one with pointers that might point to GC memory and one without. This 
gets rid of the overhead problem but doesn't allow precise collection.

Alternatively, a language might prevent all casting, even upcasting, for 
any type that might contain pointers. Specifically:

class Foo {}
class Bar : Foo {}
Foo foo = new Bar();  // type error!

This means that the GC doesn't ever need to store the type of an 
allocated object anywhere. It can get the information it needs from a 
stack map ("pointer to Foo is stored in this stack frame at offset 8") 
and a similarly formatted map for allocated types.

It would work, but it's sufficiently constraining that I don't think 
anyone has this in a real programming language.

Re: An IO Streams Library

[Atila Neves via Digitalmars-d]

On Monday, 8 February 2016 at 17:11:56 UTC, Chris Wright wrote:

On Mon, 08 Feb 2016 12:19:59 +, Atila Neves wrote:


On Monday, 8 February 2016 at 09:08:53 UTC, Dejan Lekic wrote:

[...]


I like boost. Well, sometimes. I _severely_ dislike 
boost::asio.
The new couroutines may make it easier to use, I'd have to try 
1st, but

what's the point when vibe.d exists?

Atila


I can't use vibe.d for one of my projects because I need to 
keep tight control of coroutine scheduling. Better async IO 
routines in Phobos would help me -- though I'm mainly looking 
for higher level stuff, like a telnet handler.


You can always use fibers yourself and just do the IO there. It's 
cooperative multithreading so you control when one of them yields.


Atila

Re: Can D interface with Free Pascal?

[Basile B. via Digitalmars-d-learn]

On Thursday, 28 January 2016 at 04:26:26 UTC, Taylor Hillegeist 
wrote:
Just curious... I had a thought that perhaps since Objective C 
was a replacement for Pascal on the mac. that they might have 
the same interface. but I'm not savvy enough with fpc to figure 
out how to try it.


As said in the other posts you can link dlls or even object files 
produced by a D compiler. There is the D runtime to initialize 
and finalize, a particular attention must be put on te calling 
conventions, also some stuff like strings must be passed using 
toStringz() or received with fromStringz() (and Pchar() in 
pascal)...


One thing that's interesting is to develop let's say the GUI with 
Lazarus and use a core made in D. When you'll debug your 
application in Lazarus, and if an exception is raised within the 
object or the dll made in D, the integrated debugger will break 
and display the D source directly in Lazarus.


The first time it happend to me, I was **totally mesmerized**...

(I even made a post here: 
https://forum.dlang.org/thread/aeiwsnmsrchgmkbll...@forum.dlang.org "//debugger breaks here": it was the Lazarus debugger who displayed a D source).


But actually it's totally logical, it's just the DWARF debug info 
that indicates the source name...

Re: Things that keep D from evolving?

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

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
Maybe we could.  But it's never going to happen.  Even if 
Walter weren't fundamentally opposed to multiple pointer types 
in D, it wouldn't happen.


You asked about things that prevent improvement, right?  Here's 
the big one, and a major point of friction in the community: 
Walter and Andrei refuse to break existing code in pursuit of 
changes that substantially improve the language.  (Never mind 
that code tends to break anyway.)


You are of course right, but it isn't an absolute. Nothing 
prevents someone to restrict a D compiler in such a way that you 
can get faster GC.


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.

Re: An IO Streams Library

[Chris Wright via Digitalmars-d]

On Mon, 08 Feb 2016 12:19:59 +, Atila Neves wrote:

> On Monday, 8 February 2016 at 09:08:53 UTC, Dejan Lekic wrote:
>> I think this is a huge task and requires a (huge) DIP, and
>> collaborative effort of coming up with a good, really good, API for
>> BOTH synchronous and asynchronous IO. As mentioned in the previous
>> messages, there is already an asyncio library, although I am not sure
>> it is good enough to be in Phobos...
>>
>> I know people may not like Boost, but Boost.Asio is amazing and we
>> should perhaps use it as a guide, if not copy the whole API...
> 
> I like boost. Well, sometimes. I _severely_ dislike boost::asio.
> The new couroutines may make it easier to use, I'd have to try 1st, but
> what's the point when vibe.d exists?
> 
> Atila

I can't use vibe.d for one of my projects because I need to keep tight 
control of coroutine scheduling. Better async IO routines in Phobos would 
help me -- though I'm mainly looking for higher level stuff, like a 
telnet handler.

Re: Things that keep D from evolving?

[rsw0x via Digitalmars-d-learn]

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:

On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:


I see... By any chance, can we solve this issue with GC 
managed pointers?


Maybe we could.  But it's never going to happen.  Even if 
Walter weren't fundamentally opposed to multiple pointer types 
in D, it wouldn't happen.


You asked about things that prevent improvement, right?  Here's 
the big one, and a major point of friction in the community: 
Walter and Andrei refuse to break existing code in pursuit of 
changes that substantially improve the language.  (Never mind 
that code tends to break anyway.)


-Wyatt


Pretty much this.
We can't go a version without code breakage, but also can't 
introduce features that would drastically help the language 
because it would introduce breakage.
i.e, all the great ownership/scope/what-have-you proposals and 
shit like DIP25 gets pushed through instead, then 2 days later it 
gets proven to be worthless anyways. Woops.

Re: Things that keep D from evolving?

[Wyatt via Digitalmars-d-learn]

On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:


I see... By any chance, can we solve this issue with GC managed 
pointers?


Maybe we could.  But it's never going to happen.  Even if Walter 
weren't fundamentally opposed to multiple pointer types in D, it 
wouldn't happen.


You asked about things that prevent improvement, right?  Here's 
the big one, and a major point of friction in the community: 
Walter and Andrei refuse to break existing code in pursuit of 
changes that substantially improve the language.  (Never mind 
that code tends to break anyway.)


-Wyatt

Re: How to warn of unused imports?

[Ali Çehreli via Digitalmars-d-learn]

On 02/08/2016 06:35 AM, Adam D. Ruppe wrote:

On Monday, 8 February 2016 at 08:25:09 UTC, cy wrote:

How do I get warned for leaving those, and a list of which ones I can
safely remove?


Remove one, recompile. If it passes, leave it. If not, undo and move on
to the next one.


Similarly, I comment out all; then uncomment one by one according to 
compilation errors.


Ali

Re: dpaste and the wayback machine

[Wyatt via Digitalmars-d]

On Monday, 8 February 2016 at 20:02:41 UTC, Jesse Phillips wrote:


I'm not sure if the wayback machine should be used for version 
control, if you want to keep a history of your past I suggest 
using a gist.github.com.


I view the wayback machine as a view for what the web used to 
look like not necessarily what information was in it.


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.


-Wyatt

in a template argument, specify which object member to access?

[cy via Digitalmars-d-learn]

object.member lets me access the member of the object, but what 
if I want to access those members in a generic way, but in a 
different arrangement depending on context? Like if I wanted to 
first follow a tree down, and second priority would be going left 
to right, but then I wanted to first go right, and second 
priority would be going down to up.


struct A {
string up;
string down;
string left;
string right;
}

template goPlaces(D1,D2,D3) {
string go(A a) {
return "go " ~ a.D1 ~ " then go " ~ a.D2 ~ " then go " ~ a.D3;
}
}

import std.stdio;

void main() {
A a = {"north","south","east","west"};
writeln(goPlaces!(up,down,left)(a));
}

Do I just have to use a mixin? Or implement those members as 
indexes in an array, if I want to use them differently?


enum Way { UP, DOWN, LEFT, RIGHT };
struct A {
string[Way.max+1] ways;
}
...

Re: Safe cast away from immutable

[Jonathan M Davis via Digitalmars-d]

On Monday, 8 February 2016 at 19:07:01 UTC, Iakh wrote:

import std.stdio;

struct S
{
void[] arr;

auto f() pure @safe
{
int[] a = new int[4];
arr = a;
return a;
}
}
void main() @safe
{
S s;
immutable a = s.f();
int[] b = (cast(int[])s.arr);
writeln(a);
b[0] = 1;
writeln(a);
}

http://dpaste.dzfl.pl/13751913d2ff


The bug is that it's even legal to declare a as immutable. pure 
functions that are strongly pure allow for the return value to 
have its mutability altered, because it's guaranteed that what's 
being returned isn't referenced anywhere else in the program. 
However, f is not strongly pure. It's taking the this 
pointer/reference as mutable, not immutable, which allows for the 
memory that's allocated in it to escape - as you've done in this 
example.


So, the compiler logic with regards to pure is buggy. Simply 
having


struct S
{
void[] arr;

auto f() pure @safe
{
int[] a = new int[4];
arr = a;
return a;
}
}
void main() @safe
{
S s;
immutable a = s.f();
}


in a bug report should be sufficient to show the bug, even 
without the rest of what you're doing.


In general, it should be impossible for member functions to be 
considered strongly pure unless they're marked as immutable, 
though the compiler could certainly be improved to determine that 
no escaping of the return value or anything referencing it occurs 
within the function and that thus it can get away with treating 
the return value as if it's the only reference to that data, but 
that would likely be farther into the realm of code flow analysis 
than the compiler typically does.


Regardless, your example definitely shows a bug. Please report 
it. Thanks.


- Jonathan M Davis

[Issue 15660] New: result of pure function

[via Digitalmars-d-bugs]

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

  Issue ID: 15660
   Summary: result of pure function
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: iakt...@gmail.com

Compiler can't determine result of pure function is not unique

import std.stdio;

struct S
{
void[] arr; // with int instead of void program doesn't compiles

auto f() pure @safe
{
int[] a = new int[4];
arr = a;
return a;
}
}
void main() @safe
{
S s;
immutable a = s.f();
int[] b = (cast(int[])s.arr);
writeln(a); // [0, 0, 0, 0]
b[0] = 1;
writeln(a); // [1, 0, 0, 0]
}

--

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

[via Digitalmars-d-bugs]

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

Iakh  changed:

   What|Removed |Added

Summary|result of pure function |breack "immutable" with
   ||pure function and mutable
   ||params

--

Re: Dconf 2015 talks...

[John Colvin via Digitalmars-d]

On Monday, 8 February 2016 at 19:46:19 UTC, Joseph Rushton 
Wakeling wrote:

[snip]


This might be a stupid idea, but perhaps there's something useful 
in it:


Determinism isn't the same thing as "one long chain of numbers 
that everybody reads from".


It can be acceptable to seed a set of reasonable pseudo-random 
number generators with consecutive integers (indeed seeding 
randomly can be dangerous because of the birthday problem). More 
generally, any change of the state of the rng in "seed-space" 
should produce an output equivalent to taking a sample from the 
output distribution.


Can you not have a random number generator make a copy of itself 
like this:


struct RNG
{
State state;
static State.ModifierT modifier;
this(this)
{
this.state.alterBy(modifier++);
//recalculate output sample etc...
}
}

Then any time you copy a RNG, the copy is kicked on to a new path 
in state-space. Basically we're deterministically re-seeding on 
copy.

Re: How to warn of unused imports?

[cy via Digitalmars-d-learn]

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

Re: Safe cast away from immutable

[Iakh via Digitalmars-d]

On Monday, 8 February 2016 at 20:43:23 UTC, Jonathan M Davis 
wrote:




in a bug report should be sufficient to show the bug, even 
without the rest of what you're doing.


In general, it should be impossible for member functions to be 
considered strongly pure unless they're marked as immutable, 
though the compiler could certainly be improved to determine 
that no escaping of the return value or anything referencing it 
occurs within the function and that thus it can get away with 
treating the return value as if it's the only reference to that 
data, but that would likely be farther into the realm of code 
flow analysis than the compiler typically does.


It does. A bit. If S.arr is int[] the program fails to compile.
Is all prams being const(but not immutable) not enough for
function to be Pure?



Regardless, your example definitely shows a bug. Please report 
it. Thanks.


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

Re: Safe cast away from immutable

[Jonathan M Davis via Digitalmars-d]

On Monday, 8 February 2016 at 21:14:11 UTC, Iakh wrote:
On Monday, 8 February 2016 at 20:43:23 UTC, Jonathan M Davis 
wrote:
in a bug report should be sufficient to show the bug, even 
without the rest of what you're doing.


In general, it should be impossible for member functions to be 
considered strongly pure unless they're marked as immutable, 
though the compiler could certainly be improved to determine 
that no escaping of the return value or anything referencing 
it occurs within the function and that thus it can get away 
with treating the return value as if it's the only reference 
to that data, but that would likely be farther into the realm 
of code flow analysis than the compiler typically does.


It does. A bit. If S.arr is int[] the program fails to compile.
Is all prams being const(but not immutable) not enough for
function to be Pure?


Whether the function can be pure or not has nothing to do with 
const or immutable. All that pure means in and of itself is that 
the function cannot access any module-level or static variables 
whose state can ever change after they're initialized (though 
immutable is fine, and const is fine if there can't be any other 
references to the same data). So, every bit of state that can 
change over the course of the program that a pure function can 
access is through its arguments (which includes the invisible 
this pointer/reference in the case of member functions).


Now, depending on the types of the arguments, the compiler can do 
various optimizations. The most basic would be that if all of the 
arguments are immutable, then if the same values are given, the 
compiler can elide multiple calls - e.g. pureFunc(a) * 
pureFunc(a) could just call pureFunc once and then reuse the 
result rather than calling it twice as would occur normally.


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.


Regardless, your example definitely shows a bug. Please report 
it. Thanks.


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


Thanks.

- Jonathan M Davis

Re: How to warn of unused imports?

[Basile B. via Digitalmars-d-learn]

On Monday, 8 February 2016 at 08:50:17 UTC, Daniel Kozak wrote:

V Mon, 08 Feb 2016 08:25:09 +
cy via Digitalmars-d-learn  
napsáno:


When I factor out code from my modules, it really, really 
often leaves import statements that just sit there doing 
nothing, making it look like my program is more complex than 
it is. How do I get warned for leaving those, and a list of 
which ones I can safely remove?


I dont think there is a way right now. But in a future 
dscanner. https://github.com/Hackerpilot/Dscanner/issues/134


I don't think that Dscanner will be able to do this soon. Its 
scope is limited to a single module, it's not like DCD, which 
works with the imports and which is able to look-up elsewhere.


For example you'll see this if you try to make an analyzer that 
produces warnings for signed & unsigned comparison. It impossible 
without a bit of semantic (ref: 
https://github.com/Hackerpilot/Dscanner/issues/204).


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

[Issue 15658] isFile isn't a template

[via Digitalmars-d-bugs]

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

Cédric Picard  changed:

   What|Removed |Added

  Component|dmd |phobos

--

Re: Safe cast away from immutable

[Jesse Phillips via Digitalmars-d]

On Monday, 8 February 2016 at 19:07:01 UTC, Iakh wrote:

import std.stdio;

struct S
{
void[] arr;

auto f() pure @safe
{
int[] a = new int[4];
arr = a;
return a;
}
}
void main() @safe
{
S s;
immutable a = s.f();
int[] b = (cast(int[])s.arr);
writeln(a);
b[0] = 1;
writeln(a);
}

http://dpaste.dzfl.pl/13751913d2ff


I'm pretty sure this is not safe. Works, but not safe. You happen 
to be referencing the same memory block you created on the heap, 
but I believe the compiler is free to move the memory around if 
it can find a reason to do so.


Remember, when you cast the compiler is no longer protecting you. 
By modifying the array you're taking on the responsibility to 
know where that memory is located.

[Issue 15658] New: isFile isn't a template

[via Digitalmars-d-bugs]

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

  Issue ID: 15658
   Summary: isFile isn't a template
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: cpic...@openmailbox.org

I get a strange error when not using UFCS with isFile on a DirEntry with DMD
v0.270.0

To reproduce:

$ cat test.d
void main() {
import std.file, std.algorithm;
dirEntries("/tmp/", SpanMode.breadth).filter!(f => isFile(f));
}

$ dmd test.d
/usr/include/dlang/dmd/std/file.d(1743): Error: name.isFile isn't a
template
test.d(7): Error: template instance std.file.isFile!(DirEntry) error
instantiating
/usr/include/dlang/dmd/std/algorithm/iteration.d(985):instantiated
from here: __lambda2!(DirEntry)
/usr/include/dlang/dmd/std/algorithm/iteration.d(944):instantiated
from here: FilterResult!(__lambda2, DirIterator)
test.d(7):instantiated from here: filter!(DirIterator)


It is easy to circumvent though:

$ cat test2.d
void main() {
import std.file, std.algorithm;
dirEntries("/tmp/", SpanMode.breadth).filter!(f => f.isFile);
}
$ dmd test.d


--

[Issue 15658] isFile isn't a template

[via Digitalmars-d-bugs]

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

Cédric Picard  changed:

   What|Removed |Added

   Severity|enhancement |normal

--

Re: [suggestion] Automated one-stop compiler version chart

[Nick Sabalausky via Digitalmars-d]

On Sunday, 7 February 2016 at 21:26:36 UTC, Xinok wrote:
On Sunday, 7 February 2016 at 18:46:48 UTC, Nick Sabalausky 
wrote:
I was just updating a project's .travis.yml file and noticed: 
It doesn't seem we have any one-stop-shop location to check 
all the versions of DMD/LDC/GDC currently available on 
travis-ci.


It's be really nice if we had some auto-updated chart like 
that which ALSO listed the DMDFE, LLVM and GCC versions each 
LDC/GDC version is based on.


That info seems especially difficult to find for GDC. It's a 
little easier for LDC, since I found this page ( 
https://github.com/ldc-developers/ldc/releases ), but it'd be 
really nice to have just a simple chart somewhere.


The GDC downloads page has this info:
http://gdcproject.org/downloads



That page only has info for the latest GDC. I couldn't find the 
info for previous versions.

Re: Dconf 2015 talks...

[Joseph Rushton Wakeling via Digitalmars-d]

On Monday, 8 February 2016 at 00:54:24 UTC, Era Scarecrow wrote:
 Either they use more stack space, or they act normally after 
their call is done and are deallocated normally (automatically, 
unless they are passed outside of the scope where they were 
generated).


It's that "passed outside of the scope where they were generated" 
that is bothering me.


Consider:

auto foo (Range) (Range r)
if (isInputRange!Range)
{
return r.randomSample(100).take(10);
}

void main ()
{
iota(1000).foo.writeln;
}

If the RandomSample internals are allocated on the stack using 
the technique you propose, what's going to happen here?



 True; Perhaps have one RNG for seeding and one RNG for 
passing, then reseed after passing the function off, although 
how far deep some of this could go with it's deeper copying; I 
don't know.


No, I really don't think that's an approach that's worth 
pursuing, except as a desperate workaround for the faults of the 
existing design.  RNGs should as much as possible "just work" and 
the user shouldn't have to concern themselves like this with



 Perhaps RNG should be a class outright, which probably removes 
a lot of these problems.


It does indeed give you the desired reference semantics very 
cheaply.  But now suppose you have lots of RandomSamples being 
instantiated in the inner loop of your program.  If _they_ are 
also a class, how do you handle their instantiation and 
deallocation?

Safe cast away from immutable

[Iakh via Digitalmars-d]

import std.stdio;

struct S
{
void[] arr;

auto f() pure @safe
{
int[] a = new int[4];
arr = a;
return a;
}
}
void main() @safe
{
S s;
immutable a = s.f();
int[] b = (cast(int[])s.arr);
writeln(a);
b[0] = 1;
writeln(a);
}

http://dpaste.dzfl.pl/13751913d2ff

[Issue 15659] New: SList: clear() can cause crash

[via Digitalmars-d-bugs]

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

  Issue ID: 15659
   Summary: SList: clear() can cause crash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: sigod.m...@gmail.com

This code crashes:

import std.container.slist;

SList!int s;
s.clear();

--

[Issue 15659] SList: clear() can cause crash

[via Digitalmars-d-bugs]

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

--- Comment #1 from sigod  ---
https://github.com/D-Programming-Language/phobos/pull/3980

--

Re: dpaste and the wayback machine

[Jesse Phillips via Digitalmars-d]

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?

Andrei


I'm not sure if the wayback machine should be used for version 
control, if you want to keep a history of your past I suggest 
using a gist.github.com.


I view the wayback machine as a view for what the web used to 
look like not necessarily what information was in it.

Re: Safe cast away from immutable

[Iakh via Digitalmars-d]

On Monday, 8 February 2016 at 19:33:54 UTC, Jesse Phillips wrote:


I'm pretty sure this is not safe. Works, but not safe. You


So it is bug?

Re: An IO Streams Library

[Jason White via Digitalmars-d]

On Monday, 8 February 2016 at 07:50:33 UTC, Jakob Ovrum wrote:
I like what I've seen so far, but I'd just like to note that 
it's easier to give feedback on the API when there is web 
documentation. GitHub Pages would be a natural place to host it.


A lot of D libraries on GitHub do this and not everyone uses 
the same tools, but for one example, here's LuaD[1] with 
reference documentation on GitHub pages, automatically 
generated and pushed by Travis-CI for the master branch.


https://github.com/JakobOvrum/LuaD


Done: https://jasonwhite.github.io/io/

(Nice work on bootDoc!)

I haven't tied it in with the Travis build yet, but that 
shouldn't be too hard to do.


Pretty docs typically helps motivate me to write more.

Re: An IO Streams Library

[Jason White via Digitalmars-d]

On Monday, 8 February 2016 at 12:02:08 UTC, Kagamin wrote:
In the output stream you compare output data length to the 
input data length. In case of a transcoding stream they can be 
different. Are you trying to account for partial writes?


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.

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

[Nick Sabalausky via Digitalmars-d]

On Sunday, 7 February 2016 at 23:26:05 UTC, Andrei Alexandrescu 
wrote:

On 02/04/2016 09:46 PM, Tofu Ninja wrote:
On Thursday, 4 February 2016 at 15:33:41 UTC, Andrei 
Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/3971 -- 
Andrei


People one github were asking for a dump function so they 
could do

  int a = 5;
  dump!("a"); // prints "a = 5"


Here's a working version if anyone wants it but you have to 
use it like

  mixin dump!("a");


//

mixin template dump(Names ... )
{
 auto _unused_dump = {
 import std.stdio : writeln, write;
 foreach(i,name; Names)
 {
 write(name, " = ", mixin(name), 
(i

Re: Safe cast away from immutable

[Iakh via Digitalmars-d]

On Monday, 8 February 2016 at 21:48:30 UTC, Jonathan M Davis 
wrote:



that right now, but clearly, what it currently has is buggy,


Yeah. Looks like it just traverse params's AST and search for
exactly match with ReturnType.

The code with replaced (void, int) with (class A, class B : A)
behaves the same way as original:

import std.stdio;

class A
{
int i;
}

class B : A
{
}

struct S
{
A a;

auto f() pure @safe
{
B b = new B;
a = b;
return b;
}
}

void main() @safe
{
S s;
immutable a = s.f();
A b = s.a;
writeln(a.i);
b.i = 1;
writeln(a.i);
}

Re: Things that keep D from evolving?

[Laeeth Isharc via Digitalmars-d-learn]

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:

On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:


I see... By any chance, can we solve this issue with GC 
managed pointers?


Maybe we could.  But it's never going to happen.  Even if 
Walter weren't fundamentally opposed to multiple pointer types 
in D, it wouldn't happen.


You asked about things that prevent improvement, right?  Here's 
the big one, and a major point of friction in the community: 
Walter and Andrei refuse to break existing code in pursuit of 
changes that substantially improve the language.  (Never mind 
that code tends to break anyway.)


-Wyatt


I have no special knowledge but strikes this observer that they 
are serious about working on solutions (whether that's a better 
GC or alternatives or both).  But some patience required as its 
not such a straightforward problem and its better to take time 
than rush and make a mistake.  It wasn't all that long ago that 
Andrei quit and I guess he moved across country and it certainly 
takes time to sort out one's home office and find a new working 
pattern.


The discussions in the mailing list are quite interesting 
although beyond my technical knowledge for now.


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.

Re: in a template argument, specify which object member to access?

[cy via Digitalmars-d-learn]

This is what I have so far. Using mixin(rawstring~templatearg) 
for every time I access the member is kind of cludgy though.


struct A {
string up;
string down;
string left;
string right;
}

template goPlaces(string D1, string D2, string D3) {
string goPlaces(ref A a) {
mixin("a."~D2) = "deetoo";
return "go " ~
mixin("a."~D1) ~ " then go " ~
mixin("a."~D2) ~ " then go " ~
mixin("a."~D3);   
}
}

void main() {
import std.stdio;
A a = {"north","south","east","west"};
writeln(goPlaces!("up","left","down")(a));
writeln(a.left);
}


top postinglol

On Monday, 8 February 2016 at 21:09:47 UTC, cy wrote:
object.member lets me access the member of the object, but what 
if I want to access those members in a generic way, but in a 
different arrangement depending on context? Like if I wanted to 
first follow a tree down, and second priority would be going 
left to right, but then I wanted to first go right, and second 
priority would be going down to up.


struct A {
string up;
string down;
string left;
string right;
}

template goPlaces(D1,D2,D3) {
string go(A a) {
return "go " ~ a.D1 ~ " then go " ~ a.D2 ~ " then go " ~ a.D3;
}
}

import std.stdio;

void main() {
A a = {"north","south","east","west"};
writeln(goPlaces!(up,down,left)(a));
}

Do I just have to use a mixin? Or implement those members as 
indexes in an array, if I want to use them differently?


enum Way { UP, DOWN, LEFT, RIGHT };
struct A {
string[Way.max+1] ways;
}
...

Re: in a template argument, specify which object member to access?

[cy via Digitalmars-d-learn]

On Monday, 8 February 2016 at 22:38:45 UTC, Mengu wrote:

i believe you can use __traits(getMember) there.


Great! Should have refreshed before sending that reply...

I wonder if mixin("a."~member) is better or worse than 
__traits(getMember,a,member)...

Re: Google Summer of Code 2016

[Dragos Carp via Digitalmars-d]

On Monday, 8 February 2016 at 13:25:38 UTC, CraigDillabaugh wrote:
Awesome! Thanks.  I will write up something on the idea's page 
in the next day or two (which you are welcome to edit of 
course).  Also, if a student were interested in working on 
Protocol Buffers, would there be opportunities there too?


There is still some pending work regarding Protocol Buffers:
- native support for the so called "well known" types
- optimization of non-recursive messages
- comments and deprecate field handling
- benchmarking
- json support

Re: Safe cast away from immutable

[Jesse Phillips via Digitalmars-d]

On Monday, 8 February 2016 at 20:07:49 UTC, Iakh wrote:
On Monday, 8 February 2016 at 19:33:54 UTC, Jesse Phillips 
wrote:



I'm pretty sure this is not safe. Works, but not safe. You


So it is bug?


Yeah, I missed a couple items of your code. You'd marked the 
functions @safe, and also the cast(int[]) was to convert void[] 
not to cast away an immutable.

Re: Safe cast away from immutable

[anonymous via Digitalmars-d]

On 08.02.2016 22:14, Iakh wrote:

Is all prams being const(but not immutable) not enough for
function to be Pure?


The hidden `this` parameter must be const, too. And mutable indirections 
in the return type must be considered.


This article explains it in detail:
http://klickverbot.at/blog/2012/05/purity-in-d/

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

[via Digitalmars-d-bugs]

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

--- Comment #1 from Iakh  ---
Also this works

import std.stdio;

class A
{
int i;
}

class B : A {}
struct S
{
A a;

auto f() pure @safe
{
B b = new B;
a = b;
return b;
}
}

void main() @safe
{
S s;
immutable a = s.f();
A b = s.a;
writeln(a.i);
b.i = 1;
writeln(a.i);
}

--

Re: An IO Streams Library

[Chris Wright via Digitalmars-d]

On Mon, 08 Feb 2016 18:52:52 +, Atila Neves wrote:

> On Monday, 8 February 2016 at 17:11:56 UTC, Chris Wright wrote:
>> On Mon, 08 Feb 2016 12:19:59 +, Atila Neves wrote:
>>
>>> On Monday, 8 February 2016 at 09:08:53 UTC, Dejan Lekic wrote:
 [...]
>>> 
>>> I like boost. Well, sometimes. I _severely_ dislike boost::asio.
>>> The new couroutines may make it easier to use, I'd have to try 1st,
>>> but what's the point when vibe.d exists?
>>> 
>>> Atila
>>
>> I can't use vibe.d for one of my projects because I need to keep tight
>> control of coroutine scheduling. Better async IO routines in Phobos
>> would help me -- though I'm mainly looking for higher level stuff, like
>> a telnet handler.
> 
> You can always use fibers yourself and just do the IO there. It's
> cooperative multithreading so you control when one of them yields.

Which is exactly what I'm doing now.

The point is, it's useful to have multiple types of concurrency handling 
with IO, and async IO that's likely to end up in Phobos doesn't 
necessarily obviate vibe.d or duplicate work.

Re: in a template argument, specify which object member to access?

[Mengu via Digitalmars-d-learn]

On Monday, 8 February 2016 at 21:09:47 UTC, cy wrote:
object.member lets me access the member of the object, but what 
if I want to access those members in a generic way, but in a 
different arrangement depending on context? Like if I wanted to 
first follow a tree down, and second priority would be going 
left to right, but then I wanted to first go right, and second 
priority would be going down to up.


[...]


i believe you can use __traits(getMember) there.

Re: in a template argument, specify which object member to access?

[Mengu via Digitalmars-d-learn]

On Monday, 8 February 2016 at 22:46:06 UTC, cy wrote:

On Monday, 8 February 2016 at 22:38:45 UTC, Mengu wrote:

i believe you can use __traits(getMember) there.


Great! Should have refreshed before sending that reply...

I wonder if mixin("a."~member) is better or worse than 
__traits(getMember,a,member)...


i think it's a matter of taste and here's how i would do it:

import std.stdio;
import std.array;

struct A {
  string up;
  string down;
  string left;
  string right;
}

string goPlaces(args...)(A a) {
  string[] result;
  foreach (arg; args) {
result ~= __traits(getMember, a, arg);
  }
  return "go " ~ result.join(" then go ");
}

void main() {
  A a = {"north", "south", "east", "west"};
  writeln(goPlaces!("up", "down", "left")(a));
  writeln(goPlaces!("down", "right", "left", "up")(a));
}

// outputs
// go north then go south then go east
// go south then go west then go east then go north

[Issue 15661] New: Destructor called while object still alive

[via Digitalmars-d-bugs]

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

  Issue ID: 15661
   Summary: Destructor called while object still alive
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: matt.elk...@gmail.com

In the code below the TileView destructor is called twice (see the output at
the bottom). The first call of the destructor appears to occur while the
TileView object is still alive. The expected output (also listed at the bottom)
occurs if any of a number of changes are made to the code, including but
probably not limited to:
* Creating the TextureHandles directly rather than calling create()
* Using only one argument to TileView's constructor
* Removing TextureHandle's empty destructor

This is on DMD 2.070 32-bit, running on 64-bit Windows 7.

[code]
import std.stdio;

struct TextureHandle
{
~this() {}
}

TextureHandle create() {return TextureHandle();}

 struct TileView
 {
 @disable this();
 @disable this(this);
 this(TextureHandle a, TextureHandle b) {}
 ~this() {writeln("HERE2");}
 }

 struct View
 {
 this(int)
 {
 writeln("HERE1a");
 m_tileView = TileView(create(), create());
 writeln("HERE1b");
 }

 private TileView m_tileView;
}

unittest
{
auto v = View(5);
}
[/code]

[output]
HERE1a
HERE2
HERE1b
HERE2
[/output]

[expected_output]
HERE1a
HERE1b
HERE2
[/expected_output]

--

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

[via Digitalmars-d-bugs]

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

  Issue ID: 15662
   Summary: Cannot move struct with defined opAssign due to
@disabled post-blit
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: matt.elk...@gmail.com

Given the following definition:

[code]
import std.algorithm;

struct ResourceHandle(T, alias Deleter, T Default = T.init)
{
// Constructors/Destructor
this(T handle) {m_handle = handle;}
@disable this(this);
~this() {Deleter(m_handle);}

// Operators
@disable void opAssign(ref ResourceHandle lvalue);
ref ResourceHandle opAssign(ResourceHandle rvalue) {swap(m_handle,
rvalue.m_handle); return this;}

// Methods
@property inout(T) handle() inout {return m_handle;}
@property T handle(T handle) {Deleter(m_handle); m_handle = handle; return
m_handle;}
T release() {T result = m_handle; m_handle = Default; return result;}

private:
T m_handle = Default;
}
[/code]

The following will generate a compile error, making it awkward to move unique
resources:

[code]
unittest
{
alias RH = ResourceHandle!(uint, (uint) {});
RH[] handles;
handles ~= RH(5); // Compile error: ResourceHandle is not copyable because
it is annotated with @disable
}
[/code]

See discussion at
https://forum.dlang.org/post/nnjfuqeuprcswsjjf...@forum.dlang.org

At first I was uncertain whether this was a bug or by design, but Andrei
Alexandrescu confirmed the bug status in the linked discussion.

--

Re: Odd Destructor Behavior

[Matt Elkins via Digitalmars-d-learn]

On Monday, 8 February 2016 at 07:31:07 UTC, Daniel Kozak wrote:

Seems to me too, please report it on issues.dlang.org


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

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

[Matt Elkins via Digitalmars-d]

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

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

[tsbockman via Digitalmars-d-learn]

On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
What I like most about your proposal is that it doesn't break 
any existing code that wasn't broken before. That can't be 
emphasized enough.


Although I wish more than 3 people had voted in my poll, two of 
them did claim to need the `ref`-ness of `Tuple.slice`, so I 
don't think we can just ditch it. (I did not vote.)


If you guys want to add a return-by-value version, it should be 
treated as an enhancement, not a bug fix in my opinion.

Challenge: fair partition function

[Andrei Alexandrescu via Digitalmars-d]

Consider defining a function that partitions a range around a given 
index like this:


size_t pivotPartition(alias less = (a, b) => a < b, Range)
(Range r, size_t pivot);

Returns x, one of the the indexes that r[pivot] would have if r were 
sorted. Also, r[0 .. x] contains stuff no greater than r[x] and r[x + 1 
.. $] contains stuff no less than r[x].


The challenge is to implement such a function with fairness: if several 
elements are equal to r[pivot], return the index closest to r.length / 2.


The function should be efficient, minimize calls to less and swap, etc. 
A variant that is efficient but does not implement fairness is below.



Andrei


size_t pivotPartition(alias less = (a, b) => a < b, Range)
(Range r, size_t pivot)
{
assert(pivot < r.length || r.length == 0 && pivot == 0);
if (r.length <= 1) return 0;
import std.algorithm : swapAt;
r.swapAt(pivot, 0);
size_t lo = 1, hi = r.length - 1;
loop: for (;;)
{
for (;; ++lo)
{
if (lo > hi) break loop;
if (less(r[0], r[lo])) break;
}
// found the left bound
assert(lo <= hi);
for (;; --hi)
{
if (lo == hi) break loop;
if (less(r[hi], r[0])) break;
}
// found the right bound, swap & make progress
r.swapAt(lo++, hi--);
}
--lo;
r.swapAt(lo, 0);
return lo;
}