date:20130309

Am Thu, 07 Mar 2013 19:53:29 +0400
schrieb Denis Shelomovskij verylonglogin@gmail.com:

 07.03.2013 14:28, Jacob Carlborg пишет:
  On 2013-03-07 11:12, Moritz Maxeiner wrote:
 
  Sorry if this has been answered before/is common knowledge, but is
  porting functions at a time to C wanted for optlink in general, or
  only for finding segfaults? (e.g. are pull-requests for that
  welcome)
 
  Yes, in general. I think the idea is to port the whole Optlink to C
  and then to D. It's easier to port from C to D than from assembly
  to D. This is because you can use a C version that doesn't use the
  runtime or standard library to get the generate assembly as close
  as possible to the original one. I think it was something like that.
 
 
 Didn't get. You don't have to use D with druntime. Just don't link it 
 and everything will be OK - you will just get better C (i.e. with D 
 structs and other good stuff).
 

That's a little bit oversimplified. Even a simple POD struct references
the TypeInfo_Struct declaration in druntime. There's still some
compiler work needed to really make D usable without druntime. (Think
of issues like these: If you don't have druntime - you don't have
typeinfo - no D style varargs - no associative arrays; you can't even
compare normal arrays 
(https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/adi.d#L368))

Re: C++ guys hate static_if?

2013-03-09 Thread Jouko Koski


Walter Bright  wrote:

Many of the criticisms in the paper are addressed by our positive 
experience with static if in D.


Sometimes I do find it confusing that { does or does not introduce a new 
scope in a very similar-looking contexts.


--
Jouko

Re: Optlink is on github

2013-03-09 Thread Dicebot

On Saturday, 9 March 2013 at 09:11:54 UTC, Johannes Pfau wrote:

Am Thu, 07 Mar 2013 19:53:29 +0400
schrieb Denis Shelomovskij verylonglogin@gmail.com:

07.03.2013 14:28, Jacob Carlborg пишет:
On 2013-03-07 11:12, Moritz Maxeiner wrote:

Sorry if this has been answered before/is common knowledge,
but is
porting functions at a time to C wanted for optlink in
general, or

only for finding segfaults? (e.g. are pull-requests for that
welcome)

Yes, in general. I think the idea is to port the whole
Optlink to C
and then to D. It's easier to port from C to D than from
assembly
to D. This is because you can use a C version that doesn't
use the
runtime or standard library to get the generate assembly as
close
as possible to the original one. I think it was something
like that.

Didn't get. You don't have to use D with druntime. Just don't
link it and everything will be OK - you will just get better
C (i.e. with D structs and other good stuff).

That's a little bit oversimplified. Even a simple POD struct
references

the TypeInfo_Struct declaration in druntime. There's still some
compiler work needed to really make D usable without druntime.
(Think
of issues like these: If you don't have druntime - you don't
have
typeinfo - no D style varargs - no associative arrays; you
can't even
compare normal arrays
(https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/adi.d#L368))

It can be easily checked with -betterC -defaultlib= combo. You
can skip phobos, druntime, use only C stdlib and look what will
remain working in the language. Not much.

Re: C++ guys hate static_if?

2013-03-09 Thread simendsjo


On Saturday, 9 March 2013 at 09:12:30 UTC, Jouko Koski wrote:

Walter Bright  wrote:

Many of the criticisms in the paper are addressed by our 
positive experience with static if in D.


Sometimes I do find it confusing that { does or does not 
introduce a new scope in a very similar-looking contexts.


Is there more constructs than static if that doesn't create a 
scope?

Re: C++ guys hate static_if?


On Saturday, 9 March 2013 at 09:41:42 UTC, simendsjo wrote:

On Saturday, 9 March 2013 at 09:12:30 UTC, Jouko Koski wrote:

Walter Bright  wrote:

Many of the criticisms in the paper are addressed by our 
positive experience with static if in D.


Sometimes I do find it confusing that { does or does not 
introduce a new scope in a very similar-looking contexts.


Is there more constructs than static if that doesn't create a 
scope?


version, debug, release, const/immutable/inout/static/whatever{} .

Re: Migrating dmd to D?

2013-03-09 Thread John Colvin


Coventryday, 9 March 2013 at 09:08:09 UTC, Russel Winder wrote:

On Thu, 2013-03-07 at 19:03 +0100, Kagamin wrote:
[…]
According to distrowatch Ubuntu and Mint are more popular than 
Debian, and Ubuntu allows proprietary software like Opera 
browser and Nvidia drivers, so dmd won't be a problem too. Why 
Debian policies should be an issue?


As Jeff pointed out, Debian is the base for Ubuntu, Mint, and 
others so
if you get in Debian you are in Ubuntu, Mint, etc. It is 
possible to get
into Ubuntu, Mint, etc. separately but then you have many 
channels

instead of just the one.

Debian also allows proprietary software such as NVIDIA drivers, 
it is
just that they are in the non-free repository instead of the 
free
repository. Non-free is not available by default in Debian but 
it is
there. I use it all the time for NVIDIA drivers and some other 
stuff.


A similar thing exists in fedora and redhat country: rpmfusion.

It has free and non-free branches containing a handful of 
packages fed and rh won't include in the main repos for licence 
reasons. Many people use it for nvidia drivers

Re: C++ guys hate static_if?

2013-03-09 Thread simendsjo


On Saturday, 9 March 2013 at 09:52:55 UTC, deadalnix wrote:

On Saturday, 9 March 2013 at 09:41:42 UTC, simendsjo wrote:

On Saturday, 9 March 2013 at 09:12:30 UTC, Jouko Koski wrote:

Walter Bright  wrote:

Many of the criticisms in the paper are addressed by our 
positive experience with static if in D.


Sometimes I do find it confusing that { does or does not 
introduce a new scope in a very similar-looking contexts.


Is there more constructs than static if that doesn't create a 
scope?


version, debug, release, 
const/immutable/inout/static/whatever{} .


I see const++ as well as property as qualifiers and don't assume 
a new scope.

Didn't think of version++ though :)

Re: Migrating dmd to D?


On Saturday, 9 March 2013 at 09:08:09 UTC, Russel Winder wrote:
Debian also allows proprietary software such as NVIDIA drivers, 
it is
just that they are in the non-free repository instead of the 
free
repository. Non-free is not available by default in Debian but 
it is
there. I use it all the time for NVIDIA drivers and some other 
stuff.


The support is clearly not as good. I got into an argument few 
month ago with some debian maintainers. The topic was that it was 
impossible to compile wine on a machine with the nvidia drivers. 
I came up with the issue, and even a fix, a receive basically a 
GTFO, we don't care about making a soft to run non free software 
using non free driver.


I took several month (maybe more than a year) for the issue to be 
solved, in a very similar manner to what I proposed in the first 
place. I'm not the only one that had similar issues.


Debian is not per se against non free, but some maintainers are, 
and it does matter.

Re: Optlink is on github

Am Sat, 09 Mar 2013 10:32:18 +0100
schrieb Dicebot m.stras...@gmail.com:

On Saturday, 9 March 2013 at 09:11:54 UTC, Johannes Pfau wrote:
Am Thu, 07 Mar 2013 19:53:29 +0400
schrieb Denis Shelomovskij verylonglogin@gmail.com:

07.03.2013 14:28, Jacob Carlborg пишет:
On 2013-03-07 11:12, Moritz Maxeiner wrote:

Sorry if this has been answered before/is common knowledge,
but is
porting functions at a time to C wanted for optlink in
general, or
only for finding segfaults? (e.g. are pull-requests for that
welcome)

Didn't get. You don't have to use D with druntime. Just don't
link it and everything will be OK - you will just get better
C (i.e. with D structs and other good stuff).

That's a little bit oversimplified. Even a simple POD struct
references
the TypeInfo_Struct declaration in druntime. There's still some
compiler work needed to really make D usable without druntime.
(Think
of issues like these: If you don't have druntime - you don't
have
typeinfo - no D style varargs - no associative arrays; you
can't even
compare normal arrays
(https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/adi.d#L368))

It can be easily checked with -betterC -defaultlib= combo. You
can skip phobos, druntime, use only C stdlib and look what will
remain working in the language. Not much.

I know that, I've run D code on the DS without druntime and on
Android as well, but betterC only disables moduleinfo, not typeinfo. So
you don't even get structs without druntime and that is certainly not
better than C.

test.d:
---
struct A
{
}
---

dmd -betterC -defaultlib= -c test.d
nm test.o
U _D15TypeInfo_Struct6__vtblZ

Re: Migrating dmd to D?

2013-03-09 Thread Russel Winder

On Sat, 2013-03-09 at 11:14 +0100, deadalnix wrote:
[…]
 Debian is not per se against non free, but some maintainers are, 
 and it does matter.

This latter point is Debian's biggest problem, and actually it is worse
than that in some cases. This is why having Debian maintainers
maintaining D packages who are positively associated with D is
important.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


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

Re: Optlink is on github

2013-03-09 Thread Dicebot

Ye, sure, I wanted to support your point with practical example, 
not object it by any means. By the way, templates and array 
literals I have tried were doomed, too :)

Re: C++ guys hate static_if?

2013-03-09 Thread Artur Skawina

On 03/09/13 05:34, H. S. Teoh wrote:
 On Fri, Mar 08, 2013 at 07:50:26PM -0800, Walter Bright wrote:
 On 3/8/2013 5:19 PM, Brad Anderson wrote:
 On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
  Are they full of it? Has it caused the problems they mention
 in
 D?

 Well, the two guys with an alternative proposal (concepts-lite) seem
 to hate static if (along with a third guy).

 There seems to be a lot of strawman arguments in this paper.

 Many of the criticisms in the paper are addressed by our positive
 experience with static if in D.
 
 I didn't read the paper, but I have to say that static if in D has been
 extremely, extremely useful in my code. Now that I've become acquianted
 with it, I can't live without it. It's pretty much a necessity when
 writing heavily-templated code. But given C++'s broken template design,
 I can see why its value may not have been appreciated by some people.
 
 D may still have its warts, but in terms of being a better C++, I
 think it has done a superb job, especially in the area of templates and
 compile-time mechanisms. Static if + CTFE + sane template syntax =
 readable template code = total win for D over C++.


Let me quote a paragraph from that paper:
 Being a new and realtively simple-to-use new feature, static_if would un-
 doubtedly be used by many who have no need for the relatively small increme-
 natal improvement in performance offered. The library writers for which such
 techniques really are important, already have to tools and skills needed.

No skilled Real Programmer would ever use a language feature that was simple
to use.

Seriously though, they point out several problems, some of which are C++
context specific (like mixing CPP w/ static-if and lack of introspection).
Other mentioned issues are not real problems in practice, or not even
problems at all.

What's left is:
 - static-if not creating scopes /is/ confusing, but what would be a better
   alternative?
 - (static-)if in templates or as template constraints - 
a) prevents pre-instantiation verification - true, applies to D, but
 not really a big problem, assuming sane application of static-if,
b) make constraint-based overloading ugly and fragile - true, something
 better is needed for D too. But until that exists, careful use
 of constraints mostly works.

artur

Re: Optlink is on github

Am Sat, 09 Mar 2013 11:35:42 +0100
schrieb Dicebot m.stras...@gmail.com:

 Ye, sure, I wanted to support your point with practical example, 
 not object it by any means. By the way, templates and array 
 literals I have tried were doomed, too :)

Really, templates also don't work? There's a lot of work required till
betterC is finished...

Re: Optlink is on github

Am Sat, 09 Mar 2013 11:35:42 +0100
schrieb Dicebot m.stras...@gmail.com:

 Ye, sure, I wanted to support your point with practical example, 
 not object it by any means. By the way, templates and array 
 literals I have tried were doomed, too :)

Sorry, I misunderstood that then.

Re: C++ guys hate static_if?


On Saturday, 9 March 2013 at 09:41:42 UTC, simendsjo wrote:

On Saturday, 9 March 2013 at 09:12:30 UTC, Jouko Koski wrote:

Walter Bright  wrote:

Many of the criticisms in the paper are addressed by our 
positive experience with static if in D.


Sometimes I do find it confusing that { does or does not 
introduce a new scope in a very similar-looking contexts.


Is there more constructs than static if that doesn't create a 
scope?


Labeled scopes (ironically) don't create scopes. Eg:

//
some_label:
{
int a;
//Code code code
}
a = 5;
goto some_label;
//

That doesn't actually create a new scope, and that assignement is 
legal game.


This is from the official documentation, so it is not a bug. I 
can't, for the  life of me, understand why it is that way, in 
particular, since it deviates from C. I see it as a never 
better, sometimes worst approach.


I've tried to ask about it before, but I best, the answer I got 
was works as documented, but still have no idea on the why :/ 
???


And since goto is evil, I think very few people care, so 
getting any kind of activity about this is hard.

std.concurrency: layout-dependent problem with sending structs

2013-03-09 Thread thedeemon

Found a strange bug where when trying to send a message of some 
struct the sender thread silently dies. However with different 
struct layout everything works fine. I'm using DMD 2.062 under 
Windows. Here's a code sample:


import std.concurrency, std.stdio, core.time;

struct Msg {
string name;
int sz;
double progress;
}

void myfun(Tid tid)
{
writeln(10);
tid.send(Msg(a, 123, 0.2));
writeln(20);
}

void main(string[] argv)
{
int[] arr = [1,2,3];
spawn(myfun, thisTid);

void RcvMsgAnalyzing(Msg m)
{
writeln(m.sz);
}

while(true) {
while(receiveTimeout(dur!msecs(100), RcvMsgAnalyzing)) {}
}
}

When run like this it prints 10 and then nothing happens, and 
the Task Manager shows there is only 1 thread working after that. 
But if you comment out any field of Msg struct leaving the other 
two (and correct Msg instance creation) then it works just fine, 
the message gets delivered and worker thread function runs to its 
end.


Debugger shows something goes wrong at concurrency.d line 572:
tid.mbox.put( msg );
Something inside variant.d goes mad but I haven't figured out yet 
what exactly.

Re: std.concurrency: layout-dependent problem with sending structs

2013-03-09 Thread thedeemon


On Saturday, 9 March 2013 at 11:56:14 UTC, thedeemon wrote:

struct Msg {
string name;
int sz;
double progress;
}


BTW if I change double to float everything works fine.

Re: C++ guys hate static_if?


On 3/8/13 7:48 PM, DypthroposTheImposter wrote:

See the static_if paper here:

http://isocpp.org/forums

Under the post constraints and static if there is a link to a
document about
static_if

https://docs.google.com/viewer?a=vpid=forumssrcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg


Are they full of it? Has it caused the problems they mention
in
D?


Wow. That's quite out of character for Bjarne. I think it's quite a poor 
piece.


Andrei

Re: C++ guys hate static_if?

2013-03-09 Thread d coder

Greetings

I believe the paper takes a contrived route to criticize static if. It
takes some bad code examples which are not obvious use cases of static if
and then goes on to say that the resultant code is not good. I think the
code example to begin with was not good.

Regards
- Puneet

Re: Error: 0xc0000005, Dmd Win 64

2013-03-09 Thread Michael


Crash also occurs when

int[] a;
a.length = 10;

So, it's maybe something wrong with ms c runtime of VS 2012.

Just installed Update 2 for VS 2012, not helps.

Re: C++ guys hate static_if?

On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu 
wrote:

On 3/8/13 7:48 PM, DypthroposTheImposter wrote:

See the static_if paper here:

http://isocpp.org/forums

Under the post constraints and static if there is a link to a
document about
static_if

https://docs.google.com/viewer?a=vpid=forumssrcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg


Are they full of it? Has it caused the problems they mention
in
D?


Wow. That's quite out of character for Bjarne. I think it's 
quite a poor piece.


Andrei


I think there is a bit of forced bashing in there, but the main 
point is that static if prevents eager semantic validation of 
templated code. In C++, if you write a semantically incorrect 
template, then the compiler can catch it. This is not possible 
once static ifs enter the picture.


I know for a fact I've had the C++ compiler catch a fair amount 
of errors for me, whereas it takes actual intantiation for the D 
compiler to catch said errors (and I've seen a few such errors in 
phobos).


I think the main point is not is static if good or not: I think 
D has clearly demonstrated how powerful it can be. However, to 
the question of is it the right move for C++, whith all of its 
heritage, to adopt static if? As a C++ developper, honestly, I'm 
not sure it is. I think that's where the piece is comming from, 
in maybe a clumsy manner.


C++ took a different road with its horrible template syntax, 
but it took that road. I think it is better to improve that road 
(with concepts, for example), then try to move the current 
paradigm.


That's might point of view having mostly a full C++ background, 
and having learned D. The bottom line, I think, is that it is an 
error to think of D as just improved C++, and that what might 
work for D might not be what is best for C++. It doesn't mean 
that static if (or other D constructs) are bad in and out of 
themselves. I wouldn't take this piece as a direct attack on D.


...

BTW, in regards to template constraints (not the rest), he does 
have a point. We have raised the exact same issues here on the 
boards more than once.

Re: C++ guys hate static_if?

2013-03-09 Thread Era Scarecrow


On Saturday, 9 March 2013 at 14:49:36 UTC, d coder wrote:

Greetings

I believe the paper takes a contrived route to criticize 
static if. It takes some bad code examples which are not 
obvious use cases of static if and then goes on to say that 
the resultant code is not good. I think the code example to 
begin with was not good.


Agreed. Just barely started reading it and it appears they're 
nit-picking about something they would have trouble with if it 
was scoped or not, but more importantly they aren't considering 
something we would do automatically. If you declare in one, you 
declare in the other, only difference may be a few details like 
storage types, removing some of the problems entirely; So he's 
attacking something that could be done in the preprocessor 
anyways; Or maybe he's attacking bad coding style but isn't 
expressly saying it?


[quote]
Conditional compilation, the selective inclusion of statements in 
a translation unit, is a conventional example. Consider a simple 
example of introducing some declarations, depending on whether 
the size of some type, T.


  static if (sizeof(T)==8) {
void fun();
void gun(int);
  } else {
void gun();
typedef tx int;
  }

The semantics of the program are this: if sizeof(T)==8, the 
compiler will parse the statements in the “then” branch, and will 
tokenize and brace-match the declarations in the else branch. 
Those other declarations would be uninterpreted by the compiler.


Note that unlike normal if statements, the braces enclosing the 
conditionally compiled statements do not introduce a new scope. 
Those declarations are declared into the scope enclosing the 
static if block. This difference makes
code written using static if harder to read and 
understand—modulating between static and non-static ifs in a 
single block provides ample opportunities for confution and 
mistakes.


The effect of this declaration is to conditionally modify the 
current scope with a set of new declarations. How can we know, 
later in the program, which version of gun we should use, or 
whether tx is defined or not? Any use of those

declarations would also need to be wrapped.

  static if (sizeof(T)==8)
gun(32);
  else
gun();
  static if (sizeof(T)==8) {
long n = x;
  }
  static if (sizeof(T)!=8) {
tx n = x;
  }

Thus, the use of static_if for conditional compilation is viral.
The impact of conditional parsing on program analysis tools is 
substantial. While the feature may be easily implemented as part 
of the translation process, program analysis tools have 
traditionally struggled with conditional declarations. The 
inclusion of multiple variants (via, e.g., preprocessor 
conditions) and simultaneous repersentation within a single 
program model is still an open problem in the source code 
analysis communities. Adopting static if will make analysis 
harder, not easier.

[/quote]

 And I'm sure that using the preprocessor keeps things simple 
right? Geez let's take a C/C++ version of that... Preprocessor 
tokens may be off, but the point should get across... :P


  #ifdef X
void fun();
void gun(int);
  #else
void gun();
typedef tx int;
  #endif

 And

  #ifdef X
gun(32);
  #else
gun();
  #endif
  #ifdef X
long n = x;
  #endif
  #ifndef X
tx n = x;
  #endif

[quote]
We have already heard suggestions of static_for and static_while. 
Can static_switch be far behind? C++ would become a low-level, 
unprincipled hackers’ favorite playground. In our opinion, if you 
want compile-time computation, look to constexpr, which does have 
a sane and typesafe underlying model.


If we do not provide a static_for, hackers will simply make one 
out of static_if or fake equivalents.

[/quote]

 C++ is just as low level as C, this statement is useless. Being 
against 'static_for' is kinda dumb since if you think about it, 
it just unrolls the loop ahead of time instead of optimization, 
other than that it shouldn't do anything odd. I'll agree not to 
add static_for only because it's not really needed.


[quote]
The semantics of static_if are to tokenize the branch not taken. 
If the condition is dependent, as it is in the statements above, 
then the compiler must not parse either branch. Both branches are 
tokenized since either one could
contain compiler-specific extensions—or both, or neither. That 
won’t be known until both branches would have been fully parsed.


snip

Consider the real world impact of this design choice. The 
inability of the compiler to parse the branches of the compiler 
means that the library writer will need to instantiate every 
branch of the template just to ensure that the syntax is correct 
and that no spelling errors have been made. Today, this is done, 
to a large extent, by the compiler

[/quote]

 In C++ you need to have EVERYTHING loaded (declarations, etc) 
loaded before you can compile anything, Unlike in D where all 
tokens effectively have one meaning as intended, so the whole

Re: C++ guys hate static_if?


On 3/9/13 10:22 AM, monarch_dodra wrote:

BTW, in regards to template constraints (not the rest), he does have a
point. We have raised the exact same issues here on the boards more than
once.


What was the problem for D again?

Andrei

Re: The new std.process is ready for review

On Wednesday, 6 March 2013 at 16:45:51 UTC, Steven Schveighoffer 
wrote:
On Tue, 05 Mar 2013 17:38:09 -0500, Vladimir Panteleev 
vladi...@thecybershadow.net wrote:


By the way, I should mention that I ran into several issues 
while trying to come up with the above example. The test 
program does not work on Windows, for some reason I get the 
exception:


std.process2.ProcessException@std\process2.d(494): Failed to 
spawn new process (The parameter is incorrect.)


I think Lars is on that.


I'm going to need som help with this one.  I only have Linux on 
my computer, and I can't reproduce the bug in Wine.


As a first step, could someone else try to run Vladimir's test 
case?




I've also initially tried writing a different program:

[...]


Linux should work here.  From what I can tell, you are doing it 
right.


If I get some time, I'll try and debug this.


I think I know what the problem is, and it sucks bigtime. :(

Since the child process inherits the parent's open file 
descriptors, both ends of a pipe will be open in the child 
process.  We have separated pipe creation and process creation, 
so spawnProcess() knows nothing about the other end of the pipe 
it receives, and is therefore unable to close it.


In this particular case, the problem is that sort doesn't do 
anything until it receives EOF on standard input, which never 
happens, because even though the write end of the pipe is closed 
in the parent process, it is still open in the child.


I don't know how to solve this in a good way.  I can think of a 
few alternatives, and they all suck:


1. Make a special spawnProcess() function for pipe redirection.
2. Use the process object approach, like Tango and Qt.
3. After fork(), in the child process, loop over the full range 
of possible file descriptors and close the ones we don't want 
open.


The last one would let us keep the current API (and would have 
the added benefit of cleaning up unused FDs) but I have no idea 
how it would impact performance.


Lars

Re: C++ guys hate static_if?

On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu 
wrote:
Wow. That's quite out of character for Bjarne. I think it's 
quite a poor piece.


I agree.  I stopped reading at The purpose of this paper is to 
examine the negative impact of the static if proposal [...].


Not the impact, but the *negative* impact.  That doesn't 
exactly set the stage for a very nuanced discussion.


Lars

Re: C++ guys hate static_if?

On Saturday, 9 March 2013 at 16:05:59 UTC, Andrei Alexandrescu 
wrote:

On 3/9/13 10:22 AM, monarch_dodra wrote:
BTW, in regards to template constraints (not the rest), he 
does have a
point. We have raised the exact same issues here on the boards 
more than

once.


What was the problem for D again?

Andrei


Problem is a big word. But basically, the combination: if your 
template type doesn't meet template constraints, where did it 
fail? We don't have that, but concepts do. This is part of the:
- Should we use constraints only for overloads or also to 
validate types?
- Should we instead use static asserts to find out why the 
argument type is wrong?


 That said, concepts (afaik) don't handle overloads...

...which brings us to managing said overloads. Basically, right 
now, if you want overloads, you have to repeat the conditions in 
a:


if (a  !b)
...
if (b  !c)
...
if (c)

This is minor, but it does not scale very well, especially if 
a, b and c are complicated. In algorithm, some of our 
constraints for sort/find can be 5 lines long. At this point, can 
we still say that they are readable tools for users, or an 
implementation tool for dispatch?


Things can get evenmore hairy,when you are operating on 2 
different types.


One last thing to keep in mind is that having constraints allows 
hijacking, whereas concpets/static asserts resolve as an ambigus 
call.



Not a breaking issue or anything, just more of an anoyance. I 
wanted to point out that we ourselves have already had talks 
about the points raised in said article.


Regardless, that was not the main point that I was trying to get 
accross. My main point was simply that what works for D might not 
be best for C++.

Re: std.stream replacement

2013-03-09 Thread Stewart Gordon


On 09/03/2013 02:30, Jonathan M Davis wrote:
snip

In general, ranges should work just fine for I/O as long as they have an
efficient implementation which underneathbuffers (and preferably makes them
forward ranges). Aside from how its implemented internally, there's no real
difference between operating on a range over a file and any other range. The
trick is making it efficient internally. Doing something like reading a
character at a time from a file every time that popFront is called would be
horrible, but with buffering, it should be just fine.


If examining one byte at a time is what you want.  I mean this at the 
program logic level, not just the implementation level.  The fact 
remains that most applications want to look at bigger portions of the 
file at a time.


ubyte[] data;
data.length = 100;
foreach (ref b; data) b = file.popFront();

Even with buffering, a block memory copy is likely to be more efficient 
than transferring each byte individually.


You could provide direct memory access to the buffer, but this creates 
further complications if you want to read variable-size chunks.  Further 
variables that affect the best way to do it include whether you want to 
keep hold of previously read chunks and whether you want to perform 
in-place modifications of the read-in data.



Now, you're not going to
get a random-access range that way, but it should work fine as a forward range,
and std.mmfile will probably give you want you want if an RA range is what you
really need (and that, we have already).


Yes, random-access file I/O is another thing.  I was thinking primarily 
of cases where you want to just read the file through and process it 
while doing so.  I imagine that most word processors, graphics editors, 
etc. will read the file and then generate the file afresh when you save, 
rather than just writing the changes to the file.


And then there are web browsers, which read files of various types both 
from the user's local file storage and over an HTTP connection.


Stewart.

Re: Migrating dmd to D?

Daniel Murphy yebbl...@nospamgmail.com wrote in message 
news:kgumek$2tp4$1...@digitalmars.com...
 Zach the Mystic reachbutminusthisz...@googlymail.com wrote in message 
 news:pabfuaorrjbljxzrg...@forum.dlang.org...

 Something like this https://github.com/yebblies/magicport2 ?

 Yes! I need to look it over more thoroughly, but I couldn't ask for a 
 better beginning. Can I trust that you'll be a willing part of future 
 discussions on this matter, even if only to play Devil's Advocate?

 More like a full-blown attempt than a beginning.  I started this a long 
 time ago.

 There are three parts to it:
 - c++ parser/d printer, with lots of cheating and special cases
 - patches to the c++ source
 - patched version of dmd to build the result (no error on variable 
 shadowing etc)

 It produces a 7 line d file which appears to get through 3/7ths of 
 semantic1.  Root needs to be ported, and a cleaner interface to the 
 backend is needed to compile the glue layer.


Update: With the bulk of root converting or ported, and the glue layer 
stubbed out, I can build dmd from the converted source then lex and parse 
the source (+druntime headers) again.

The highlight was the dynamically resized struct in root/stringtable. 
Something went horribly wrong there.

Re: C++ guys hate static_if?


On Saturday, 9 March 2013 at 15:22:55 UTC, monarch_dodra wrote:
On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu 
wrote:

On 3/8/13 7:48 PM, DypthroposTheImposter wrote:

See the static_if paper here:

http://isocpp.org/forums

Under the post constraints and static if there is a link to 
a

document about
static_if

https://docs.google.com/viewer?a=vpid=forumssrcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg


Are they full of it? Has it caused the problems they mention
in
D?


Wow. That's quite out of character for Bjarne. I think it's 
quite a poor piece.


Andrei


I think there is a bit of forced bashing in there, but the main 
point is that static if prevents eager semantic validation of 
templated code. In C++, if you write a semantically incorrect 
template, then the compiler can catch it. This is not possible 
once static ifs enter the picture.


I know for a fact I've had the C++ compiler catch a fair amount 
of errors for me, whereas it takes actual intantiation for the 
D compiler to catch said errors (and I've seen a few such 
errors in phobos).


I think the main point is not is static if good or not: I 
think D has clearly demonstrated how powerful it can be. 
However, to the question of is it the right move for C++, 
whith all of its heritage, to adopt static if? As a C++ 
developper, honestly, I'm not sure it is. I think that's where 
the piece is comming from, in maybe a clumsy manner.


C++ took a different road with its horrible template syntax, 
but it took that road. I think it is better to improve that 
road (with concepts, for example), then try to move the current 
paradigm.


That's might point of view having mostly a full C++ 
background, and having learned D. The bottom line, I think, is 
that it is an error to think of D as just improved C++, and 
that what might work for D might not be what is best for C++. 
It doesn't mean that static if (or other D constructs) are bad 
in and out of themselves. I wouldn't take this piece as a 
direct attack on D.


...

BTW, in regards to template constraints (not the rest), he does 
have a point. We have raised the exact same issues here on the 
boards more than once.


The more I think of it, the more this whole duck typing for 
templates is probably a bad solution because we lack tool to 
express « meta types ».

Re: Optlink is on github

2013-03-09 Thread Andrej Mitrovic

On 3/9/13, deadalnix deadal...@gmail.com wrote:
 On Friday, 8 March 2013 at 17:40:58 UTC, Andrej Mitrovic wrote:
 Honestly D has huge potential for tools like
 compilers/linkers/etc.
 They're the types of programs where you practically know all
 your
 requirements at compile-time, so e.g. generics come into play
 really
 nicely.


 That is the theory. In practice you'll run in MANY problems.


In practice I'm getting quite fed up with linker bugs, or DMD object
gen bugs which cause the linker to choke. :)

Re: Migrating dmd to D?

2013-03-09 Thread H. S. Teoh

On Sat, Mar 09, 2013 at 10:38:02AM +, Russel Winder wrote:
 On Sat, 2013-03-09 at 11:14 +0100, deadalnix wrote:
 […]
  Debian is not per se against non free, but some maintainers are, 
  and it does matter.
 
 This latter point is Debian's biggest problem, and actually it is worse
 than that in some cases. This is why having Debian maintainers
 maintaining D packages who are positively associated with D is
 important.
[...]

+1. I have upload privileges, and I'm willing to help with D packages.


T

-- 
Nearly all men can stand adversity, but if you want to test a man's
character, give him power. -- Abraham Lincoln

Re: The new std.process is ready for review

On Saturday, 9 March 2013 at 16:05:15 UTC, Lars T. Kyllingstad 
wrote:

I think I know what the problem is, and it sucks bigtime. :(

Since the child process inherits the parent's open file 
descriptors, both ends of a pipe will be open in the child 
process.  We have separated pipe creation and process creation, 
so spawnProcess() knows nothing about the other end of the 
pipe it receives, and is therefore unable to close it.


In this particular case, the problem is that sort doesn't do 
anything until it receives EOF on standard input, which never 
happens, because even though the write end of the pipe is 
closed in the parent process, it is still open in the child.


I don't know how to solve this in a good way.  I can think of a 
few alternatives, and they all suck:


1. Make a special spawnProcess() function for pipe 
redirection.

2. Use the process object approach, like Tango and Qt.
3. After fork(), in the child process, loop over the full range 
of possible file descriptors and close the ones we don't want 
open.


The last one would let us keep the current API (and would have 
the added benefit of cleaning up unused FDs) but I have no idea 
how it would impact performance.


I have tried (3), and confirmed that it does indeed solve the 
problem.


Lars

safeD

2013-03-09 Thread Mark T



Where can I find more information on SafeD?

http://dlang.org/safed.html

google didn't seem to find much

Is this suitable for embedded targets such as ARM Cortex 32 bit?

thanks

Mark

Re: C++ guys hate static_if?

2013-03-09 Thread Ali Çehreli


On 03/09/2013 03:15 AM, Artur Skawina wrote:

   - static-if not creating scopes /is/ confusing, but what would be a 
better

 alternative?

I am surprised that  and  are never mentioned:

static_if 
void foo();


Problem solved. ;)

Ali

Re: Cross compilers; GDC/LDC

2013-03-09 Thread Kai Nacke


On Monday, 4 March 2013 at 13:29:34 UTC, David Nadlinger wrote:

On Sunday, 3 March 2013 at 13:57:15 UTC, Manu wrote:

Ideally, I would really like all these toolchains:
GDC: x86, x64, ARM, PPC, MIPS, SH4 - common toolchains
LDC: x86, x64, ARM, PPC - used by apple



See http://wiki.dlang.org/LDC for information on the ARM/PPC 
status. You might want to contact Kai directly, maybe he can 
easily provide you with a real PPC64 cross-compiler.




Hi Manu,

I uploaded a Win64-version of LDC to 
http://www.redstar.de/ldc/LDC.zip (md5: 
5ae2c1c4b2c6e94e81b930b668a02cc4). It contains this version and 
targets:


LDC - the LLVM D compiler (trunk):
  based on DMD v2.061 and LLVM 3.3svn
  Default target: x86_64-pc-win32
  Host CPU: corei7
  http://dlang.org - http://wiki.dlang.org/LDC

  Registered Targets:
arm  - ARM
mips - Mips
mips64   - Mips64 [experimental]
mips64el - Mips64el [experimental]
mipsel   - Mipsel
ppc32- PowerPC 32
ppc64- PowerPC 64
thumb- Thumb
x86  - 32-bit X86: Pentium-Pro and above
x86-64   - 64-bit X86: EM64T and AMD64

Maybe this is useful for you.

Kai

Re: Error: 0xc0000005, Dmd Win 64

2013-03-09 Thread Brad Roberts

On 3/9/2013 7:11 AM, Michael wrote:
 Crash also occurs when
 
 int[] a;
 a.length = 10;
 
 So, it's maybe something wrong with ms c runtime of VS 2012.
 
 Just installed Update 2 for VS 2012, not helps.

Please make sure that a bug report is filed:

  http://d.puremagic.com/issues/

Thanks,
Brad

Re: C++ guys hate static_if?


On Saturday, 9 March 2013 at 17:51:31 UTC, Ali Çehreli wrote:

On 03/09/2013 03:15 AM, Artur Skawina wrote:

   - static-if not creating scopes /is/ confusing, but what
would be a better
 alternative?

I am surprised that  and  are never mentioned:

static_if 
void foo();


Problem solved. ;)

Ali


static if(condition) «
void foo();
»

Let's do it with style ;)

Re: C++ guys hate static_if?

2013-03-09 Thread Klaim - Joël Lamotte

Note that there will be a teleconference Tuesday with one important point:
 Discuss whether to continue work on static if, or to focus work on
concepts lite.
See:
https://groups.google.com/a/isocpp.org/forum/#!topic/concepts/AMVFwQGgS3c

I'm pointing that in case Alexandrescu and Walter didn't know and want to
defend their paper.

Joel Lamotte

Re: C++ guys hate static_if?


On 03/09/2013 12:10 PM, deadalnix wrote:

On Saturday, 9 March 2013 at 17:51:31 UTC, Ali Çehreli wrote:

On 03/09/2013 03:15 AM, Artur Skawina wrote:

 - static-if not creating scopes /is/ confusing, but what
would be a better
 alternative?

I am surprised that  and  are never mentioned:

static_if 
void foo();


Problem solved. ;)

Ali


static if(condition) «
void foo();
»

Let's do it with style ;)


I love how the second set show up in two different styles on my computer.

Re: C++ guys hate static_if?


On 03/09/2013 01:33 AM, Nick Sabalausky wrote:

On Sat, 9 Mar 2013 02:08:07 -0500
Nick Sabalauskyseewebsitetocontac...@semitwist.com  wrote:


On Sat, 09 Mar 2013 01:48:55 +0100
DypthroposTheImpostermcbrac...@gmail.com  wrote:


 See the static_if paper here:

http://isocpp.org/forums

Under the post constraints and static if there is a link to a
document about
static_if

https://docs.google.com/viewer?a=vpid=forumssrcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg

Are they full of it? Has it caused the problems they mention
in
D?


Does that document exist somewhere in a the form of a real web page?
Or at least *any* real document format?


To be clear, that's not a veiled attack on anything. I really *am*
just simply asking if there's a link for that anywhere to a real file
(html, pdf, text, wordperfect, gif, hell whatever.)


I converted it to pdf.  Do you want it?

Re: C++ guys hate static_if?


On Saturday, 9 March 2013 at 18:23:29 UTC, 1100110 wrote:
I love how the second set show up in two different styles on my 
computer.


This is not different style, this is different chars.   != « 
» .

Re: The new std.process is ready for review

On Sat, 09 Mar 2013 11:05:14 -0500, Lars T. Kyllingstad  
pub...@kyllingen.net wrote:



On Wednesday, 6 March 2013 at 16:45:51 UTC, Steven Schveighoffer wrote:
On Tue, 05 Mar 2013 17:38:09 -0500, Vladimir Panteleev  
vladi...@thecybershadow.net wrote:



I've also initially tried writing a different program:

[...]


Linux should work here.  From what I can tell, you are doing it right.

If I get some time, I'll try and debug this.


I think I know what the problem is, and it sucks bigtime. :(

Since the child process inherits the parent's open file descriptors,  
both ends of a pipe will be open in the child process.  We have  
separated pipe creation and process creation, so spawnProcess() knows  
nothing about the other end of the pipe it receives, and is therefore  
unable to close it.


In this particular case, the problem is that sort doesn't do anything  
until it receives EOF on standard input, which never happens, because  
even though the write end of the pipe is closed in the parent process,  
it is still open in the child.


Oh crap, that is bad.

Unlike Windows which is an opt-in strategy, unix has an opt-out strategy  
(there is the F_CLOEXEC flag).  For consistency, I think it would be good  
to close all the file descriptors before calling exec.


I don't know how to solve this in a good way.  I can think of a few  
alternatives, and they all suck:


1. Make a special spawnProcess() function for pipe redirection.
2. Use the process object approach, like Tango and Qt.
3. After fork(), in the child process, loop over the full range of  
possible file descriptors and close the ones we don't want open.


The last one would let us keep the current API (and would have the added  
benefit of cleaning up unused FDs) but I have no idea how it would  
impact performance.


I think 3 is the correct answer, it is consistent with Windows, and the  
most logical behavior.  For instance, if other threads are open and doing  
other things that aren't related (like network sockets), those too will be  
inherited!  We should close all file descriptors.


How do you loop over all open ones?  Just curious :)

-Steve

Re: C++ guys hate static_if?

2013-03-09 Thread Timon Gehr


On 03/09/2013 01:48 AM, DypthroposTheImposter wrote:

See the static_if paper here:

http://isocpp.org/forums

Under the post constraints and static if there is a link to a
document about
static_if

https://docs.google.com/viewer?a=vpid=forumssrcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg


   Are they full of it?


Maybe. The paper is full of typos.


Has it caused the problems they mention in D?


All of the non-C++ specific ones that are not made up to make the paper 
longer. Eg:


0. Templates + static if are an ad-hoc abstraction mechanism.

1. Declaration-site template body type checking becomes undecidable.

2. Constraint-based overloading needs manual work in order to express 
specialization relations.



In D there also exist other problems that wouldn't occur in C++ in that 
form:


static if(!is(typeof(x))) enum y = 1;
static if(!is(typeof(y))) enum z = 2;
static if(!is(typeof(z))) enum x = 3;

The above currently does not have any defined behaviour. If the three 
are distributed to mutually importing modules, which constants get 
defined may depend on the order the modules are passed to DMD on the 
command line. (It is solvable, but so far few people have shown interest.)

Re: C++ guys hate static_if?


On 03/09/2013 12:30 PM, deadalnix wrote:

On Saturday, 9 March 2013 at 18:23:29 UTC, 1100110 wrote:

I love how the second set show up in two different styles on my computer.


This is not different style, this is different chars.   != « » .


Yes, but my email client did not display them( « » ) as the same character.

They showed up as two distinct characters( «  (we're totally going to 
pretend that's one character)), which amused me since your comment was 
let's do it with style.

Re: The new std.process is ready for review

On Saturday, 9 March 2013 at 18:35:25 UTC, Steven Schveighoffer 
wrote:
On Sat, 09 Mar 2013 11:05:14 -0500, Lars T. Kyllingstad 
pub...@kyllingen.net wrote:


On Wednesday, 6 March 2013 at 16:45:51 UTC, Steven 
Schveighoffer wrote:
On Tue, 05 Mar 2013 17:38:09 -0500, Vladimir Panteleev 
vladi...@thecybershadow.net wrote:



I've also initially tried writing a different program:

[...]


Linux should work here.  From what I can tell, you are doing 
it right.


If I get some time, I'll try and debug this.


I think I know what the problem is, and it sucks bigtime. :(

Since the child process inherits the parent's open file 
descriptors, both ends of a pipe will be open in the child 
process.  We have separated pipe creation and process 
creation, so spawnProcess() knows nothing about the other 
end of the pipe it receives, and is therefore unable to close 
it.


In this particular case, the problem is that sort doesn't do 
anything until it receives EOF on standard input, which never 
happens, because even though the write end of the pipe is 
closed in the parent process, it is still open in the child.


Oh crap, that is bad.

Unlike Windows which is an opt-in strategy, unix has an opt-out 
strategy (there is the F_CLOEXEC flag).  For consistency, I 
think it would be good to close all the file descriptors before 
calling exec.


I don't know how to solve this in a good way.  I can think of 
a few alternatives, and they all suck:


1. Make a special spawnProcess() function for pipe 
redirection.

2. Use the process object approach, like Tango and Qt.
3. After fork(), in the child process, loop over the full 
range of possible file descriptors and close the ones we don't 
want open.


The last one would let us keep the current API (and would have 
the added benefit of cleaning up unused FDs) but I have no 
idea how it would impact performance.


I think 3 is the correct answer, it is consistent with Windows, 
and the most logical behavior.  For instance, if other threads 
are open and doing other things that aren't related (like 
network sockets), those too will be inherited!  We should close 
all file descriptors.


I think so too.  In C, you have to know about these things, and 
they are specified in the documentation for fork() and exec().  
In D you shouldn't have to know, things should just work the 
way you expect them to.




How do you loop over all open ones?  Just curious :)


You don't.  That is why I said solution (3) sucks too. :)  You 
have to loop over all possible non-std file descriptors, i.e. 
from 3 to the maximum number of open files.  (On my Ubuntu 
installation, this is by default 1024, but may be as much as 
4096.  I don't know about other *NIXes)


Here is how to do it:

import core.sys.posix.unistd, core.sys.posix.sys.resource;
rlimit r;
getrlimit(RLIMIT_NOFILE, r);
for (int i = 0; i  r.rlim_cur; ++i)
close(i);

Lars

Re: C++ guys hate static_if?

2013-03-09 Thread Peter Alexander


On Saturday, 9 March 2013 at 16:22:43 UTC, monarch_dodra wrote:
...which brings us to managing said overloads. Basically, right 
now, if you want overloads, you have to repeat the conditions 
in a:


if (a  !b)
...
if (b  !c)
...
if (c)

This is minor, but it does not scale very well, especially if 
a, b and c are complicated. In algorithm, some of our 
constraints for sort/find can be 5 lines long. At this point, 
can we still say that they are readable tools for users, or an 
implementation tool for dispatch?


I agree this is a problem. sort didn't have constraints for a 
long time. I added them not long ago, but if I'm being perfectly 
honest, I'm not 100% convinced I've done it correctly. It's 
incredibly difficult to examine a non-trivial function to see 
what the correct constraints are.


btw, you have a bug :-)  If the arguments match constraints a and 
c, but not b then the call will be ambiguous on the first and 
third.


Another problem with constraints is that if you want to add a 
specialisation, you can't do it without changing the existing 
functions, e.g.


void foo(R)(R r) if (isInputRange!R)

If I want to add a better version for random access ranges, I 
cannot just add:


void foo(R)(R r) if (isRandomAccessRange!R)

I also have to modify the original:

void foo(R)(R r) if (isInputRange!R  !isRandomAccessRange!R)

I suppose a better solution to this problem would involve someway 
of specifying that random access ranges are a subtype of input 
ranges, and the overload resolution would recognise that the 
random access range version is preferable to the more general 
version when available. I can't see a way to do this in general 
with constraints.

Re: The new std.process is ready for review

On Saturday, 9 March 2013 at 18:44:45 UTC, Lars T. Kyllingstad 
wrote:
On Saturday, 9 March 2013 at 18:35:25 UTC, Steven Schveighoffer 
wrote:

How do you loop over all open ones?  Just curious :)


You don't.  That is why I said solution (3) sucks too. :)  You 
have to loop over all possible non-std file descriptors, i.e. 
from 3 to the maximum number of open files.  (On my Ubuntu 
installation, this is by default 1024, but may be as much as 
4096.  I don't know about other *NIXes)


Here is how to do it:

import core.sys.posix.unistd, core.sys.posix.sys.resource;
rlimit r;
getrlimit(RLIMIT_NOFILE, r);
for (int i = 0; i  r.rlim_cur; ++i)
close(i);


BTW, core.sys.posix.sys.resource currently doesn't exist, we have 
to create it.


Lars

Re: The new std.process is ready for review

On Sat, 09 Mar 2013 13:44:44 -0500, Lars T. Kyllingstad  
pub...@kyllingen.net wrote:



On Saturday, 9 March 2013 at 18:35:25 UTC, Steven Schveighoffer wrote:



How do you loop over all open ones?  Just curious :)


You don't.  That is why I said solution (3) sucks too. :)  You have to  
loop over all possible non-std file descriptors, i.e. from 3 to the  
maximum number of open files.  (On my Ubuntu installation, this is by  
default 1024, but may be as much as 4096.  I don't know about other  
*NIXes)


Here is how to do it:

import core.sys.posix.unistd, core.sys.posix.sys.resource;
rlimit r;
getrlimit(RLIMIT_NOFILE, r);
for (int i = 0; i  r.rlim_cur; ++i)
 close(i);


Hm... don't close 0, 1, 2 :)

On Linux at least, you could use /proc/self/fd  I suppose it's faster just  
to loop though.


How long does it take when you close non-open descriptors?  We don't want  
to hamper performance too much.


I wonder if select on all possible file descriptors in the fd_err  
parameter would give you a clue as to which were invalid.


-Steve

Re: The new std.process is ready for review

On Sat, 09 Mar 2013 13:54:32 -0500, Steven Schveighoffer  
schvei...@yahoo.com wrote:



I wonder if select on all possible file descriptors in the fd_err  
parameter would give you a clue as to which were invalid.


Hm... seems like select returns -1 if an invalid descriptor is included.   
That probably means it won't flag all of them..


-Steve

Re: safeD

2013-03-09 Thread jerro


Is this suitable for embedded targets such as ARM Cortex 32 bit?


For ARM, your best bet is to follow this guide to build a GDC 
cross-compiler (probably easiest to build on a Linux host):


http://gdcproject.org/wiki/Cross%20Compiler/crosstool-NG

I don't know what kind of ARM Cortex you have in mind and what OS 
do you need to use. If you mean Cortex A8, A9 or A15 and if your 
target OS is GNU/Linux, then you can use Druntime and Phobos. I 
haven't used GDC on ARM enough to know if everything in Druntime 
and Phobos works, but the parts that I have used did work. In 
this case you should be able to SafeD too, as it's just a subset 
of D.


For Android there's a fork of GDC at 
https://github.com/jpf91/GDC/tree/android, but it hasn't been 
updated for some time now. There are build scripts that build NDK 
with gdc support at https://github.com/jpf91/gdc-android-scripts. 
I don't know how well that fork works. Also, GDC's Druntime does 
not support shared libraries, which is a problem if you want to 
call D functions from java apps.


If you are using some other OS or no OS at all, I don't think 
there is a working version of Druntime you can use. In that case, 
you could probably still use D, but without Druntime. You would 
need to write stubs for some Druntime functions to avoid linker 
errors, and you would need to avoid any D features that use 
Druntime. Because of that, you couldn't use any feature that use 
a GC, such as operator new, associative arrays, closures or 
appending to slices. This would also make it impossible to 
effectively use SafeD (because you wouldn't be able to allocate 
memory). You could port Druntime to your platform, but I guess 
this is a lot of work.

Re: The new std.process is ready for review

On Saturday, 9 March 2013 at 18:54:31 UTC, Steven Schveighoffer 
wrote:
On Sat, 09 Mar 2013 13:44:44 -0500, Lars T. Kyllingstad 
pub...@kyllingen.net wrote:


On Saturday, 9 March 2013 at 18:35:25 UTC, Steven 
Schveighoffer wrote:



How do you loop over all open ones?  Just curious :)


You don't.  That is why I said solution (3) sucks too. :)  You 
have to loop over all possible non-std file descriptors, i.e. 
from 3 to the maximum number of open files.  (On my Ubuntu 
installation, this is by default 1024, but may be as much as 
4096.  I don't know about other *NIXes)


Here is how to do it:

import core.sys.posix.unistd, core.sys.posix.sys.resource;
rlimit r;
getrlimit(RLIMIT_NOFILE, r);
for (int i = 0; i  r.rlim_cur; ++i)
close(i);


Hm... don't close 0, 1, 2 :)

On Linux at least, you could use /proc/self/fd  I suppose it's 
faster just to loop though.


How long does it take when you close non-open descriptors?  We 
don't want to hamper performance too much.


On my computer, with 1024 (minus 3 ;))possible file descriptors, 
it roughly doubles the time spent inside spawnProcess() up to, 
but not including, the excecve() call.  (About 0.1 microsecond 
per file descriptor.)  Considering that execve() probebly dwarfs 
that number, I think we're in good shape.


Of course, we have a problem if some other platform allows 
ulong.max open files...


I wonder if select on all possible file descriptors in the 
fd_err parameter would give you a clue as to which were invalid.


My guess is that select() uses more or less the same mechanism as 
close() for checking FD validity, and thus would gain us nothing.


Lars

Re: C++ guys hate static_if?


On 3/9/13 1:10 PM, Klaim - Joël Lamotte wrote:

Note that there will be a teleconference Tuesday with one important point:
Discuss whether to continue work on static if, or to focus work on
concepts lite.
See:
https://groups.google.com/a/isocpp.org/forum/#!topic/concepts/AMVFwQGgS3c

I'm pointing that in case Alexandrescu and Walter didn't know and want
to defend their paper.

Joel Lamotte


Thanks, Joel.

Andrei

Re: safeD

2013-03-09 Thread Mark T


On Saturday, 9 March 2013 at 19:07:31 UTC, jerro wrote:
Is this suitable for embedded targets such as ARM Cortex 32 
bit?


For ARM, your best bet is to follow this guide to build a GDC 
cross-compiler (probably easiest to build on a Linux host):


http://gdcproject.org/wiki/Cross%20Compiler/crosstool-NG

I don't know what kind of ARM Cortex you have in mind and what 
OS do you need to use. If you mean Cortex A8, A9 or A15 and if 
your target OS is GNU/Linux, then you can use Druntime and 
Phobos. I haven't used GDC on ARM enough to know if everything 
in Druntime and Phobos works, but the parts that I have used 
did work. In this case you should be able to SafeD too, as it's 
just a subset of D.


   Thanks for the input - but where is SafeD defined? Is there a 
compiler switch?
I haven't looked at D in a while, it was just too big for ARM 
Cortex M, smaller PowerPC and similar targets - a google search 
got me to the SafeD topic.

Re: safeD

2013-03-09 Thread Jonathan M Davis

On Saturday, March 09, 2013 20:47:10 Mark T wrote:
 Thanks for the input - but where is SafeD defined? Is there a
 compiler switch?

No. It's simply code that's @safe. If you mark your functions as @safe, then 
they can only can @safe and @trusted functions and can't do any operations 
that the language considers to be @system (e.g. pointer arithmetic). So, what 
it comes down to is that you have certain safety guarantees about any code 
that's marked @safe. It's not really a separate language. It's just that you 
can only use a subset of the language within @safe code, because you can only 
use stuff that's guaranteed to be safe (though when calling @trusted code, you 
_do_ still rely on the programmer who wrote it having verified that it was 
actually safe, and they could screw that up).

Certain language constructs and core library components are not yet @safe like 
they should be, and attribute inferrence for templates still needs a lot of 
work (templated functions infer whether they're @safe, nothrow, and/or pure), 
so there's a lot of templated stuff that's perfectly safe but doesn't get 
treated that way yet. So, you're probably going to have to use @trusted more 
than would be desirable (and certainly more than you'll have to in the 
future), but on the whole, @safe itself works just fine. But it's part of the 
language, not something triggered by a compiler switch.

- Jonathan M Davis

Re: safeD

2013-03-09 Thread Minas Mina


On Saturday, 9 March 2013 at 19:47:12 UTC, Mark T wrote:
   Thanks for the input - but where is SafeD defined? Is there 
a compiler switch?
I haven't looked at D in a while, it was just too big for ARM 
Cortex M, smaller PowerPC and similar targets - a google search 
got me to the SafeD topic.


No, you don't need to compiler switch. What you need is to mark 
functions as @safe. E.g:


@safe void safe_foo()
{
}

If you don't mark them they are considerded @system.

Re: The new std.process is ready for review

On Sat, 09 Mar 2013 14:24:49 -0500, Lars T. Kyllingstad  
pub...@kyllingen.net wrote:


My guess is that select() uses more or less the same mechanism as  
close() for checking FD validity, and thus would gain us nothing.


Yeah, I was hoping select would flag each non-valid file descriptor in  
fd_errors, and do it all in an internal loop in the kernel instead of  
going back and forth between user space and kernel space.


But I don't think it does that.  It just errors the whole function on the  
first invalid descriptor it sees.


Go with your workaround, sounds reasonable.  I agree that 100us pales in  
comparison to launching a program.  Perhaps an option to disable this  
behavior should be available in Config.  It certainly is possible with the  
F_CLOEXEC flag to manually do what needs to be done.


-Steve

Re: Optlink is on github

2013-03-09 Thread Andrej Mitrovic

On 3/7/13, Daniel Murphy yebbl...@nospamgmail.com wrote:
 If anyone is interested I'll put it up on github.

I'd be interested, please do put it online when you get the time.

Re: About structs and performant handling

2013-03-09 Thread bearophile


Namespace:


Wrong link...
I meant: http://dpaste.1azy.net/b9624e01


Benchmarks on dpaste aren't very useful because I think no 
optimization switches are used, and because the CPU is not under 
control, so other unknown tasks can steal some of its time.


Bye,
bearophile

Re: safeD

2013-03-09 Thread jerro


On Saturday, 9 March 2013 at 19:47:12 UTC, Mark T wrote:

On Saturday, 9 March 2013 at 19:07:31 UTC, jerro wrote:
Is this suitable for embedded targets such as ARM Cortex 32 
bit?


For ARM, your best bet is to follow this guide to build a GDC 
cross-compiler (probably easiest to build on a Linux host):


http://gdcproject.org/wiki/Cross%20Compiler/crosstool-NG

I don't know what kind of ARM Cortex you have in mind and what 
OS do you need to use. If you mean Cortex A8, A9 or A15 and if 
your target OS is GNU/Linux, then you can use Druntime and 
Phobos. I haven't used GDC on ARM enough to know if everything 
in Druntime and Phobos works, but the parts that I have used 
did work. In this case you should be able to SafeD too, as 
it's just a subset of D.


   Thanks for the input - but where is SafeD defined?


It is described in The D programming language book. There's 
also something about it in Programming in D book, but that part 
hasn't been translated to English yet. People have written about 
SafeD in other places too, but I can't remember any.



Is there a compiler switch?


There are attributes @safe, @trusted and @system, that are used 
like this:


void foo() @safe
{
//some code
}

or

@safe
{
void foo() @safe{}
void bar() @safe{}
}

or (this will affect all the functions from @safe: to the end of 
the scope):


@safe:

void foo(){}
void bar(){}

The code that is marked as safe can't use certain language 
features (For example
pointer arithmetic and casting pointers - I haven't used @safe 
enough to know all the restrictions) or call functions that are 
marked @system. Also, some new restrictions (related to returning 
by reference) will need to be added to @safe, because it was 
recently discovered that it is currently possible to write @safe 
code that is not actually memory safe.


@system and @trusted code can use all D features and call all 
functions. The difference between them is that @trusted functions 
can be called by @safe code and @system functions can not.


For templates, safety is inferred from implementation if there 
are no attributes, and ordinary functions are considered @system 
by default.


I haven't looked at D in a while, it was just too big for ARM 
Cortex M, smaller PowerPC and similar targets - a google search 
got me to the SafeD topic.


If D needs to much memory or if the executables are too large for 
your use case,
SafeD will not make it any better. It will actually make it 
worse, because it makes manual memory management impossible (it 
prohibits calling malloc or casting between pointer types), if 
used consistently.

Re: About structs and performant handling

Benchmarks on dpaste aren't very useful because I think no 
optimization switches are used, and because the CPU is not 
under control, so other unknown tasks can steal some of its 
time.


Bye,
bearophile


I used optimation switches:
Application arguments:
-O -release -noboundscheck

But you're right, but what should I do?
I could deliver you my results from my pc:
[quote]
Call b0 (B by ref).  Duration: 259 total, 0.129500 average.
Call b1 (B by move). Duration: 804 total, 0.402000 average.
Call b2 (B by make). Duration: 364 total, 0.182000 average.
Call b3 (B by copy). Duration: 943 total, 0.471500 average.
Call b4 (B by manual move). Duration: 1101 total, 0.550500 
average.

Call b5  (A by move). Duration: 17 total, 0.008500 average.
Call b6 (A by copy). Duration: 65 total, 0.032500 average.
Call b7 (A by ref).  Duration: 47 total, 0.023500 average.
Call b8 (A by make). Duration: 54 total, 0.027000 average.
[/quote]
Also compiled with -O -release -noboundscheck on a Intel i5-2500k 
CPU with 3.30 GHz.

But the script is there. So you could test by yourself. :)

Re: DDoc: possible to show inherited class members?

2013-03-09 Thread Marco Leise

Am Sat, 09 Mar 2013 08:06:18 +0100
schrieb Kapps opantm2+s...@gmail.com:

 It would be nice if this was default, and possibly if there was 
 an 'inherit' when overriding much like there is 'ditto' (or just 
 default to base type documentation).

No question.

-- 
Marco

Re: C++ guys hate static_if?

2013-03-09 Thread Ali Çehreli


On 03/09/2013 10:10 AM, deadalnix wrote:

 static_if 
 void foo();
 

 Problem solved. ;)

 Ali

 static if(condition) «
 void foo();
 »

 Let's do it with style ;)

Ha ha! :) I remembered about those characters as well but only after 
posting mine.


Ali

Re: About structs and performant handling

2013-03-09 Thread Ali Çehreli


On 03/09/2013 12:19 PM, Namespace wrote:

 But structs with a bigger size aren't that performant if you pass them
 as copy or move them (See also my small benchmark:

I have started working on the DConf presentation about copy and move 
semantics in D. I have done exactly the same type of tests and was 
surprised how faster pass-by-reference can be.


To be fair, I have also accessed the members of the structs inside the 
function to see whether the pointer dereferencing in the by-ref case 
brought any cost. Apparently I have been ignorant in modern CPU designs 
because I was surprised to see that pointer dereferencing seemingly had 
no cost at all. My guess would be that the object is completely inside 
the processor's cache.


Then I suspected dmd and made similar tests with gcc in the C language 
and have seen similar results. So yes, apparently by-ref is faster at 
least in some cases.


 For example:
 [code]
 struct A { }
 void foo(A a) { }
 [/code]
 The compiler will check by these kind of parameters if they are structs
 and if the size is proven greater as N (maybe 16 - 24) bit. If not, the
 '' will be ignored. The function take in this cases normally lvalues as
 copy and moves rvalues.
 But if the struct size is greater than N the compiler changes the
 storage class of this parameter to ref.

I hope others with compiler knowledge will chime in here.

I think the type of the parameter that is passed is intrinsic to how the 
function gets compiled. I think, for that to work, the compiler would 
have to compile two versions of the function, one taking by-value and 
the other taking by-ref.


If what I said above is correct, then of course that wouldn't scale, 
e.g. we would need four separate compilations of the function if we had 
two parameters.


Then there would be the issue of finding a naming scheme for these 
separate versions of the function so that the linker finds the right 
one. I am making up some names for the linker: foo_val_val(), 
foo_val_ref(), foo_ref_val(), foo_ref_ref().


Others, please correct me if I am wrong above. :)

Ali

Re: Migrating dmd to D?

2013-03-09 Thread Chad Joan


On 02/27/2013 08:05 PM, Andrei Alexandrescu wrote:

On 2/27/13 7:55 PM, timotheecour wrote:

Use dtoh to initiate and conduct an incremental port of the compiler.


How about going the other way around?

Using swig to make existing dmd C++ code available to D, so we can
advance with a mix of D and C++ code until all of C++ code is converted.
I was able to successfully convert large code bases from C++ to D using
swig (eg: opencv, sfml, etc). It's the most hands-off way, with very
minimal interface file that can recursively make things accessible with
fine grained control (for opencv the interface file was  200 loc).


I think that's a fine idea but I also believe dtoh would be a mightily
powerful program in and by itself. Once available, it would make
migration of C++ projects to D possible and easy.

Andrei


Isn't this what swig /does/ though?  What is lacking?

Re: The new std.process is ready for review

On Saturday, 9 March 2013 at 16:05:15 UTC, Lars T. Kyllingstad 
wrote:
1. Make a special spawnProcess() function for pipe 
redirection.

2. Use the process object approach, like Tango and Qt.
3. After fork(), in the child process, loop over the full range 
of possible file descriptors and close the ones we don't want 
open.


The last one would let us keep the current API (and would have 
the added benefit of cleaning up unused FDs) but I have no idea 
how it would impact performance.


How about this: Set FD_CLOEXEC on all pipes just after creation, 
but clear the flag for the relevant pipes before exec?

Re: About structs and performant handling

2013-03-09 Thread Marco Leise

Am Sat, 09 Mar 2013 15:07:49 -0800
schrieb Ali Çehreli acehr...@yahoo.com:

 Apparently I have been ignorant in modern CPU designs 
 because I was surprised to see that pointer dereferencing seemingly had 
 no cost at all. My guess would be that the object is completely inside 
 the processor's cache.

Be aware of several things playing together here: L1 and L2
cache as well as prefetching and order of the data in memory.
If you create a few KiB of data and run it through a test its
all in the L1 cache and blazing fast. If you have a game and
load a matrix struct from somewhere scattered in memory you'll
see the massive access penalty.
The modern prefetchers in CPUs keep track of a N streams of
forward or backward serial memory accesses. So they work
perfectly for iterating an array for example. The work in the
background and use free memory bandwidth to load data from
RAM to CPU caches before you actually need it. This hides the
memory delay that has become increasingly larger in the past
years. It is so important that many don't optimize for CPU
cycles anymore but instead for memory access and cache
locality:

* http://en.wikipedia.org/wiki/Judy_array

* 
http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

Its easy to underestimate the effects until you benchmark with
some several MiB large random memory access patterns and see
how you get close to a 100 times slow down.

-- 
Marco

Re: The new std.process is ready for review

On Sat, 09 Mar 2013 19:51:49 -0500, Vladimir Panteleev  
vladi...@thecybershadow.net wrote:



On Saturday, 9 March 2013 at 16:05:15 UTC, Lars T. Kyllingstad wrote:

1. Make a special spawnProcess() function for pipe redirection.
2. Use the process object approach, like Tango and Qt.
3. After fork(), in the child process, loop over the full range of  
possible file descriptors and close the ones we don't want open.


The last one would let us keep the current API (and would have the  
added benefit of cleaning up unused FDs) but I have no idea how it  
would impact performance.


How about this: Set FD_CLOEXEC on all pipes just after creation, but  
clear the flag for the relevant pipes before exec?


This doesn't help if other threads are randomly opening file descriptors.   
That is a problem I don't think we considered.


Unix's design here is very outdated, seems to assume a single threaded app.

This does make me thing of another good point, we should unset the  
FD_CLOEXEC flag on stdout, stdin, and stderr!


-Steve

Re: C++ guys hate static_if?

2013-03-09 Thread Nick Sabalausky

On Sat, 09 Mar 2013 12:28:37 -0600
1100110 0b1100...@gmail.com wrote:

 On 03/09/2013 01:33 AM, Nick Sabalausky wrote:
  On Sat, 9 Mar 2013 02:08:07 -0500
  Nick Sabalauskyseewebsitetocontac...@semitwist.com  wrote:
 
  On Sat, 09 Mar 2013 01:48:55 +0100
  DypthroposTheImpostermcbrac...@gmail.com  wrote:
 
   See the static_if paper here:
 
  http://isocpp.org/forums
 
  Under the post constraints and static if there is a link to a
  document about
  static_if
 
  https://docs.google.com/viewer?a=vpid=forumssrcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg
 
  Are they full of it? Has it caused the problems they
  mention in
  D?
 
  Does that document exist somewhere in a the form of a real web
  page? Or at least *any* real document format?
 
  To be clear, that's not a veiled attack on anything. I really *am*
  just simply asking if there's a link for that anywhere to a real
  file (html, pdf, text, wordperfect, gif, hell whatever.)
 
 I converted it to pdf.  Do you want it?

Sure, please. If you could either post it here, or on the web, or email
nick1 at semitwist dot com, or whatever works for you that'd be
great. :)

Re: About structs and performant handling

Ali Çehreli acehr...@yahoo.com wrote in message 
news:khgfc6$1m9i$1...@digitalmars.com...

 To be fair, I have also accessed the members of the structs inside the 
 function to see whether the pointer dereferencing in the by-ref case 
 brought any cost. Apparently I have been ignorant in modern CPU designs 
 because I was surprised to see that pointer dereferencing seemingly had no 
 cost at all. My guess would be that the object is completely inside the 
 processor's cache.


Accessing a member of a stuct on the stack:
mov EDX, dword ptr [ESP+stackoffset+memberoffset]

Accessing a member of a struct on the heap:
(assume pointer to struct is in EAX)
mov EDX, dword ptr [EAX+memberoffset]

A lot of the time the heap pointer will be in a register already.  Stack 
memory will almost always be in the caches, and so will recently used heap 
memory.

If you want to measure the cost of loading the heap pointer then 
dereferencing, you might want to mark all the registers as used so the 
compiler is forced to reload.

eg with
asm {}


  For example:
  [code]
  struct A { }
  void foo(A a) { }
  [/code]
  The compiler will check by these kind of parameters if they are structs
  and if the size is proven greater as N (maybe 16 - 24) bit. If not, the
  '' will be ignored. The function take in this cases normally lvalues as
  copy and moves rvalues.
  But if the struct size is greater than N the compiler changes the
  storage class of this parameter to ref.

 I hope others with compiler knowledge will chime in here.

 I think the type of the parameter that is passed is intrinsic to how the 
 function gets compiled. I think, for that to work, the compiler would have 
 to compile two versions of the function, one taking by-value and the other 
 taking by-ref.


A better way to do with would be to change (or extend) the abi, so that 
structs over a certain size are always passed by reference with this 
parameter type.  Then you only need one version of the function.  We could 
use auto ref for this.

Re: C++ guys hate static_if?

2013-03-09 Thread Walter Bright


On 3/9/2013 8:22 AM, monarch_dodra wrote:

Things can get evenmore hairy,when you are operating on 2 different types.


This is why complex expressions can be encapsulated as functions.



One last thing to keep in mind is that having constraints allows hijacking,
whereas concpets/static asserts resolve as an ambigus call.


I don't see where the hijacking comes in.

Re: The new std.process is ready for review

On Sat, 09 Mar 2013 11:05:14 -0500, Lars T. Kyllingstad  
pub...@kyllingen.net wrote:



On Wednesday, 6 March 2013 at 16:45:51 UTC, Steven Schveighoffer wrote:
On Tue, 05 Mar 2013 17:38:09 -0500, Vladimir Panteleev  
vladi...@thecybershadow.net wrote:


By the way, I should mention that I ran into several issues while  
trying to come up with the above example. The test program does not  
work on Windows, for some reason I get the exception:


std.process2.ProcessException@std\process2.d(494): Failed to spawn new  
process (The parameter is incorrect.)


I think Lars is on that.


I'm going to need som help with this one.  I only have Linux on my  
computer, and I can't reproduce the bug in Wine.


Tried as well.  I have only a 32-bit license for Windows XP, so I don't  
have a 64-bit VM to test with (this is not wine, but vmware, should be  
exactly the same as running on a real windows box).  I gave away my  
Windows 7 64-bit box :(


Anyway, on 32-bit XP I get a successful run:

100 lines of stdout, 100 lines of stderr

I can possibly try it on a laptop from work.  But not until Monday.

So it probably is a 64-bit-only issue.  I know you just added this part  
Lars, and it uses microsoft's runtime.  Very different from the DMC  
runtime.  But both should use the same OS call.  Will take a closer look  
at the code around that line.


Vladimir, can you try compiling 32-bit windows and see if it works for  
you, just to confirm?


-Steve

Re: The new std.process is ready for review



So it probably is a 64-bit-only issue.  I know you just added this part  
Lars, and it uses microsoft's runtime.  Very different from the DMC  
runtime.  But both should use the same OS call.  Will take a closer look  
at the code around that line.




Looks fine to me.

Doing some searching online, the overwhelming results for that specific  
error are for failed ANT build or java execution due to a huge class path  
(which I think is either passed on the command line or via environment?)


Try shortening your executable path/environment?

Just a guess...

-Steve

Re: The new std.process is ready for review

On Sunday, 10 March 2013 at 02:54:44 UTC, Steven Schveighoffer 
wrote:
Vladimir, can you try compiling 32-bit windows and see if it 
works for you, just to confirm?


I'm seeing the same exception with both 32 and 64 bit, Steven.

I guess it must be something specific to my system, like the 
HANDLE_FLAG_INHERIT stuff.

Re: The new std.process is ready for review

On Sunday, 10 March 2013 at 03:06:03 UTC, Steven Schveighoffer 
wrote:

Try shortening your executable path/environment?


Didn't help.

Re: The new std.process is ready for review

On Sat, 09 Mar 2013 22:07:26 -0500, Vladimir Panteleev  
vladi...@thecybershadow.net wrote:



On Sunday, 10 March 2013 at 02:54:44 UTC, Steven Schveighoffer wrote:
Vladimir, can you try compiling 32-bit windows and see if it works for  
you, just to confirm?


I'm seeing the same exception with both 32 and 64 bit, Steven.

I guess it must be something specific to my system, like the  
HANDLE_FLAG_INHERIT stuff.


IIRC, you were able to get something working there with std.process2.  Is  
that example still working?  I'm trying to see what could be different  
that's causing this.


I can try a test on a win7 box monday.  Likely the issue is xp vs. win7.

-Steve

Any takers for http://d.puremagic.com/issues/show_bug.cgi?id=9673?

I figure http://d.puremagic.com/issues/show_bug.cgi?id=9673 it's a great 
relatively confined project of good utility. We preapproved it, if 
anyone wants to snatch it please come forward.


Also, any comments to the design are welcome.


Thanks,

Andrei

Re: Any takers for http://d.puremagic.com/issues/show_bug.cgi?id=9673?

On Sunday, 10 March 2013 at 04:29:34 UTC, Andrei Alexandrescu 
wrote:
I figure http://d.puremagic.com/issues/show_bug.cgi?id=9673 
it's a great relatively confined project of good utility. We 
preapproved it, if anyone wants to snatch it please come 
forward.


Also, any comments to the design are welcome.


I've thought about this before. Here are my thoughts:

1. Querying the dependencies of one module, and compiling it, 
should be done in one go (one dmd execution).


The idea is that if we need to get a module's dependencies, it 
will be because the module is one we've never compiled it before, 
or the module itself or one of its previously-known dependencies 
has changed


2. Object files (and their .deps) should be cached independently 
of the entry point module.


This will allow speeding up incremental compilation of multiple 
programs that share some source files.

Re: The new std.process is ready for review

On Sunday, 10 March 2013 at 03:48:36 UTC, Steven Schveighoffer 
wrote:
On Sat, 09 Mar 2013 22:07:26 -0500, Vladimir Panteleev 
vladi...@thecybershadow.net wrote:


On Sunday, 10 March 2013 at 02:54:44 UTC, Steven Schveighoffer 
wrote:
Vladimir, can you try compiling 32-bit windows and see if it 
works for you, just to confirm?


I'm seeing the same exception with both 32 and 64 bit, Steven.

I guess it must be something specific to my system, like the 
HANDLE_FLAG_INHERIT stuff.


IIRC, you were able to get something working there with 
std.process2.  Is that example still working?  I'm trying to 
see what could be different that's causing this.


Yes, Steven. The ls test program still works:
http://dump.thecybershadow.net/935b0c4a47ce367313efcc1806f75076/lstest.d

Re: Color your terminal's output

2013-03-09 Thread Axl


When I run:

$ dmd -unittest -m64 /usr/lib/x86_64-linux-gnu/libncurses.a -run 
terminal.d


I get the follwoing output:

terminal.o: In function `_D8terminal12_staticCtor2FZv':
terminal.d:(.text._D8terminal12_staticCtor2FZv+0x27): undefined 
reference to `setupterm'
terminal.d:(.text._D8terminal12_staticCtor2FZv+0x81): undefined 
reference to `tigetstr'
terminal.d:(.text._D8terminal12_staticCtor2FZv+0x12b): undefined 
reference to `tigetstr'
terminal.d:(.text._D8terminal12_staticCtor2FZv+0x1cc): undefined 
reference to `tigetstr'
terminal.d:(.text._D8terminal12_staticCtor2FZv+0x26d): undefined 
reference to `tigetstr'
terminal.d:(.text._D8terminal12_staticCtor2FZv+0x30e): undefined 
reference to `tigetstr'
terminal.o:terminal.d:(.text._D8terminal12_staticCtor2FZv+0x3af): 
more undefined references to `tigetstr' follow
terminal.o: In function 
`_D8terminal8Terminal36__T13setCapabilityTE8terminal5ColorZ13setCapabilityMFxE8terminal10CapabilityxE8terminal5ColorZv':
terminal.d:(.text._D8terminal8Terminal36__T13setCapabilityTE8terminal5ColorZ13setCapabilityMFxE8terminal10CapabilityxE8terminal5ColorZv+0xb2): 
undefined reference to `tparm'
terminal.d:(.text._D8terminal8Terminal36__T13setCapabilityTE8terminal5ColorZ13setCapabilityMFxE8terminal10CapabilityxE8terminal5ColorZv+0xc2): 
undefined reference to `tputs'
terminal.d:(.text._D8terminal8Terminal36__T13setCapabilityTE8terminal5ColorZ13setCapabilityMFxE8terminal10CapabilityxE8terminal5ColorZv+0x147): 
undefined reference to `tparm'
terminal.d:(.text._D8terminal8Terminal36__T13setCapabilityTE8terminal5ColorZ13setCapabilityMFxE8terminal10CapabilityxE8terminal5ColorZv+0x157): 
undefined reference to `tputs'
terminal.o: In function 
`_D8terminal8Terminal19__T13setCapabilityZ13setCapabilityMFxE8terminal10CapabilityZv':
terminal.d:(.text._D8terminal8Terminal19__T13setCapabilityZ13setCapabilityMFxE8terminal10CapabilityZv+0xac): 
undefined reference to `tparm'
terminal.d:(.text._D8terminal8Terminal19__T13setCapabilityZ13setCapabilityMFxE8terminal10CapabilityZv+0xbc): 
undefined reference to `tputs'
terminal.d:(.text._D8terminal8Terminal19__T13setCapabilityZ13setCapabilityMFxE8terminal10CapabilityZv+0x13e): 
undefined reference to `tparm'
terminal.d:(.text._D8terminal8Terminal19__T13setCapabilityZ13setCapabilityMFxE8terminal10CapabilityZv+0x14e): 
undefined reference to `tputs'

collect2: ld returned 1 exit status
--- errorlevel 1

I know it is a linker error, but I cannot fix it. Any ideas?

dmd version is:

DMD64 D Compiler v2.061

linker version is:

GNU ld (GNU Binutils for Ubuntu) 2.22

Distro is Ubuntu Linux 12.04.

Thanks,

Axl

Re: C++ guys hate static_if?


On 03/09/2013 08:09 PM, Nick Sabalausky wrote:

On Sat, 09 Mar 2013 12:28:37 -0600
11001100b1100...@gmail.com  wrote:


On 03/09/2013 01:33 AM, Nick Sabalausky wrote:

On Sat, 9 Mar 2013 02:08:07 -0500
Nick Sabalauskyseewebsitetocontac...@semitwist.com   wrote:


On Sat, 09 Mar 2013 01:48:55 +0100
DypthroposTheImpostermcbrac...@gmail.com   wrote:


  See the static_if paper here:

http://isocpp.org/forums

Under the post constraints and static if there is a link to a
document about
static_if

https://docs.google.com/viewer?a=vpid=forumssrcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg

 Are they full of it? Has it caused the problems they
mention in
D?


Does that document exist somewhere in a the form of a real web
page? Or at least *any* real document format?


To be clear, that's not a veiled attack on anything. I really *am*
just simply asking if there's a link for that anywhere to a real
file (html, pdf, text, wordperfect, gif, hell whatever.)


I converted it to pdf.  Do you want it?


Sure, please. If you could either post it here, or on the web, or email
nick1 at semitwist dot com, or whatever works for you that'd be
great. :)



http://1100110.in/static-if.pdf

(Powered by vibe.d  =P)

Re: About structs and performant handling

I think the type of the parameter that is passed is intrinsic 
to how the function gets compiled. I think, for that to work, 
the compiler would have to compile two versions of the 
function, one taking by-value and the other taking by-ref.


If we have this we have still the problem that moving a big 
struct is slow.
My 'make' is a lot faster. Therefore I suggested this new 
behaviour instead of the old deliberations about 'auto ref'. And 
I thought, because it is probable, that 'auto ref' will never 
work for non-template function, my Idea would be a nice 
alternative. :)

Re: About structs and performant handling

A better way to do with would be to change (or extend) the abi, 
so that
structs over a certain size are always passed by reference with 
this

parameter type.

And what if you want to pass it by value?
I am a opponent of such automatic and uncontrollable compiler 
intervention. Better to manually identify something to be on the 
safe side.



Then you only need one version of the function.  We could
use auto ref for this.
'auto ref' will probably never work for non-template functions, 
as Jonathan said some time ago.

Re: About structs and performant handling

Namespace rswhi...@googlemail.com wrote in message 
news:qmznbrplexqrdqahg...@forum.dlang.org...
 A better way to do with would be to change (or extend) the abi, so that
 structs over a certain size are always passed by reference with this
 parameter type.
 And what if you want to pass it by value?

You don't mark it with ''.

 I am a opponent of such automatic and uncontrollable compiler 
 intervention. Better to manually identify something to be on the safe 
 side.


Then I don't understand the point.  If it doesn't need to be automatic, you 
can just do it in your own code (use ref/not ref)

 Then you only need one version of the function.  We could
 use auto ref for this.
 'auto ref' will probably never work for non-template functions, as 
 Jonathan said some time ago.

That is not my understanding.

Re: About structs and performant handling


You don't mark it with ''.


Oh, then I understood you wrong.
I thought you meant that the compiler for each struct parameters 
(whether marked or not) just automatically perform such changes.



Then you only need one version of the function.  We could
use auto ref for this.
'auto ref' will probably never work for non-template 
functions, as Jonathan said some time ago.


That is not my understanding.


Read my thread 'auto ref - again'.

Re: About structs and performant handling

Namespace rswhi...@googlemail.com wrote in message 
news:aucfrmomyneucfykp...@forum.dlang.org...
 Then you only need one version of the function.  We could
 use auto ref for this.
 'auto ref' will probably never work for non-template functions, as 
 Jonathan said some time ago.

 That is not my understanding.

 Read my thread 'auto ref - again'.

If Jonathan made this claim in there, I must have missed it.  Regardless, 
there is an open pull request that implements auto ref, which has not been 
accepted or rejected yet.

I'd just like to say thanks for D

2013-03-09 Thread Jonathan M Davis

The more I deal with this language, the more I love it, and the more 
frustrating it is to deal with other languages (much as I like many of them as 
well). What we have isn't perfect, but overall, it's so clean and powerful 
that it's an absolute blast to work with. It's so amazingly easy to do so many 
things in it that are often frustratingly difficult in other languages. Ranges 
in particular make a huge difference in writing nicely idiomatic and 
straightforward code, but the language design as a whole is great (much as it 
still has a few warts - like all languages do).

So, I just felt like saying thanks to everyone who's put work into D and 
continues to do so. Keep up the good work!

Now, if only I could use it at work... :)

- Jonathan M Davis

Re: how to get top N distinct elements from range?

2013-03-09 Thread Andrea Fontana


On Saturday, 9 March 2013 at 01:36:53 UTC, bearophile wrote:


Is it a good idea to replace std.algorithm.filter with 
something like that filter2 (plus some missing methods)?


Bye,
bearophile


Maybe two versions (filter and cachedFilter) or a bool template 
param?


I was thinking about @pure front() too: but I think it's a wrong 
assumption. The right assumption would be that front should 
return the same value until popFront is called again. It can read 
front value lazily from front() call. It can do a lot of impure 
things (lol) but it shouldn't change front randomly at each 
call.


I would improve distinct to support an alias pred = a  b to 
build a bst instead of an AA.


Or just a field like distinct!a.id (that should work with aa 
backend)

Re: how to get top N distinct elements from range?

2013-03-09 Thread Andrea Fontana


On Saturday, 9 March 2013 at 09:13:26 UTC, Andrea Fontana wrote:

On Saturday, 9 March 2013 at 01:36:53 UTC, bearophile wrote:


Is it a good idea to replace std.algorithm.filter with 
something like that filter2 (plus some missing methods)?


Bye,
bearophile


Maybe two versions (filter and cachedFilter) or a bool template 
param?


I was thinking about @pure front() too: but I think it's a 
wrong assumption. The right assumption would be that front 
should return the same value until popFront is called again. It 
can read front value lazily from front() call. It can do a lot 
of impure things (lol) but it shouldn't change front randomly 
at each call.


I would improve distinct to support an alias pred = a  b to 
build a bst instead of an AA.


Or just a field like distinct!a.id (that should work with aa 
backend)


I almost got it:

auto distinct(alias fun = a, Range)(Range r)
if (isInputRange!Range) {
alias unaryFun!fun _fun;

bool[ReturnType!_fun] mySet;

return r.filter2!((k) {
if (_fun(k) in mySet)
return false;
mySet[_fun(k)] = true;
return true;
  });
}

ReturnType!_fun doesn't work, if i set to the right type, 
function works as expected

Re: how to get top N distinct elements from range?

2013-03-09 Thread Andrea Fontana


On Saturday, 9 March 2013 at 09:32:43 UTC, Andrea Fontana wrote:

On Saturday, 9 March 2013 at 09:13:26 UTC, Andrea Fontana wrote:

On Saturday, 9 March 2013 at 01:36:53 UTC, bearophile wrote:


Is it a good idea to replace std.algorithm.filter with 
something like that filter2 (plus some missing methods)?


Bye,
bearophile


Maybe two versions (filter and cachedFilter) or a bool 
template param?


I was thinking about @pure front() too: but I think it's a 
wrong assumption. The right assumption would be that front 
should return the same value until popFront is called again. 
It can read front value lazily from front() call. It can do a 
lot of impure things (lol) but it shouldn't change front 
randomly at each call.


I would improve distinct to support an alias pred = a  b to 
build a bst instead of an AA.


Or just a field like distinct!a.id (that should work with aa 
backend)


I almost got it:

auto distinct(alias fun = a, Range)(Range r)
if (isInputRange!Range) {
alias unaryFun!fun _fun;

bool[ReturnType!_fun] mySet;

return r.filter2!((k) {
if (_fun(k) in mySet)
return false;
mySet[_fun(k)] = true;
return true;
  });
}

ReturnType!_fun doesn't work, if i set to the right type, 
function works as expected



auto distinct(alias fun = a, Range)(Range r)
if (isInputRange!Range) {
alias unaryFun!fun _fun;

bool[typeof(_fun((ElementType!Range).init))] mySet;

return r.filter2!((k) {
if (_fun(k) in mySet)
return false;
mySet[_fun(k)] = true;
return true;
  });
}


struct User
{
int id;
string name;
}

void main() {
User[] users = [ {1, first}, {2, second}, {3, first}];

users.distinct!(a.id)().writeln;
users.distinct!(a.name)().writeln;

}

this works. Is this:
bool[typeof(_fun((ElementType!Range).init))] mySet;

the right way?

Re: Appender cannot add struct with immutable members