Re: this is almost a workaround for the lack of named parameters

[John Colvin]

On Friday, 22 March 2013 at 21:29:46 UTC, foobar wrote:

On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:

On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:


WTF? What do kwargs have to do with programming? Sounds more 
like a half-Klingon & half-Ferengi species to me.


kwargs = keyword arguments

It's a common naming convention in python, as exemplified in 
matplotlib.


That was meant more as a rhetorical question rather than a real 
one.
Yes, I guessed the meaning by the surrounding context but 
nevertheless it was a major WAT while skimming the post. Also, 
Who the fuck cares whats common in Python? I was reading and 
replying on the *D* NG, was I not?


Kwarg seems a reasonable name, consistent with a pre-existing 
convention. Please suggest a better alternative if you have one. 
I must admit I'm bemused by your level of aggression over what 
appears to be a trivial matter.

Re: D => asm.js for the web?

[John Colvin]

On Saturday, 23 March 2013 at 02:39:55 UTC, H. S. Teoh wrote:

On Sat, Mar 23, 2013 at 03:34:54AM +0100, Adam D. Ruppe wrote:

On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:
>I think someone will be happy to use D instead of C/C++ on 
>the web

>for performance-sensitive code, like games.

If it compiles to any kind of javascript it is a mistake to 
think
they'll be a performance boost over just writing javascript, 
with or
without annotations. Odds are there will be leaky abstractions 
in

the compile process that can hurt speed.


Any kind of translation from language X to language Y will 
incur at
least the performance overhead of language Y, plus some 
incidental
overhead incurred by non-trivial or imperfect mapping of X's 
features to

Y'es features. This incidental overhead is rarely every zero.

So there is no way translating from language X to language Y 
will be
faster than writing in language Y in the first place, no matter 
how good
your optimizer is. Otherwise, you might as well just write in 
language Y

to begin with, and run the optimizer on *that*.



I don't think you understood the point. asm.js is not the same as 
js. Pure js isn't involved anywhere along the translation path 
bearophile proposed except as a side-effect.

Re: this is almost a workaround for the lack of named parameters

[John Colvin]

On Saturday, 23 March 2013 at 15:00:13 UTC, bearophile wrote:

foobar:

Code that needs named parameters to be more readable is poorly 
designed code in the first place.


Have you used a language where the usage of named arguments is 
idiomatic, like Python, Scala or Ada? They are sometimes useful 
even for well designed code, like functions with two arguments.


Bye,
bearophile


A simple example is matplotlib.pyplot.plot

There are so many possible flags and parameters that can be 
passed in order to get the exact behaviour you want, but commonly 
you'll only want a few set for each call. You don't want to have 
to set all the other preceding parameters, you just want to go 
e.g. plot(data, linewidth=5)

Re: can't compile a simple class

[John Colvin]

On Saturday, 23 March 2013 at 21:12:25 UTC, Patrick Tinkham wrote:

On Saturday, 23 March 2013 at 21:08:39 UTC, Namespace wrote:
On Saturday, 23 March 2013 at 21:04:25 UTC, Patrick Tinkham 
wrote:
Sorry for the question. I am a n00b to D. I tried to compile 
the following code from Alexandrescu's book:


import std.stdio;
class A {
int x = 42;
}

unittest {
auto a1 = new A;
assert (a1.x == 42);
auto a2 = a1;
a2.x = 100;
assert (a1.x == 100);
}

at the command line:j

/d$ dmd c.d
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_473_1a5.o): In 
function `main':
src/rt/dmain2.d:(.text.main+0x4): undefined reference to 
`_Dmain'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_453_525.o): In 
function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4): 
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc): 
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x12): 
undefined reference to `_deh_end'


...

plus much more encrypted Klingon.

Help?


You need a main function:

import std.stdio;
class A {
 int x = 42;
}

unittest {
 auto a1 = new A;
 assert (a1.x == 42);
 auto a2 = a1;
 a2.x = 100;
 assert (a1.x == 100);
}

void main() { }


Thank you!!! (I guess I'm just accustomed to stand-alone 
classes in Java...)


dmd has a flag - - main that auto generates a blank main function 
to prevent linker errors.

Re: Proposal for SentinelInputRange

[John Colvin]

On Sunday, 24 March 2013 at 12:22:37 UTC, deadalnix wrote:
On Sunday, 24 March 2013 at 11:49:17 UTC, Andrei Alexandrescu 
wrote:

On 3/24/13 7:32 AM, deadalnix wrote:
I finally decided to write a post about such imaginary 
"sufficiently
smart compilers" that clearly don't exists today, never will 
and so we

have to clutter the language :
http://www.deadalnix.me/2013/03/23/a-story-about-optimization-llvm-and-the-sentinelinputrange/


I really hope that someone wrote this imaginary LLVM thing 
everybody is

talking about !


Looking great (also love the page design). The piece has a few 
systematic English language errors that should be easy to fix. 
Would you want to accept a copyedit step from a native 
speaker, and if so, is anyone here inclined to do that?




I'd be happy to, if someone want to do it.



Native English speaker here; I'd be happy to edit for grammar.

Re: Proposal for SentinelInputRange

[John Colvin]

On Sunday, 24 March 2013 at 12:22:37 UTC, deadalnix wrote:
On Sunday, 24 March 2013 at 11:49:17 UTC, Andrei Alexandrescu 
wrote:

On 3/24/13 7:32 AM, deadalnix wrote:
I finally decided to write a post about such imaginary 
"sufficiently
smart compilers" that clearly don't exists today, never will 
and so we

have to clutter the language :
http://www.deadalnix.me/2013/03/23/a-story-about-optimization-llvm-and-the-sentinelinputrange/


I really hope that someone wrote this imaginary LLVM thing 
everybody is

talking about !


Looking great (also love the page design). The piece has a few 
systematic English language errors that should be easy to fix. 
Would you want to accept a copyedit step from a native 
speaker, and if so, is anyone here inclined to do that?




I'd be happy to, if someone want to do it.


I copied and pasted in to libreoffice for editing: 
http://dl.dropbox.com/u/910836/sentinal.odt  or  
http://dl.dropbox.com/u/910836/sentinal.doc



There are 2 comments from me, they are in [] and highlighted in 
yellow. You'll probably want to address them and then delete them.


There were a lot of grammatical mistakes that have now been fixed 
and a couple of sentences have been rearranged. I had planned to 
work as Andrei suggested with "before -> after" but I quickly 
realised the edit file would be longer than the document!


P.S.
I may have accidentally introduced some British English by 
accident, perhaps a native American English speaker will spot 
them.

Re: Bug in using string mixins inside of a struct?

[John Colvin]

On Tuesday, 26 March 2013 at 21:28:16 UTC, Joseph Cassman wrote:

I get these errors

aggregate.d(11): Error: variable aggregate.A.c!("y").c cannot 
use template to add field to aggregate 'A'
aggregate.d(6): Error: template instance aggregate.A.c!("y") 
error instantiating


from compiling the following code

struct A
{
void b()
{
size_t y;
mixin(c!("y"));
}

template c(string x)
{
const char[] c = "
while(" ~ x ~ " < 100)
{
" ~ x ~ "++;
}";
}
}

I can only find bug 276 
(http://d.puremagic.com/issues/show_bug.cgi?id=276) which seems 
related but looks like it was fixed.


I am using dmd 2.062 on Ubuntu Linux 12.10.

Is this a bug? Or maybe bad code?

Thanks

Joseph


It's bad code. What were you hoping for the code to do?

Re: Bug in using string mixins inside of a struct?

[John Colvin]

On Tuesday, 26 March 2013 at 22:35:46 UTC, John Colvin wrote:

On Tuesday, 26 March 2013 at 21:28:16 UTC, Joseph Cassman wrote:

I get these errors

aggregate.d(11): Error: variable aggregate.A.c!("y").c cannot 
use template to add field to aggregate 'A'
aggregate.d(6): Error: template instance aggregate.A.c!("y") 
error instantiating


from compiling the following code

struct A
{
   void b()
   {
   size_t y;
   mixin(c!("y"));
   }

   template c(string x)
   {
   const char[] c = "
   while(" ~ x ~ " < 100)
   {
   " ~ x ~ "++;
   }";
   }
}

I can only find bug 276 
(http://d.puremagic.com/issues/show_bug.cgi?id=276) which 
seems related but looks like it was fixed.


I am using dmd 2.062 on Ubuntu Linux 12.10.

Is this a bug? Or maybe bad code?

Thanks

Joseph


It's bad code. What were you hoping for the code to do?


Sorry, I didn't read the code properly.

The template should be outside of the struct, then it works.

Re: Bug in using string mixins inside of a struct?

[John Colvin]

On Tuesday, 26 March 2013 at 23:00:40 UTC, Timon Gehr wrote:

On 03/26/2013 10:28 PM, Joseph Cassman wrote:

I get these errors

aggregate.d(11): Error: variable aggregate.A.c!("y").c cannot 
use

template to add field to aggregate 'A'
aggregate.d(6): Error: template instance aggregate.A.c!("y") 
error

instantiating

from compiling the following code

struct A
{
void b()
{
size_t y;
mixin(c!("y"));
}

template c(string x)
{
const char[] c = "
while(" ~ x ~ " < 100)
{
" ~ x ~ "++;
}";
}
}

I can only find bug 276
(http://d.puremagic.com/issues/show_bug.cgi?id=276) which 
seems related

but looks like it was fixed.

I am using dmd 2.062 on Ubuntu Linux 12.10.

Is this a bug? Or maybe bad code?



Bad code. Use enum for compile-time constants.

This will work:

struct A{
void b(){
size_t y;
mixin(c!("y"));
}

template c(string x){
enum c = "while(" ~ x ~ " < 100){" ~ x ~ "++;}";
}
}


Perhaps you can enlighten me:

why does "const c" work if the template is outside the struct, 
but not if it's inside?


Also, why doesn't "string c" work even outside of the struct, 
seeing as it's value is completely defined at compile-time?

Re: My thoughts & experiences with D so far, as a novice D coder

[John Colvin]

On Wednesday, 27 March 2013 at 15:34:20 UTC, Vidar Wahlberg wrote:

- The lack of "rectangular" arrays created at runtime in D 
("int i = 5; int[i][i] foo;") can be quite confusing for 
programmers with Java or C++ background. Even though there 
exists alternatives 
(http://denis-sh.github.com/phobos-additions/unstd.multidimensionalarray.html), 
this design decision and how to get around it when you really 
desire a "rectangular" array could be explained in more detail 
at http://dlang.org/arrays.html.



int i = 5;

auto foo = new int[][](i,i);

Re: My thoughts & experiences with D so far, as a novice D coder

[John Colvin]

On Wednesday, 27 March 2013 at 16:15:45 UTC, John Colvin wrote:

This is actually nothing to do with auto. It's endemic to all 
templated returns from functions and the same is true in c++ (I 
don't know enough about java generics to comment).


Sorry, I'd want to correct this to "This is only partly to do 
with auto".

Re: My thoughts & experiences with D so far, as a novice D coder

[John Colvin]

On Wednesday, 27 March 2013 at 15:34:20 UTC, Vidar Wahlberg wrote:

- While the "auto"-keyword often is great, it can lead to 
difficulties, especially when used as the return type of a 
function, such as "auto foo() { return bar; }". Sometimes you 
may wish to store the result of a function/method call as a 
global variable/class member, but when the function/method 
returns "auto" it's not apparent what the data type may be. 
While you may be able to find out what "bar" is by digging in 
the source code, it can still be difficult to find. One example 
is to save the result of "std.regex.match()" as a member in a 
class. For me the solution was to "import std.traits", create a 
function "auto matchText(string text) { return match(text, 
myRegex); }" and define the class member as 
"ReturnType!matchText matchResult;" (do also note that function 
& member must come in the right order for this to compile). 
This was all but obvious to a novice D coder as myself, the 
solution was suggested to me in the IRC channel.


This is actually nothing to do with auto. It's endemic to all 
templated returns from functions and the same is true in c++ (I 
don't know enough about java generics to comment).


A solution to your particular problem

class A(type_of_myRegex) {
alias ReturnType!(match!(string, type_of_myRegex)) RegexR;
RegexR r;
void foo(string text, type_of_myRegex myRegex) {
r = match(text, myRegex);
}
}

of course, if you only ever use one Regex type then of course you 
could do without the templating in the class and hard-code it in.

Re: My thoughts & experiences with D so far, as a novice D coder

[John Colvin]

On Wednesday, 27 March 2013 at 18:06:46 UTC, Vidar Wahlberg wrote:
I'm impressed and most grateful for the feedback, I've learned 
some new things today :)



int i = 5;
auto foo = new int[][](i,i);


Won't this create an array (with 5 elements) of arrays (with 5 
elements), also called a "jagged array"? Where memory is not 
necessarily continuously allocated and looking up values adds 
another layer of indirection?




Unfortunately yes.

However, it's not a hard problem to overcome with a wrapper 
struct over a contiguous array.

Re: DIP33: A standard exception hierarchy

[John Colvin]

On Monday, 1 April 2013 at 12:12:56 UTC, Lars T. Kyllingstad 
wrote:


But if all cleanup code is bypassed, what is the point in using 
the exception mechanism in the first place?  Why not just 
abort() and be done with it?


I can think of two reasons for throwing an Error rather than 
aborting directly:
1. You want a kind of "graceful" shutdown, in which destructors 
*are* called and make their best attempt at cleaning things up.
2. You want to catch it at some point, and perform some manual 
cleanup.


But if (1) does not happen, can you even hope to do something 
useful with (2)?  Your program is in the worst possible state 
it can be!


I'm no expert on these things, but:

Any chance of being in an invalid state - > undefined behaviour

Undefined behaviour - > your destructors/cleanup routine could in 
theory do anything.


Therefore, you're better off not trying to cleanup if program 
state could be invalid.



Anything that doesn't signal a possible invalid state should be 
sensibly catchable and run destructors etc. , anything that does 
should cut through the program like a knife and is catchable at 
your own risk.

Re: File compare/merge

[John Colvin]

On Monday, 1 April 2013 at 20:18:36 UTC, Andrei Alexandrescu 
wrote:

On 4/1/13 3:53 PM, Walter Bright wrote:
Life has gotten a lot easier for me trying to manage multiple 
branches

of D since I've been using file compare/merge tools.

I use winmerge for Windows, and meld for Linux. They are both 
free, and

work great.

What do you use?


It's a good discussion. Love meld but OSX installation is 
tenuous so I gave up on it. This morning I installed Octosplit 
(http://goo.gl/sgNWw) on Chrome this morning, it took seconds 
and it made diff viewing a lot better.


Andrei


Just started using Octosplit and I have to say it's really nice.

It is a little slow though on really big diffs, I tested it on a 
recent pull of mine to druntime (>2500 lines changed) it takes a 
few seconds for the tick box to appear, then the page hangs for a 
few more seconds once I click it.


Stil, hardly long to wait in the general scheme of things, 
especially compared to opening some applications.

Re: DIP33: A standard exception hierarchy

[John Colvin]

On Friday, 5 April 2013 at 13:42:02 UTC, deadalnix wrote:

Right now, it isn't even possible to try a graceful shutdown 
when really, the program is unlikely to be in a completely 
unpredictable state, especially in @safe code.


It is possible. Catch the error.

However, having the language pretend that it can make any logical 
guarantees to you like it does with exceptions (i.e. finally 
blocks, chaining etc.) only encourages people not to take Errors 
as seriously as one should.
Soon people are throwing errors where they should be exceptions 
and vice versa. Even worse: people will be catching errors 
everywhere and their code could be happily running for days 
performing undefined behaviour.


This is a similar situation to shared (although with some 
important differences). Making it easier to use would be like 
putting a seatbelt on a motorbike. Sure, it might be safer some 
of the time. It'll definitely require less care to use. But when 
the bike slips sideways underneath you going round a bend at 
80mph, you need to kick it away as fast as possible.
It'll save you all the times it *doesn't* matter, but it'll kill 
you that one time when it *does*.

Re: To help LDC/GDC

[John Colvin]

On Monday, 8 April 2013 at 12:39:58 UTC, Manu wrote:

On 8 April 2013 21:53, Iain Buclaw  wrote:


On 8 April 2013 12:41, deadalnix  wrote:


On Monday, 8 April 2013 at 09:41:52 UTC, Iain Buclaw wrote:


It uses some type information, eg:

const/immutable/wild  -> qualified const.
shared -> qualified volatile.
shared + const/wild -> qualified const/volatile.


const/wild can be muted via aliasing. I'm not sure how GCC's 
backend
understand const, but this seems unclear to me if this is 
correct.



GCC's backend is pretty much C/C++ semantics.  So the const 
qualifier is

shallow, and does not guarantee that no mutations will occur.



But D makes no further guarantee. I don't see how const in D is 
any
different than const in C++ in that sense? That's basically the 
concept of
const, it's not a useful concept for optimisation, only 
immutable is.


D const is transitive, surely that makes a difference/presents an 
opportunity?

Re: To help LDC/GDC

[John Colvin]

On Tuesday, 9 April 2013 at 15:42:38 UTC, Dicebot wrote:
On Tuesday, 9 April 2013 at 15:20:48 UTC, Andrei Alexandrescu 
wrote:

Not gonna argue latter but former is just wrong.

struct Test
{
int a;
pure int foo1() // strong pure
{
return 42;
}

pure int foo2() // weak pure
{
return a++;
}
}

Signature is the same for both functions.


Both are weakly pure.

Andrei


And that is even more surprising as foo2 perfectly matches 
concept of pure


Don't you mean foo1? I have no idea what i'm talking about but 
foo1 looks a lot more pure than foo2 to me.

Re: To help LDC/GDC

[John Colvin]

On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton 
Wakeling wrote:

On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the 
function's parameters as

const or immutable.


Sure, I accept that.  What I was meaning, though, was an 
up-front declaration
which would make the compiler shout if those necessary 
conditions were not met.


i.e.

  pure foo(int n) { ... } // compiles

  strong pure bar(int n) { ... } // compiler instructs you 
to make
 // variables const or 
immutable


Both are strongly pure.


is foo strongly pure because of n being a value type that cannot 
contain any indirection? (i.e. as far as the outside world is 
concerned you don't get any side effects whatever you do with it).


Is the same for structs that contain no indirection? Or do they 
have to be const/immutable?

Re: To help LDC/GDC

[John Colvin]

On Thursday, 11 April 2013 at 10:27:55 UTC, kenji hara wrote:

2013/4/11 John Colvin 


On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix wrote:

On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton 
Wakeling wrote:



On 04/10/2013 08:39 PM, Walter Bright wrote:

Sure there is. Declare the function as pure, and the 
function's

parameters as
const or immutable.



Sure, I accept that.  What I was meaning, though, was an 
up-front

declaration
which would make the compiler shout if those necessary 
conditions were

not met.

i.e.

  pure foo(int n) { ... } // compiles

  strong pure bar(int n) { ... } // compiler instructs 
you to make
 // variables const or 
immutable




Both are strongly pure.



is foo strongly pure because of n being a value type that 
cannot contain
any indirection? (i.e. as far as the outside world is 
concerned you don't

get any side effects whatever you do with it).

Is the same for structs that contain no indirection? Or do 
they have to be

const/immutable?



It is same for structs that has no *mutable* indirections. In 
below, all

functions are strongly pure.

module x;
struct S1 { int n; }
struct S2 { immutable int[] arr; }
struct S3 { int[] arr; }

pure int foo0(int n);
pure int foo1(S1);   // S1 has no indirections
pure int foo2(S2);   // S2 has no *mutable* indirections
pure int foo3(immutable ref S3 x);   // foo3 cannot access any 
mutable

indirections

Kenji Hara


right, gotcha!

Re: dmd command line options bad design: -offilename, -Ddocdir etc.

[John Colvin]

On Thursday, 11 April 2013 at 15:15:09 UTC, Andrej Mitrovic wrote:

On 4/11/13, Jonas Drewsen  wrote:

By "I think that would be the way to go" I did not necessary
refer to having both formats supported at the same time but
simply to use the standard way that people know.


Unix != universal standard.


Next best thing.

Re: Vote for std.process

[John Colvin]

On Friday, 12 April 2013 at 04:46:52 UTC, Jesse Phillips wrote:
It is that time, If you would like to see the proposed 
std.process include into Phobos please vote yes.


Yes! :)

Re: dmd command line options bad design: -offilename, -Ddocdir etc.

[John Colvin]

On Friday, 12 April 2013 at 09:54:30 UTC, Iain Buclaw wrote:

On 11 April 2013 17:57, Paulo Pinto  wrote:


Am 11.04.2013 17:20, schrieb John Colvin:

 On Thursday, 11 April 2013 at 15:15:09 UTC, Andrej Mitrovic 
wrote:



On 4/11/13, Jonas Drewsen  wrote:


By "I think that would be the way to go" I did not necessary
refer to having both formats supported at the same time but
simply to use the standard way that people know.



Unix != universal standard.



Next best thing.



Actually I would like to know how the desktop world would look 
like

had Apple bought BeOS instead.

This would mean no UNIX on the desktop, assuming Apple would 
have

won a similar market as of today.

--
Paulo



Linux would have still taken off... and UNIX would still be 
relevant on the

server market.  :)


Not to mention supercomputers. There's a reason why they use(d) 
UNIX and linux and it's not because of apple.

Release management.

[John Colvin]

[x-post from /r/programming]
It's not the most detailed article, but it does have a few 
interesting points. Perhaps there is something we can learn from 
their experience.


http://phonegap.com/2012/04/12/rolling-releases-how-apache-cordova-becomes-phonegap-and-why/

Enjoy :)

Re: dmd command line options bad design: -offilename, -Ddocdir etc.

[John Colvin]

On Friday, 12 April 2013 at 12:12:18 UTC, Paulo Pinto wrote:

On Friday, 12 April 2013 at 09:54:30 UTC, Iain Buclaw wrote:
On 11 April 2013 17:57, Paulo Pinto  
wrote:



Am 11.04.2013 17:20, schrieb John Colvin:

On Thursday, 11 April 2013 at 15:15:09 UTC, Andrej Mitrovic 
wrote:



On 4/11/13, Jonas Drewsen  wrote:

By "I think that would be the way to go" I did not 
necessary

refer to having both formats supported at the same time but
simply to use the standard way that people know.



Unix != universal standard.



Next best thing.



Actually I would like to know how the desktop world would 
look like

had Apple bought BeOS instead.

This would mean no UNIX on the desktop, assuming Apple would 
have

won a similar market as of today.

--
Paulo



Linux would have still taken off... and UNIX would still be 
relevant on the

server market.  :)



Linux took off because it provided a way to port UNIX software 
at cost zero.


The companies where I developed in commercial UNIX platforms 
they only used Linux as a way to avoid paying UNIX licenses, 
not because Linux was something great.


The enterprise world only cares about money.

--
Paulo


I think we can probably agree that linux has become something 
quite great, despite that not being the initial reason for 
adoption.


Even if you don't like the basic architecture that much, the 
community and frameworks built on top of it have been spectacular.

Re: 'exp' vs 'std'? Forked: Vote for std.process

[John Colvin]

On Friday, 12 April 2013 at 14:27:25 UTC, Manu wrote:
On 13 April 2013 00:04, Jesse Phillips 
 wrote:



On Friday, 12 April 2013 at 06:25:10 UTC, Manu wrote:

I see this pattern where something is designed, discussed, 
and then voted
into phobos. At this time the design looks good on paper, but 
there is

very
little practical experience using the library.
The problem then is, once accepted, people start using it, 
and at some
point some issues are found, or ideas for improvement are 
made based on
user experience, but the module can no longer be touched due 
to the

general
phobia of making breaking changes...



I think this needs to happen prior to the formal 
review/voting. I would
say it should be a precursor to starting the official review, 
however this
would raise the bar too high for things like Jacob's 
Serialization library;
he has a working library, but it isn't ready for Phobos and it 
would be
silly to require the translation prior to approving it for 
Phobos.


How we choose to add to the exp module would need some 
consideration.




I would say, everything, bar nothing.

The serialisation library is a good example. It's a complicated 
system, and
it has some history already, offering some confidence from the 
start.
Experience might suggest that it's more-or-less acceptable into 
phobos.
It's obviously seen a few projects, but once something is 
accepted into

phobos, I think it's fair to anticipate its usage to increase
significantly, and in many different kinds of projects.
As an independent library, it might be evaluated by a potential 
user, and
found not to satisfy the requirements for some reason... they 
move on and
continue looking at alternatives, nobody's the wiser. Once it's 
in phobos,
there's a temptation, even an encouragement to use it because 
it's
'standard'. At this point, it may be found that the project it 
wasn't
suitable for could be worked with some relatively minor 
changes, which
should be made, and the library becomes more useful and 
robust... phobos

doesn't support this pattern at the moment.

I maintain the position that it needs at least a year in the 
real world
before you can truly be confident in it. New things shouldn't 
be barred
from post-release tuning on account of "omg it's a breaking 
change!".


I strongly agree with this.

There needs to be a middle step between the wild-west of 
independent libraries and the strictly controlled world of 
standard library.

Re: 'exp' vs 'std'? Forked: Vote for std.process

[John Colvin]

On Friday, 12 April 2013 at 15:05:52 UTC, Manu wrote:
On 13 April 2013 00:41, Piotr Szturmaj  
wrote:



http://forum.dlang.org/thread/**jcksnp$ah8$1...@digitalmars.com

My idea was to ship exp branch with phobos so all users could 
look into

new code. Not all users follow github/newsgroups/etc.



Why a branch though? That implies that people are git-savvy 
(not as common

as you think), and that they even have git installed at all...
It should be an exp directory next to std, so anyone can use it.


Agreed. Git should not be required to *use* phobos, only to 
*contribute* to it.

Re: 'exp' vs 'std'? Forked: Vote for std.process

[John Colvin]

On Friday, 12 April 2013 at 16:31:50 UTC, Steven Schveighoffer 
wrote:
With the exp version, you either keep exp.module around forever 
as a public link to the std.module, or you force people's code 
to break even though no API has changed.


-Steve


I like the pragma idea better, but I don't see why an exp.module 
link couldn't just be deprecated then removed. Even if you have 
to keep it around for ages, it's hardly going to get in the way 
much.

Re: Zero timeout receive

[John Colvin]

On Saturday, 13 April 2013 at 01:26:16 UTC, James Wirth wrote:

The discussion:


http://forum.dlang.org/thread/mailman.426.1286264462.858.digitalmar...@puremagic.com?page=9


implies that:
   receiveTimeout(dur!"msecs"(0), some-callback-function)

is acceptable - meaning that no blocking occurs.  A simple 
experiment verifies this - but I hesitate to use "undocumented" 
features.  Some APIs would interpret the 0 as infinity.


I also fear that placing such a nonblocking recieve into the 
main event loop of a GUI program would impact performance - it 
would also be non-generic.  Is there a fast function which 
returns true just when the "mail box" is non-empty?


Thanks


Make a small test and time it. I personally wouldn't expect to 
see much slowdown from the extra code invoked by receiveTimeout 
compared to the rest of a busy loop.


However, either special casing receiveTimeout for 0 duration or 
introducing a new receiveNoBlock or similar would be good.

Re: Unit tests called multiple times?

[John Colvin]

On Friday, 12 April 2013 at 23:01:55 UTC, Steven Schveighoffer 
wrote:
On Fri, 12 Apr 2013 18:52:50 -0400, William 
 wrote:


I'm compiling a medium-sized project written in D with the 
-unittests flag.  I have some writeln statements in my unit 
tests, for debug purposes, and I've noticed that certain unit 
tests are being run more than once.  Sample output is along 
these lines:


DEBUG: unit test started...
DEBUG: loop found whatever
DEBUG: iteration successful
DEBUG: bar is equal to bar
DEBUG: unit test passed...
DEBUG: unit test started...
DEBUG: loop found whatever
DEBUG: iteration successful
DEBUG: bar is equal to bar
DEBUG: unit test passed...
DEBUG: unit test started...
DEBUG: loop found whatever
DEBUG: iteration successful
DEBUG: bar is equal to bar
DEBUG: unit test passed...

is this standard behavior for DMD?  Is it documented anywhere?
 It's not much of a problem, but it strikes me as rather odd, 
and makes the debug output difficult to read.


Are your unit tests inside templates?  If so, they are 
instantiated once per template.  To fix, move outside the 
template.


This actually can be a nice feature, and at the same time 
horrible.  It's nice because you can parameterize your unit 
tests!  It's horrible because you have to be careful your unit 
tests are valid for all possible instantiations!


-Steve


That's a really nice feature. By running the unittests a 
developer could verify that there isn't a latent bug in the 
library code revealed by their particular types (or a bug in 
their types of course). If we could leverage this more then bugs 
in phobos could be identified quicker.

Re: Bus error on 32bit OSX, not 64bit

[John Colvin]

On Sunday, 14 April 2013 at 14:48:40 UTC, Jacob Carlborg wrote:

This code:

http://pastebin.com/U5XdFfDq

Will result in a bus error when compiled as 32bit. Three ways 
the bus error won't happen:


* If I compile as 64bit everything works fine
* If the function "foo" is moved inline in the "main" function 
everything works fine
* If store the return value of "fp" in "foo" in a temporary 
variable and then return it


DMD 2.062
Mac OS X 10.8.2


Have you tried any debugging? Disassembly? It's quite hard for me 
(or anyone else for that matter) to diagnose when it's not a 
separately compilable example and there's no extra info.

Re: Bus error on 32bit OSX, not 64bit

[John Colvin]

On Sunday, 14 April 2013 at 18:50:52 UTC, Jacob Carlborg wrote:

On 2013-04-14 19:12, John Colvin wrote:

Have you tried any debugging? Disassembly? It's quite hard for 
me (or
anyone else for that matter) to diagnose when it's not a 
separately

compilable example and there's no extra info.


This is the dissassembly for the 64bit version:

http://pastebin.com/L30u3tMu

32bit version:

http://pastebin.com/tKVCTeZV

This is what Clang produces for basically the same code:

http://pastebin.com/JBcNupfs

The C code looks like:

http://pastebin.com/KS9QwB3A


That's a start. The relative offsets are missing from the calls 
though (I think), which makes it rather hard to decipher. What 
are you using to disassemble? "objdump -M intel -dr file.o" will 
give you more info. It's the standard linux tool for the job, 
available from macports.


Also, it would be good if you ran it with gdb, when it bus errors 
type 'disas' and post that. Then we'd be able to see what 
instruction it's occurring at (hopefully).

Re: Bus error on 32bit OSX, not 64bit

[John Colvin]

On Monday, 15 April 2013 at 07:22:08 UTC, Jacob Carlborg wrote:

On 2013-04-14 23:55, John Colvin wrote:

That's a start. The relative offsets are missing from the 
calls though
(I think), which makes it rather hard to decipher. What are 
you using to
disassemble? "objdump -M intel -dr file.o" will give you more 
info. It's

the standard linux tool for the job, available from macports.


Ok, I used obj2asm.

Also, it would be good if you ran it with gdb, when it bus 
errors type
'disas' and post that. Then we'd be able to see what 
instruction it's

occurring at (hopefully).


Ok, I'll do that.

I just tried the same example on Mac OS X 10.6.3 and it runs 
fine. The assembly is basically the same.


I wasn't able to install objdump, I'll try again tonight. This 
what otool gives:


http://pastebin.com/N8hMiKDe

This is the man page for otool, if there any particular flags 
you want me to use:


http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html


That otool output is missing foo. Other than that the flags 
you're using are fine.

Re: Bus error on 32bit OSX, not 64bit

[John Colvin]

On Sunday, 14 April 2013 at 14:48:40 UTC, Jacob Carlborg wrote:

This code:

http://pastebin.com/U5XdFfDq

Will result in a bus error when compiled as 32bit. Three ways 
the bus error won't happen:


* If I compile as 64bit everything works fine
* If the function "foo" is moved inline in the "main" function 
everything works fine
* If store the return value of "fp" in "foo" in a temporary 
variable and then return it


DMD 2.062
Mac OS X 10.8.2


Casting a function that returns void to a function that returns 
something seems bound to cause trouble. While it may be allowed 
in C It seems a bit of a leap to assume that it would work 
properly in D.

Re: Bus error interfacing with C function returning large struct

[John Colvin]

On Tuesday, 16 April 2013 at 19:26:09 UTC, Jacob Carlborg wrote:
The following code will result in a bus error on Mac OS X 
10.8.2 using DMD 2.062 compiled for 32bit (segfault on 64bit). 
A couple of notes:


* This code runs fine on Mac OS X 10.6.3
* It seems the struct has to be over 64 bits in size
* "foo" need to take an argument

Dissassembly at the bottom.

I think this is the same problem I had with interfacing with 
the objc_msgSend_stret function, see other post:


http://forum.dlang.org/thread/kkefk8$2663$1...@digitalmars.com

C code:

struct Foo
{
int a;
int b;
int c;
};

typedef struct Foo Foo;

Foo foo (int a)
{
Foo f;
f.a = 1;
f.b = 2;
f.c = 3;
return f;
}

D code:

struct Foo
{
int a;
int b;
int c;
}

extern (C) Foo foo (int a);

Foo bar ()
{
return foo(0);
}

extern (C) int printf(in char*, ...);

void main ()
{
auto frame = bar();
printf("a=%d b=%d c=%d\n".ptr, frame.a, frame.b, frame.c);
}

GDB session with dissassembly:

http://pastebin.com/rguwXucR

Dissassembly of the corresponding C program compiled with Clang:

http://pastebin.com/MG8Tnkzp

Dissassembly of "foo" on Mac OS X 10.8.2 using Clang 4.1:

http://pastebin.com/0jKqksxx

Dissassembly of "foo" on Mac OS X 10.6.3 using Clang 1.5:

http://pastebin.com/kbdfuVcB


Some observations:

Assuming main is doing everything properly, it's passing a 
pointer to 12 bytes of stack space to bar in eax (as per the D 
ABI). bar then puts that pointer on the stack for foo (as per the 
IA32 OS X ABI). However, it looks to me like it's in the wrong 
place, because of this line:

0x2673 : sub$0x8,%esp

This is just from a quick glance, I may have added my hexes 
wrongly.

Re: Bus error interfacing with C function returning large struct

[John Colvin]

On Tuesday, 16 April 2013 at 23:03:44 UTC, John Colvin wrote:

On Tuesday, 16 April 2013 at 19:26:09 UTC, Jacob Carlborg wrote:
The following code will result in a bus error on Mac OS X 
10.8.2 using DMD 2.062 compiled for 32bit (segfault on 64bit). 
A couple of notes:


* This code runs fine on Mac OS X 10.6.3
* It seems the struct has to be over 64 bits in size
* "foo" need to take an argument

Dissassembly at the bottom.

I think this is the same problem I had with interfacing with 
the objc_msgSend_stret function, see other post:


http://forum.dlang.org/thread/kkefk8$2663$1...@digitalmars.com

C code:

struct Foo
{
   int a;
   int b;
   int c;
};

typedef struct Foo Foo;

Foo foo (int a)
{
   Foo f;
   f.a = 1;
   f.b = 2;
   f.c = 3;
   return f;
}

D code:

struct Foo
{
   int a;
   int b;
   int c;
}

extern (C) Foo foo (int a);

Foo bar ()
{
   return foo(0);
}

extern (C) int printf(in char*, ...);

void main ()
{
   auto frame = bar();
   printf("a=%d b=%d c=%d\n".ptr, frame.a, frame.b, frame.c);
}

GDB session with dissassembly:

http://pastebin.com/rguwXucR

Dissassembly of the corresponding C program compiled with 
Clang:


http://pastebin.com/MG8Tnkzp

Dissassembly of "foo" on Mac OS X 10.8.2 using Clang 4.1:

http://pastebin.com/0jKqksxx

Dissassembly of "foo" on Mac OS X 10.6.3 using Clang 1.5:

http://pastebin.com/kbdfuVcB


Some observations:

Assuming main is doing everything properly, it's passing a 
pointer to 12 bytes of stack space to bar in eax (as per the D 
ABI). bar then puts that pointer on the stack for foo (as per 
the IA32 OS X ABI). However, it looks to me like it's in the 
wrong place, because of this line:

0x2673 : sub$0x8,%esp

This is just from a quick glance, I may have added my hexes 
wrongly.


I was wrong. Ignore the previous post.

Re: Bus error interfacing with C function returning large struct

[John Colvin]

On Tuesday, 16 April 2013 at 19:26:09 UTC, Jacob Carlborg wrote:
The following code will result in a bus error on Mac OS X 
10.8.2 using DMD 2.062 compiled for 32bit (segfault on 64bit). 
A couple of notes:


* This code runs fine on Mac OS X 10.6.3
* It seems the struct has to be over 64 bits in size
* "foo" need to take an argument

Dissassembly at the bottom.

I think this is the same problem I had with interfacing with 
the objc_msgSend_stret function, see other post:


http://forum.dlang.org/thread/kkefk8$2663$1...@digitalmars.com

C code:

struct Foo
{
int a;
int b;
int c;
};

typedef struct Foo Foo;

Foo foo (int a)
{
Foo f;
f.a = 1;
f.b = 2;
f.c = 3;
return f;
}

D code:

struct Foo
{
int a;
int b;
int c;
}

extern (C) Foo foo (int a);

Foo bar ()
{
return foo(0);
}

extern (C) int printf(in char*, ...);

void main ()
{
auto frame = bar();
printf("a=%d b=%d c=%d\n".ptr, frame.a, frame.b, frame.c);
}

GDB session with dissassembly:

http://pastebin.com/rguwXucR

Dissassembly of the corresponding C program compiled with Clang:

http://pastebin.com/MG8Tnkzp

Dissassembly of "foo" on Mac OS X 10.8.2 using Clang 4.1:

http://pastebin.com/0jKqksxx

Dissassembly of "foo" on Mac OS X 10.6.3 using Clang 1.5:

http://pastebin.com/kbdfuVcB


Martins reply in the bug report correctly identifies the problem, 
it's a bug in dmds implementation of the OS X IA32 ABI.


This is quite a severe bug, it's only by luck that eax was set to 
0 causing an immediate error.


I suggest it should be marked critical.

Re: Bus error interfacing with C function returning large struct

[John Colvin]

On Wednesday, 17 April 2013 at 11:14:52 UTC, Jacob Carlborg wrote:

On 2013-04-17 12:05, John Colvin wrote:

Martins reply in the bug report correctly identifies the 
problem, it's a

bug in dmds implementation of the OS X IA32 ABI.


I see. I'm still wondering why it works on Mac OS X 10.6.3, 
just luck?


clang just happened to put the arguments to foo in to registers 
different on 10.6.3
Instead of loading the 0 argument in to eax it loaded the pointer 
to the struct like it would in system V ABI (linux)


I have no idea whether this is a complete coincidence, or whether 
clang has changed it's approach to the OS X abi, or whether the 
ABI itself has changed.

Re: DConf 2013 official car/room sharing thread

[John Colvin]

On Thursday, 18 April 2013 at 17:04:49 UTC, Walter Bright wrote:

On 4/18/2013 1:23 AM, Iain Buclaw wrote:
Incidentally, I only get around by bicycle (even moved 400 
miles to a new home

on one last year).  =)


It's far too dangerous to commute by bike in Seattle. The 
streets are winding and narrow. I tried it briefly, but it 
wasn't worth it.


Is that USA winding and narrow, or something I would recognise as 
winding and narrow (UK)?

Re: DConf 2013 official car/room sharing thread

[John Colvin]

On Thursday, 18 April 2013 at 18:45:56 UTC, H. S. Teoh wrote:

On Thu, Apr 18, 2013 at 10:50:55AM -0700, Walter Bright wrote:

On 4/18/2013 10:42 AM, Iain Buclaw wrote:
>I certainly don't mind winding and narrow.   Cycling isn't 
>inherently
>dangerous, but the two main things that don't help are - lack 
>of

>cycle paths; careless or inconsiderate drivers.

When you have cars brushing by your elbow at 40 mph, well, I 
thought
that was very dangerous. When going around curves, cars 
routinely
cut into the inside shoulder. They'll do it on blind corners, 
too.


I'm actually surprised that a lot more bikers aren't killed 
around
here, although many are. I walk a lot, and many times I've had 
to

step lively off of the road.


Speaking of careless drivers... not long ago up here in 
Canuckland (a
few hours' drive from Seattle, incidentally), I almost got run 
over by a
car *while crossing a crosswalk with flashing lights*. There 
was another
vehicle which had come to a stop in the outer lane, which may 
have
obscured me, but the car in the inner lane obviously didn't see 
me and
didn't notice the big flashing lights above the crosswalk (and 
didn't
consider why the vehicle on her right had stopped at a 
crosswalk with

big flashing lights above).

Fortunately I was keeping an eye on it (I wasn't sure if it was 
slowing
down so I hesitated). The driver screamed (oh yeah did she 
scream -- I
could hear it through her closed windows) and slammed the 
brakes when
she saw me, but couldn't stop in time; I stepped back just in 
time as

she passed in front of me about 1-2 feet at the most.

Since then, I no longer assume that red lights, pedestrian walk 
signs,
or crosswalk flashing lights mean anything to drivers. You 
might pay for

that assumption with your life. *shudder*


T


In quite a bit of mainland europe, red lights only apply to 
straight on traffic and not to people turning. The number of 
times I almost got killed by cars turning into me in a single 
week in Rome was ridiculous!

Re: DConf 2013 official car/room sharing thread

[John Colvin]

On Thursday, 18 April 2013 at 20:31:14 UTC, Iain Buclaw wrote:
On 18 April 2013 19:01, Walter Bright 
 wrote:



On 4/18/2013 10:50 AM, Walter Bright wrote:

I'm actually surprised that a lot more bikers aren't killed 
around here,
although many are. I walk a lot, and many times I've had to 
step lively

off of
the road.



There's also a politically powerful bike lobby around here, 
but I don't

think this is a problem that can be solved by politics.


Cycle paths and routes can still be developed through state 
funding.  One
of the best things for cyclists in the UK is the national cycle 
network,
which through experience is a great way to get around the 
country.


It's amazing what the netherlands have done for cycling: 
http://en.wikipedia.org/wiki/Cycling_in_the_Netherlands

Re: Attribute inference for auto functions?

[John Colvin]

On Friday, 19 April 2013 at 12:43:49 UTC, Piotr Szturmaj wrote:


What about this:

auto inferReturnTypeAndAttributes() { ... }
auto(return) inferOnlyReturnType() { ... }

or since all attributes are constraints, it can be rewritten to:

auto inferOnlyReturnType() pure nothrow @safe { ... }

It really doesn't make sense to infer impurity, throwing or 
unsafety because these are the default.


I imagine there are some use cases where programmer for example 
wants to infer all but purity, possibly because some other part 
of the code relies on pure behavior of his function, and he 
doesn't care about the other attributes. Example of pure 
function where nothrow and safety are inferred:


auto inferAllButPurity() pure { ... }

To sum up:

1. auto   - infers all
2. auto(return)   - infers only a return type
3. auto fn() attrs... - infers return type and all not 
specified attributes


Second and third are equivalent, thus auto(return) is optional.

There were some voices about breaking overriden functions by 
adding/inferring superclass function attribute. I think this is 
an oversight, virtual functions should not have attributes 
inferred.


I like this. It provides a good balance of control and automation.

how would template functions be treated with auto(return)?

Re: DIP 36: Rvalue References

[John Colvin]

On Saturday, 20 April 2013 at 15:23:35 UTC, deadalnix wrote:

On Saturday, 20 April 2013 at 15:17:39 UTC, Namespace wrote:
I don't think adding more to the language is the sane thing 
to do right now.


Why not? Could you explain this?
This issue is discussed since more than a year and it is a 
very annoying issue.
And even if Walter and Andrei are of this opinion, it would 
still only polite when they explain in detail why they think 
this.


Listen, this issue is very real, but it is mostly about 
performance. I'll tell you something : the best performance 
improvement is the one that bring your program from non working 
state to working one. And right now, many existing feature are 
broken.


The let's add whatever feature we have in mind is the very 
cause of the state of the language right now.


Sadly, I have to agree on this. As nice as many new feature ideas 
are, they are far from priorities when there are multiple core 
mechanics that are broken.

Re: DIP 36: Rvalue References

[John Colvin]

On Saturday, 20 April 2013 at 16:11:49 UTC, Namespace wrote:
Sadly, I have to agree on this. As nice as many new feature 
ideas are, they are far from priorities when there are 
multiple core mechanics that are broken.


There is no reason to prioritize DIP 36. Kenji, Dicebot and I 
did most of the work. The DIP is written and all necessary 
information are described in detail there with examples. The 
code also exists and there is even a pull request which has 
passed all the tests. Thus, this proposal is linked with not 
much work. Most of it was taken over by others.
Due to this, it really is not asking too much to get a note if 
this pull is accepted or rejected. Of course, with detailed 
justification.


How about "on hold"? (Not that I have any say in it at all)

The fact is, there's much more to any change than simply 
implementing it. Changes break unexpected things. There are 
always extra corner cases not considered. There are always bugs 
and inconsistencies.


Although it's great that you and some others have done the 
legwork to implement this proposal, it may have to wait until 
other more urgent problems have been fixed.

Re: Compiler / Language Infrastructure

[John Colvin]

On Sunday, 21 April 2013 at 15:09:48 UTC, Suminda Dharmasena 
wrote:

 - separate grammar definition


This is being worked on:
http://forum.dlang.org/thread/iabqtohohovkxjwtw...@forum.dlang.org

Digitalmars (i.e. Walter Bright) is a big part of D development 
but it is primarily a community driven open-source project.

alias symbols in object files

[John Colvin]

test.d:

extern (C):
void foo(){}
alias foo bar;

$dmd -c test.d

$nm test.o
 t
 D _D11test12__ModuleInfoZ
 w _d_dso_registry
 U _Dmodule_ref
 T foo


Surely the aliased symbol should appear in the object file, or am 
I missing something?

Re: alias symbols in object files

[John Colvin]

On Sunday, 21 April 2013 at 18:54:27 UTC, John Colvin wrote:

test.d:

extern (C):
void foo(){}
alias foo bar;

$dmd -c test.d

$nm test.o
 t
 D _D11test12__ModuleInfoZ
 w _d_dso_registry
 U _Dmodule_ref
 T foo


Surely the aliased symbol should appear in the object file, or 
am I missing something?


Just to avoid any confusion for non-linux guys:

nm is a linux utility for listing the symbols in an object file.

Re: alias symbols in object files

[John Colvin]

On Sunday, 21 April 2013 at 19:22:27 UTC, Peter Alexander wrote:

On Sunday, 21 April 2013 at 18:54:27 UTC, John Colvin wrote:
Surely the aliased symbol should appear in the object file, or 
am I missing something?


What would you expect it to look like in the object file? A 
duplicate of the foo function?


Something like that, yes.

I have a templated function and need particular instantiations of 
it in a library. If aliases cannot be used for this, I suppose 
the most reasonable option is to write wrapper functions.

template mixin function name mangling

[John Colvin]

Apologies for another question so short after the previous one.

tempmix.d:

mixin template Foo()
{
extern(C) void foo() {}
}

mixin Foo!();

extern(C) void bar() {}


$dmd -c tempmix.d
$nm tempmix.o
 t
 T bar
 D _D7tempmix12__ModuleInfoZ
 T _D7tempmix15__unittest_failFiZv
 T _D7tempmix7__arrayZ
 T _D7tempmix8__assertFiZv
 W _D7tempmix8__T3FooZ3fooUZv
 U _d_array_bounds
 U _d_assertm
 w _d_dso_registry
 U _Dmodule_ref
 U _d_unittestm

foo gets mangled D-style, bar is left bare. Is this deliberate? I 
was under the impression that they should both be left bare.


I tried moving the extern(C) around to various other places, 
including extern(C): at the top of the file. No success.

Re: template mixin function name mangling

[John Colvin]

On Monday, 22 April 2013 at 09:03:24 UTC, Peter Alexander wrote:

mixin template A() {
extern(C) int foo() { return 1; }
}

mixin template B() {
extern(C) int foo() { return 2; }
}

mixin A a;
mixin B b;

void main() {
int x = a.foo() + b.foo();
}

If both foo's have the same symbol, then how am I able to 
disambiguate them in code?


Maybe duplicate extern(C) template mixin symbols need to be an 
error?


If there are true duplicates then it would need to be an error. 
However, if a mixin uses a mixin identifier then it's going to 
need to be mangled anyway, so only


mixin A;
mixin B;

would have to be an error. It already is an error, but 
unfortunately only when you reference the content of the mixin, 
not at the mixin statement.

extern(C) System V ABI choices

[John Colvin]

Currently complex types are not passed in accordance with the 
System V ABI when using extern(C) on linux x64, (dmd git master, 
no flags):


extern(C):

cfloat cf(cfloat a)
{
return a;
}
// a is expected on the stack (not the fpu stack) and returned in 
XMM0:XMM1 (real in one, imaginary in the other I presume. Lots of 
empty space.)


cdouble cd(cdouble a)
{
return a;
}
// a is expected in XMM0:XMM1, a hidden pointer argument to some 
stack space is expected in RDI, filled from a and is returned in 
RAX


creal cr(creal a)
{
return a;
}
// a is expected on the stack (not fpu stack), a hidden pointer 
argument to some stack space is passed in RDI, filled from a and 
is returned in RAX.



/*

Would it not be better to make these compliant with the 
equivalent types specified in the System V ABI (when using 
extern(C) on linux x64)? It would ease interactions with other 
languages.


*/


As specified here: 
http://refspecs.linuxfoundation.org/elf/x86_64-abi-0.95.pdf


cfloat would be passed as real -> XMM and imag -> XMM
and returned identically

cdouble would be passed as real -> XMM and imag -> XMM
and returned identically

creal would be passed on the stack (not fpu)
and returned as real -> ST and imag -> ST


I recognise that these types are supposed to be phased out in 
favour of std.complex. However, seeing as that doesn't seem to be 
happening any time soon, getting the ABI right would be good for 
now.

D runtime in os x dylib

[John Colvin]

There seems to be a problem with starting the d runtime in a d 
dylib loaded in a c program. Whenever I call Runtime.initialize() 
i get a segfault.


C code:

#include 
#include 

int main() {
void *library;
int (*fptr)();
library = dlopen("testlib.dylib", RTLD_LAZY);
if(library == NULL)
puts("couldn't load the library");
else {
*(void **)(&fptr) = dlsym(library,"number");
if(fptr == NULL) {
puts("couldn't load function");
}
else {
printf("the result is %d\n",(*fptr)());
}
}
return(0);
}

compiled with gcc, no flags.

d code:

import core.runtime;

extern(C) int number() {
Runtime.initialize();
return(4);
}

compiled with dmd -shared

Backtrace:

Program received signal EXC_BAD_ACCESS, Could not access 
memory.

Reason: 13 at address: 0x
0x00010003de28 in __tls_get_addr ()
(gdb) bt
#0  0x00010003de28 in __tls_get_addr ()
#1  0x00010003cdfc in thread_attachThis ()
#2  0x00010003ccb8 in thread_init ()
#3  0x00010003e312 in gc_init ()
#4  0x000100044ff5 in rt_init ()
#5  0x00010003b637 in 
D4core7runtime7Runtime10initializeFDFC6object9ThrowableZvZb ()

#6  0x000100034ee9 in number ()
#7  0x00010e84 in main ()

All compilation and debugging done in OS X 10.7

Note: if the Runtime.initialize(); line is commented out, the 
library is loaded and runs correctly.

Re: D runtime in os x dylib

[John Colvin]

On Sunday, 24 June 2012 at 09:59:18 UTC, Jacob Carlborg wrote:

On 2012-06-23 22:54, John Colvin wrote:
There seems to be a problem with starting the d runtime in a d 
dylib
loaded in a c program. Whenever I call Runtime.initialize() i 
get a

segfault.


Dynamic libraries aren't properly working yet. It's being 
worked on.


I see that now, managed to dig up some old bug reports and 
threads. Is there any timeframe for this or is it on the back 
burner so to speak?

Re: D runtime in os x dylib

[John Colvin]

Hmm, nothing in the last 3 months. Looks like i may have to 
abandon os x for development at least for the near future.


On Sunday, 24 June 2012 at 12:41:15 UTC, Jacob Carlborg wrote:

On 2012-06-24 13:47, John Colvin wrote:

I see that now, managed to dig up some old bug reports and 
threads. Is
there any timeframe for this or is it on the back burner so to 
speak?


I'm not sure of the time frame for this but Martin Nowak is 
working on this:


https://github.com/dawgfoto/druntime/commits/SharedRuntime

Re: D runtime in os x dylib

[John Colvin]

On Monday, 25 June 2012 at 12:17:03 UTC, Jacob Carlborg wrote:

On 2012-06-24 16:39, John Colvin wrote:
Hmm, nothing in the last 3 months. Looks like i may have to 
abandon os x

for development at least for the near future.


I'm not entirely sure but maybe you're having this problem:

http://d.puremagic.com/issues/show_bug.cgi?id=7995

Pull the latest source code from github and try that if you're 
using a release.


I'm having a nightmare getting the runtime to compile, with 
MODEL=64 I get a load of these:


src/core/simd.d(35): Error: base type of __vector must be a 16 
byte static array, not void[32LU]
src/core/simd.d(52): Error: template instance 
core.simd.Vector!(void[32LU]) error instantiating
src/core/simd.d(35): Error: base type of __vector must be a 16 
byte static array, not double[4LU]
src/core/simd.d(53): Error: template instance 
core.simd.Vector!(double[4LU]) error instantiating
src/core/simd.d(35): Error: base type of __vector must be a 16 
byte static array, not float[8LU]
src/core/simd.d(54): Error: template instance 
core.simd.Vector!(float[8LU]) error instantiating
src/core/simd.d(35): Error: base type of __vector must be a 16 
byte static array, not byte[32LU]
src/core/simd.d(55): Error: template instance 
core.simd.Vector!(byte[32LU]) error instantiating
src/core/simd.d(35): Error: base type of __vector must be a 16 
byte static array, not ubyte[32LU]
src/core/simd.d(56): Error: template instance 
core.simd.Vector!(ubyte[32LU]) error instantiating
src/core/simd.d(35): Error: base type of __vector must be a 16 
byte static array, not short[16LU]
src/core/simd.d(57): Error: template instance 
core.simd.Vector!(short[16LU]) error instantiating
src/core/simd.d(35): Error: base type of __vector must be a 16 
byte static array, not ushort[16LU]
src/core/simd.d(58): Error: template instance 
core.simd.Vector!(ushort[16LU]) error instantiating
src/core/simd.d(35): Error: base type of __vector must be a 16 
byte static array, not int[8LU]
src/core/simd.d(59): Error: template instance 
core.simd.Vector!(int[8LU]) error instantiating
src/core/simd.d(35): Error: base type of __vector must be a 16 
byte static array, not uint[8LU]
src/core/simd.d(60): Error: template instance 
core.simd.Vector!(uint[8LU]) error instantiating
src/core/simd.d(35): Error: base type of __vector must be a 16 
byte static array, not long[4LU]
src/core/simd.d(61): Error: template instance 
core.simd.Vector!(long[4LU]) error instantiating
src/core/simd.d(35): Error: base type of __vector must be a 16 
byte static array, not ulong[4LU]
src/core/simd.d(62): Error: template instance 
core.simd.Vector!(ulong[4LU]) error instantiating


I tried MODEL=32 just in case and got the same but with "u" 
insteal of "LU"

Re: D runtime in os x dylib

[John Colvin]

On Monday, 25 June 2012 at 18:55:22 UTC, Jacob Carlborg wrote:


Are you using the latest sources of DMD?


Yes I am.

Re: D runtime in os x dylib

[John Colvin]

On Tuesday, 26 June 2012 at 18:31:34 UTC, John Colvin wrote:

On Monday, 25 June 2012 at 18:55:22 UTC, Jacob Carlborg wrote:


Are you using the latest sources of DMD?


Yes I am.


sorry, my mistake, i replaced the wrong dmd file. It compiles 
fine with the up to date dmd.

Re: D runtime in os x dylib

[John Colvin]

On Wednesday, 27 June 2012 at 10:15:37 UTC, Jacob Carlborg wrote:

On 2012-06-27 02:35, John Colvin wrote:

On Tuesday, 26 June 2012 at 18:31:34 UTC, John Colvin wrote:

On Monday, 25 June 2012 at 18:55:22 UTC, Jacob Carlborg wrote:


Are you using the latest sources of DMD?


Yes I am.


sorry, my mistake, i replaced the wrong dmd file. It compiles 
fine with

the up to date dmd.


Good, is that working any better ?


Yes, it appears the bug is fixed in the current druntime. Thanks 
for your help.

Tuple/TypeTuple etc.

[John Colvin]

Denis has been complaining about this for ages and I think it's 
worth doing something about.


Definitions:

std.typecons.Tuple
A bit like python's tuples. It's a heterogeneous collection of 
runtime values with compile-time determined types.


std.typetuple.TypeTuple
A heterogeneous *compile-time* collection of types, expressions 
and aliases.



Problems:

TypeTuple isn't just a typetuple, it's an everythingtuple. It's a 
terrible name that is confusing to newcomers (and even to people 
who've used D a lot but not delved in to the CT capabilities so 
much).


TypeTuple looks too much like Tuple. It's a totally different 
concept but the names are too similar.



Possible solutions:

1) rename TypeTuple in-place to something better. This is not a 
real option as it would break far too much code.


2) Introduce a new tuple constructor with a new name, and 
deprecate TypeTuple


2a) A whole new module, leaving std.typetuple as effectively an 
alias to the new module. Denis has a pull for this[1], which also 
adds new tuple constructors specialised for expressions.



I like Denis' pull request. It fixes the problem in a backwards 
compatible manner. However - as Jonathan points out in the 
comments - the naming is still a problem. GenericTuple, 
ExpressionTuple etc. all sound like they could be related to 
std.typecons.Tuple


So, we need a new name:
Sequence, ArgList or ParamList are possible suggestions.


A possible complete path to getting this sorted, using Sequence 
as an example:


1) Create a new module like in Denis' PR, called std.sequence and 
containing the template Sequence, equivalent to current 
std.typetuple.TypeTuple


1a) optional: include specific templates like TypeSequence and 
ExpressionSequence.


2) Leave std.typetuple as an alias to the new module, including 
alias TypeTuple = Sequence; Deprecate it.


3) std.traits.isTypeTuple becomes isTypeSequence and 
isExpressionTuple becomes isExpressionSequence.   Deprecated 
aliases from the old names are left for compatibility.


4) Change phobos over to using std.sequence (note that this is 
not required immediately, as there is 100% backwards 
compatibility).


The only remaining headache would be people getting confused by 
dmd spewing out complaints about tuple(blah, blah, blah), but 
that's a relatively minor concern.



P.S. please note that deprecating is not breaking, per se. 
Deprecations are just warnings by default. Also, although having 
compatibility aliases floating around is annoying, it's an 
unfortunate necessity if one wants to change things while not 
breaking everyone's code. I think it's a model we're going to 
have to get used to in order to be both flexible and reliable.


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

Re: Tuple/TypeTuple etc.

[John Colvin]

On Friday, 16 August 2013 at 16:08:42 UTC, bearophile wrote:

John Colvin:


Possible solutions:


My vote is for solution n.5:

Add the built-in t{} syntax to denote all kind of tuples.

Bye,
bearophile


There was no number 5...

A builtin syntax would be cool, I agree.

Re: GPGPUs

[John Colvin]

On Friday, 16 August 2013 at 19:55:56 UTC, luminousone wrote:
The core (!) point here is that processor chips are rapidly 
becoming a
collection of heterogeneous cores. Any programming language 
that assumes

a single CPU or a collection of homogeneous CPUs has built-in
obsolescence.

So the question I am interested in is whether D is the 
language that can
allow me to express in a single codebase a program in which 
parts will
be executed on one or more GPGPUs and parts on multiple CPUs. 
D has

support for the latter, std.parallelism and std.concurrency.

I guess my question is whether people are interested in 
std.gpgpu (or

some more sane name).


CUDA, works as a preprocessor pass that generates c files from 
.cu extension files.


In effect, to create a sensible environment for microthreaded 
programming, they extend the language.


a basic CUDA function looking something like...

__global__ void add( float * a, float * b, float * c) {
   int i = threadIdx.x;
   c[i] = a[i] + b[i];
}

add<<< 1, 10 >>>( ptrA, ptrB, ptrC );

Their is the buildin variables to handle the index location 
threadIdx.x in the above example, this is something generated 
by the thread scheduler in the video card/apu device.


Generally calls to this setup has a very high latency, so using 
this for a small handful of items as in the above example makes 
no sense. In the above example that would end up using a single 
execution cluster, and leave you prey to the latency of the 
pcie bus, execution time, and latency costs of the video memory.


it doesn't get effective until you are working with large data 
sets, that can take advantage of a massive number of threads 
where the latency problems would be secondary to the sheer 
calculations done.


as far as D goes, we really only have one build in 
microthreading capable language construct, foreach.


However I don't think a library extension similar to 
std.parallelism would work gpu based microthreading.


foreach would need to have something to tell the compiler to 
generate gpu bytecode for the code block it uses, and would 
need instructions on when to use said code block based on 
dataset size.


while it is completely possible to have very little change with 
function just add new property @microthreaded and the build in 
variables for the index position/s, the calling syntax would 
need changes to support a work range or multidimensional range 
of some sort.


perhaps looking something like

add$(1 .. 10)(ptrA,ptrB,ptrC);

a templated function looking similar

add!(float)$(1 .. 10)(ptrA,ptrB,ptrC);


We have a[] = b[] * c[] - 5; etc. which could work very neatly 
perhaps?

Re: Tuple/TypeTuple etc.

[John Colvin]

On Friday, 16 August 2013 at 16:03:22 UTC, John Colvin wrote:
Denis has been complaining about this for ages and I think it's 
worth doing something about.


Definitions:

std.typecons.Tuple
A bit like python's tuples. It's a heterogeneous collection of 
runtime values with compile-time determined types.


std.typetuple.TypeTuple
A heterogeneous *compile-time* collection of types, expressions 
and aliases.



Problems:

TypeTuple isn't just a typetuple, it's an everythingtuple. It's 
a terrible name that is confusing to newcomers (and even to 
people who've used D a lot but not delved in to the CT 
capabilities so much).


TypeTuple looks too much like Tuple. It's a totally different 
concept but the names are too similar.



Possible solutions:

1) rename TypeTuple in-place to something better. This is not a 
real option as it would break far too much code.


2) Introduce a new tuple constructor with a new name, and 
deprecate TypeTuple


2a) A whole new module, leaving std.typetuple as effectively an 
alias to the new module. Denis has a pull for this[1], which 
also adds new tuple constructors specialised for expressions.



I like Denis' pull request. It fixes the problem in a backwards 
compatible manner. However - as Jonathan points out in the 
comments - the naming is still a problem. GenericTuple, 
ExpressionTuple etc. all sound like they could be related to 
std.typecons.Tuple


So, we need a new name:
Sequence, ArgList or ParamList are possible suggestions.


A possible complete path to getting this sorted, using Sequence 
as an example:


1) Create a new module like in Denis' PR, called std.sequence 
and containing the template Sequence, equivalent to current 
std.typetuple.TypeTuple


1a) optional: include specific templates like TypeSequence and 
ExpressionSequence.


2) Leave std.typetuple as an alias to the new module, including 
alias TypeTuple = Sequence; Deprecate it.


3) std.traits.isTypeTuple becomes isTypeSequence and 
isExpressionTuple becomes isExpressionSequence.   Deprecated 
aliases from the old names are left for compatibility.


4) Change phobos over to using std.sequence (note that this is 
not required immediately, as there is 100% backwards 
compatibility).


The only remaining headache would be people getting confused by 
dmd spewing out complaints about tuple(blah, blah, blah), but 
that's a relatively minor concern.



P.S. please note that deprecating is not breaking, per se. 
Deprecations are just warnings by default. Also, although 
having compatibility aliases floating around is annoying, it's 
an unfortunate necessity if one wants to change things while 
not breaking everyone's code. I think it's a model we're going 
to have to get used to in order to be both flexible and 
reliable.


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


How do you guys feel about ctList/CtList/CTList?

Re: GPGPUs

[John Colvin]

On Friday, 16 August 2013 at 22:11:41 UTC, luminousone wrote:

On Friday, 16 August 2013 at 20:07:32 UTC, John Colvin wrote:
We have a[] = b[] * c[] - 5; etc. which could work very neatly 
perhaps?


While this in fact could work, given the nature of GPGPU it 
would

not be very effective.

In a non shared memory and non cache coherent setup, the 
entirety

of all 3 arrays have to be copied into GPU memory, had that
statement ran as gpu bytecode, and then copied back to complete
the operation.

GPGPU doesn't make sense on small code blocks, both in
instruction count, and by how memory bound a particular 
statement

would be.

The compiler needs to either be explicitly told what can/should
be ran as a GPU function, or have some intelligence about what 
to

or not to run as a GPU function.

This will get better in the future, APU's using the full HSA
implementation will drastically reduce the "buyin" latency/cycle
cost of using a GPGPU function, and make them more practical for
smaller(in instruction count/memory boundess) operations.


I didn't literally mean automatically inserting GPU code.

I was more imagining this:

void foo(T)(T[] arr)
{
useArray(arr);
}

auto a = someLongArray;
auto b = someOtherLongArray;

gpu
{
auto aGPU = toGPUMem(a);
auto bGPU = toGPUMem(b);

auto c = GPUArr(a.length);

c[] = a[] * b[];

auto cCPU = toCPUMem(c);
c.foo();

dot(c, iota(c.length).array().toGPUMem())
.foo();
}

gpu T dot(T)(T[] a, T[] b)
{
//gpu dot product
}


with cpu arrays and gpu arrays identified separately in the type 
system. Automatic conversions could be possible, but of course 
that would allow carelessness.


Obviously there is some cpu code mixed in with the gpu code 
there, which should be executed asynchronously if possible. You 
could also have

onlyGPU
{
//only code that can all be executed on the GPU.
}



Just ideas off the top of my head. Definitely full of holes and I 
haven't really considered the detail :)

Re: Tuple/TypeTuple etc.

[John Colvin]

On Saturday, 17 August 2013 at 01:01:10 UTC, Dicebot wrote:
Currently it is not the case. typeof(tuple(1,2)) is 
Tuple!(int,int), not TypeTuple!(int, int). But 
typeof(TypeTuple(1,2)) is TypeTyple!(int, int) :)


Whu?

There is no such type as TypeTuple!(int, int), it is completely 
aliased away to a builtin tuple.


Also, printing out types is actually rather misleading, as it 
chooses when to use or not use tuple() in annoying ways e.g. 
TypeTuple!(int, string) is (int, string) but TypeTuple!(int, 3) 
is tuple(int, 3)   Either they are both tuples, or neither is.


To the best of my knowledge, there is only this:

1) collections of items, called tuples. They can contain pretty 
much anything you want, as long it's available at compile-time.
They are ***not types***. If and only if a tuple contains only 
types, the tuple itself is a type. This is often referred to as a 
type-tuple. In current D, tuples of all varieties are created by 
variadic template parameters.*


2) instantiations of type-tuples. These are a collection of 
runtime values, individually accessible by indexing or foreach 
iteration. std.typecons.Tuple is a wrapper around one of these 
providing some extra functionality.


*std.typetuple.TypeTuple only exists to provide convenient syntax 
for this.

Re: std.serialization: pre-voting review / discussion

[John Colvin]

On Saturday, 17 August 2013 at 08:29:37 UTC, glycerine wrote:

On Wednesday, 14 August 2013 at 13:43:50 UTC, Dicebot wrote:

On Wednesday, 14 August 2013 at 13:28:42 UTC, glycerine wrote:

Wishful thinking aside, they are competitors.


They are not. `std.serialization` does not and should not 
compete in Thrift domain.


Huh? Do you know what thrift does? Summary: Everything that
Orange/std.serialization does and more. To the point: Thrift
provides data versioning, std.serialization does not. In my 
book:

end of story, game over. Thrift is preffered choice.


Thrift is the preferred choice when choosing a library for ALL 
your possible serialization needs and more. However, standard 
library modules are not about including every possible 
convenience, it's about providing solid building blocks for 
creating larger frameworks.


What you're suggesting leads directly to the clearly idiotic like 
"std.stdio sucks because it's doesn't have a printRainbows 
feature"

Re: Tuple/TypeTuple etc.

[John Colvin]

On Saturday, 17 August 2013 at 12:37:23 UTC, Dicebot wrote:

On Saturday, 17 August 2013 at 11:43:09 UTC, John Colvin wrote:

On Saturday, 17 August 2013 at 01:01:10 UTC, Dicebot wrote:
Currently it is not the case. typeof(tuple(1,2)) is 
Tuple!(int,int), not TypeTuple!(int, int). But 
typeof(TypeTuple(1,2)) is TypeTyple!(int, int) :)


Whu?

There is no such type as TypeTuple!(int, int), it is 
completely aliased away to a builtin tuple.


Yeah but there is no syntax for them so I am using TypeTuple 
for unambiguity. pragma(msg) will print (int, int) for it.


ok, fair enough.

Also, printing out types is actually rather misleading, as it 
chooses when to use or not use tuple() in annoying ways e.g. 
TypeTuple!(int, string) is (int, string) but TypeTuple!(int, 
3) is tuple(int, 3)   Either they are both tuples, or neither 
is.


They are two types of built-in tuples - pure type tuples and 
expression/mixed tuples. typeof expression tuple is type tuple. 
Those have same syntax but slightly different semantics.


Not quite, there are pure type-tuples (can be used as a type), 
pure expression-tuples (can be assigned to) and mixed tuples. But 
then there's also aliases...

int a;
auto b = TypeTuple!(a);
b[0] = 3;
assert(a == 0);  //passes
clearly b is an instantiation of a typetuple (or an 
expression-tuple, as you point out), but what is actually going 
on in it's initialisation?



To the best of my knowledge, there is only this:

1) collections of items, called tuples. They can contain 
pretty much anything you want, as long it's available at 
compile-time.
They are ***not types***. If and only if a tuple contains only 
types, the tuple itself is a type. This is often referred to 
as a type-tuple. In current D, tuples of all varieties are 
created by variadic template parameters.*


All true but last statement. They are not "created" anywhere, 
this is simply most convenient way to capture built-in tuple in 
a form usable by user code.


That's what i mean by created. I deliberated over what word to 
use there for quite a while, but perhaps "capture" is better. 
Either way, you've got some ct stuff and you want to group it 
together in to a tuple, variadic template parameters is the way 
to do it.


2) instantiations of type-tuples. These are a collection of 
runtime values, individually accessible by indexing or foreach 
iteration. std.typecons.Tuple is a wrapper around one of these 
providing some extra functionality.


As far as I can observe, instantiations of type tuples are 
expression tuples.


That's an interesting way of looking at it. I didn't realise one 
could do this:

auto ET = TypeTuple!(2, "2");
ET[0] = 5;   //perfectly fine

And std.typecons.Tuple is completely different beast, it simply 
a template struct.


Yes, as I said: It's a wrapper around an instantiation of a 
type-tuple.




Every time I think I understand this, there's more...

Re: Tuple/TypeTuple etc.

[John Colvin]

On Saturday, 17 August 2013 at 14:04:21 UTC, Dicebot wrote:

On Saturday, 17 August 2013 at 13:55:10 UTC, John Colvin wrote:
And std.typecons.Tuple is completely different beast, it 
simply a template struct.


Yes, as I said: It's a wrapper around an instantiation of a 
type-tuple.


By that logic every single possible template with variadic 
parameters is wrapper around instantiation of type tuple. 
std.typecons.Tuple does not store expression tuple inside so I 
don't think it is legal to call it a "wrapper". Simply 
pseudo-anonymous struct with pseudo-anonymous fields.


I'm afraid if you look at the implementation of 
std.typecons.Tuple, it does exactly what you say it doesn't do. 
The struct-like aspects (e.g. named access) are simulated using 
aliases.

Re: Tuple/TypeTuple etc.

[John Colvin]

On Saturday, 17 August 2013 at 15:50:51 UTC, Timon Gehr wrote:

http://wiki.dlang.org/The_D_Programming_Language/Seq


I added a little bit on multiple return values.

Re: Experiments with emscripten and D

[John Colvin]

On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote:

On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote:

On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:
>Every time I do, I get the urge to abandon programming and 
>change

>my occupation.

My thoughts too, The Internet is ripe for another revolution, 
but
the old ways need to be abandoned rather than continually 
propped up
with duct tape and thread. You can barely create simple 
applications
using current html+js tools, and Flash and so forth consume 
vast
amounts of memory and cpu power which can  stress out even a 
full
blown desktop computer if you are a heavy browser user like I 
am,
yet most "personal computers" are now low powered mobile 
devices

which makes the situation really bad.

IMO the current direction leads to a dead end.

The big boys like Google, Mozilla and MS seem more interested 
in
fighting each other over world domination rather than come up 
with

viable alternatives that can lead the way out of this mess.

[...]

It's just like Nick Sabalausky always likes to rant about. In 
1975, we

had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, and our
applications ran rather slowly.  Then processor speed increased
exponentially, RAM increased exponentially, and today we have 
64-bit
computers with 4GHz CPUs (and multicore!) and who knows how 
many GBs of
RAM, and our (web) applications run at about the same speed as 
in 1975.

Clearly, *something* is very, very wrong with this picture.


T


How do we fix it? We have a great language here, let's 
revolutionise the web :p

Re: Experiments with emscripten and D

[John Colvin]

On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote:

On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote:

On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh wrote:
>On Sat, Aug 17, 2013 at 05:30:28PM +0200, Rob T wrote:
>>On Saturday, 17 August 2013 at 14:42:19 UTC, Gambler wrote:
>>>Every time I do, I get the urge to abandon programming and 
>>>change

>>>my occupation.
>>
>>My thoughts too, The Internet is ripe for another 
>>revolution, but
>>the old ways need to be abandoned rather than continually 
>>propped up
>>with duct tape and thread. You can barely create simple 
>>applications
>>using current html+js tools, and Flash and so forth consume 
>>vast
>>amounts of memory and cpu power which can  stress out even a 
>>full
>>blown desktop computer if you are a heavy browser user like 
>>I am,
>>yet most "personal computers" are now low powered mobile 
>>devices

>>which makes the situation really bad.
>>
>>IMO the current direction leads to a dead end.
>>
>>The big boys like Google, Mozilla and MS seem more 
>>interested in
>>fighting each other over world domination rather than come 
>>up with

>>viable alternatives that can lead the way out of this mess.
>[...]
>
>It's just like Nick Sabalausky always likes to rant about. In 
>1975,
>we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, 
>and our
>applications ran rather slowly.  Then processor speed 
>increased
>exponentially, RAM increased exponentially, and today we have 
>64-bit
>computers with 4GHz CPUs (and multicore!) and who knows how 
>many GBs
>of RAM, and our (web) applications run at about the same 
>speed as in
>1975.  Clearly, *something* is very, very wrong with this 
>picture.

>
>
>T

How do we fix it? We have a great language here, let's 
revolutionise

the web :p


Yeah! vibe.d FTW! :) And the client-side version thereof. :)


T


Yeah the server-side is relatively easy to pull off, seeing as 
you're completely in control there.


The client side is an eensy little bit harder haha. It would 
probably require heavily modifying/creating a new web-browser and 
then convincing people to use it.


I wonder how powerful browser extensions can be these days...

Re: Experiments with emscripten and D

[John Colvin]

On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:

On Sat, Aug 17, 2013 at 09:07:20PM +0200, John Colvin wrote:

On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote:
>On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote:
>>On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh 
>>wrote:

[...]
>>>It's just like Nick Sabalausky always likes to rant about. 
>>>In 1975,
>>>we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, 
>>>and our
>>>applications ran rather slowly.  Then processor speed 
>>>increased
>>>exponentially, RAM increased exponentially, and today we 
>>>have
>>>64-bit computers with 4GHz CPUs (and multicore!) and who 
>>>knows how
>>>many GBs of RAM, and our (web) applications run at about 
>>>the same
>>>speed as in 1975.  Clearly, *something* is very, very wrong 
>>>with

>>>this picture.

[...]
>>How do we fix it? We have a great language here, let's 
>>revolutionise

>>the web :p
>
>Yeah! vibe.d FTW! :) And the client-side version thereof. :)

[...]

Yeah the server-side is relatively easy to pull off, seeing as
you're completely in control there.

The client side is an eensy little bit harder haha. It would
probably require heavily modifying/creating a new web-browser 
and

then convincing people to use it.

I wonder how powerful browser extensions can be these days...


Hmm. That's an idea, write an extension that can run code 
through rdmd.
(You have to deliver the source rather than the object code, 
since you

don't know what OS your client is running on.)


not necessarily. The extension would know and could tell the 
server which version to send (with an optional fallback to code 
for systems that you don't have a binary ready for). It could 
also query shared library / dll versions.

Also, you could just send llvm IR...

Requiring an extension puts it in the same boat as Flash, 
though. :-(


An extension today, built-in to the browser tomorrow?

And you'd have to sandbox the code since arbitrary D code 
running wild
on the user's computer is a Bad Thing(tm). Which runs into 
GC-related
issues when your client is a low-memory handheld device. Though 
arguably

this would still be an improvement over JS, since an interpreted
language necessarily uses more resources.


T


most, if not all operating systems have good sandboxing, don't 
they? iOS sandboxes the hell out of everything and I presume 
android does something similar. on linux you can use selinux 
utility sandbox or similar.

Re: Experiments with emscripten and D

[John Colvin]

On Saturday, 17 August 2013 at 20:58:09 UTC, Dicebot wrote:

On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:
And you'd have to sandbox the code since arbitrary D code 
running wild
on the user's computer is a Bad Thing(tm). Which runs into 
GC-related
issues when your client is a low-memory handheld device. 
Though arguably
this would still be an improvement over JS, since an 
interpreted

language necessarily uses more resources.


You are getting pretty close to NaCl idea :)


Yeah, I was thinking that :p

NaCl seems designed mostly as native extensions for the 
html/js/css world.


I was thinking bigger: The browser as a (transient, if 
appropriate) application delivery system.


I really dislike html and css for anything other than simple 
documents, it quickly feels like one big patchily supported 
corner-case. Anything other than simple uses ends up requiring 
significant abuses, even if you're lucky enough to be working in 
a hypothetical totally standards compliant environment. Even 
something as simple as a drop-down menu with persistence means 
either: massively abuse css OR use JS.


What I'm imagining is a truly dynamic web-delivered UI with 
native speed and processing capability, not just a faster web-app.

Re: Experiments with emscripten and D

[John Colvin]

On Saturday, 17 August 2013 at 21:16:59 UTC, John Colvin wrote:

On Saturday, 17 August 2013 at 20:58:09 UTC, Dicebot wrote:

On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:
And you'd have to sandbox the code since arbitrary D code 
running wild
on the user's computer is a Bad Thing(tm). Which runs into 
GC-related
issues when your client is a low-memory handheld device. 
Though arguably
this would still be an improvement over JS, since an 
interpreted

language necessarily uses more resources.


You are getting pretty close to NaCl idea :)


Yeah, I was thinking that :p

NaCl seems designed mostly as native extensions for the 
html/js/css world.


I was thinking bigger: The browser as a (transient, if 
appropriate) application delivery system.


I really dislike html and css for anything other than simple 
documents, it quickly feels like one big patchily supported 
corner-case. Anything other than simple uses ends up requiring 
significant abuses, even if you're lucky enough to be working 
in a hypothetical totally standards compliant environment. Even 
something as simple as a drop-down menu with persistence means 
either: massively abuse css OR use JS.


What I'm imagining is a truly dynamic web-delivered UI with 
native speed and processing capability, not just a faster 
web-app.


This would still be working - to some extent, in the browser:
the end user experience can be as seamless or as seperated as the 
developer wants. Your D app could look just like a webpage and 
behave just like a webpage, or it could be a totally separate 
window that appears to have no relation to the web as we know it.


For an increasing number of users these days, the browser *is* 
the computer. They barely touch anything else. Nobody wants to 
install another program to do every little task, but they'll 
happily click a link to a specialised web-app. Native apps took 
off on mobile, but at the same time they were dying on the 
desktop. Now the view seems to be to want to kill them on mobile 
too and make everything a web-app. Perhaps we can get the best of 
both worlds.


What I want is a true way out from the current obsession with 
trying to shoe-horn every possible use-case in to html/css/js 
with the associated necessary over-reliance on js, which is by 
all accounts a horrible language.

Re: Experiments with emscripten and D

[John Colvin]

On Sunday, 18 August 2013 at 04:52:16 UTC, deadalnix wrote:

I feel pretty confident I can do a wat speech for D.


I can't think of many wats. There are questionable design 
decisions, annoying things that look like they should compile but 
don't (local variable alias to non-global template errors 
anyone?) and performance pitfalls, but nothing so gloriously 
broken as what javascript achieves.


Coming from a C(++) perspective has prevented a lot of complete 
gibbering insanity from occurring. In particular, having a basic 
respect for data-layout at the machine level and an ethos of not 
doing very costly implicit type type-conversions has staved off a 
whole horde of crazy.

Re: Experiments with emscripten and D

[John Colvin]

On Sunday, 18 August 2013 at 12:48:49 UTC, deadalnix wrote:

On Sunday, 18 August 2013 at 11:21:52 UTC, John Colvin wrote:

On Sunday, 18 August 2013 at 04:52:16 UTC, deadalnix wrote:

I feel pretty confident I can do a wat speech for D.


I can't think of many wats. There are questionable design 
decisions, annoying things that look like they should compile 
but don't (local variable alias to non-global template errors 
anyone?) and performance pitfalls, but nothing so gloriously 
broken as what javascript achieves.




I know many of them. That is probably because I'm working on 
SDC, so I have to dig into dark corner of the language, 
nevertheless, it is really possible to do.


In fact I planned to do it, but Denis Korskin warned me about 
the bad image it would create of D, and I have to admit he was 
right, so I abandoned the idea.


I presume they are at least documented somewhere? A page on the 
wiki? I'd be interested to see them myself. Who knows, maybe some 
of them are fixable?


Coming from a C(++) perspective has prevented a lot of 
complete gibbering insanity from occurring. In particular, 
having a basic respect for data-layout at the machine level 
and an ethos of not doing very costly implicit type 
type-conversions has staved off a whole horde of crazy.


I'm not here for nothing :D


good point :)

Re: GPGPU and D

[John Colvin]

On Sunday, 18 August 2013 at 08:40:33 UTC, Russel Winder wrote:

Luminousone, Atash, John,

Thanks for the email exchanges on this, there is a lot of good 
stuff in
there that needs to be extracted from the mail threads and 
turned into a
"manifesto" type document that can be used to drive getting a 
design and
realization together. The question is what infrastructure would 
work for
us to collaborate. Perhaps create a GitHub group and a 
repository to act

as a shared filestore?

I can certainly do that bit of admin and then try and start a 
document
summarizing the email threads so far, if that is a good way 
forward on

this.


A github group could be a good idea, for sure. A simple wiki page 
with some sketched out goals would be good too, which I guess 
would draw on the content of the previous thread.


Anyway, I can't really get too involved right now, my masters 
thesis is due in a terrifyingly small amount of time.
However, come September and onwards I could definitely spend some 
serious time on this. If everything goes to plan I might well be 
able to justify working on such a project as a part of my PhD.

Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?

[John Colvin]

On Sunday, 18 August 2013 at 18:08:58 UTC, Dicebot wrote:
Yes, in limited circumstances if you write D like you would 
write C, you can get comparative performance.


I'd say in all cases when you mimic C behavior in D one should 
expect same or better performance with ldc/gdc unless you hit a 
bug.


array literal allocations. I guess that's debatably a performance 
bug.

Re: GPGPUs

[John Colvin]

On Sunday, 18 August 2013 at 18:19:06 UTC, Dejan Lekic wrote:

On Tuesday, 13 August 2013 at 18:21:12 UTC, eles wrote:
On Tuesday, 13 August 2013 at 16:27:46 UTC, Russel Winder 
wrote:
The entry point would be if D had a way of creating GPGPU 
kernels that

is better than the current C/C++ + tooling.


You mean an alternative to OpenCL language?

Because, I imagine, a library (libopencl) would be easy enough 
to write/bind.


Who'll gonna standardize this language?


Tra55er did it long ago - look at the cl4d wrapper. I think it 
is on GitHub.


I had no idea that existed. Thanks :) 
https://github.com/Trass3r/cl4d

Re: GPGPU and D

[John Colvin]

On Sunday, 18 August 2013 at 18:30:29 UTC, Russel Winder wrote:

On Sun, 2013-08-18 at 19:46 +0200, John Colvin wrote:

A github group could be a good idea, for sure. A simple wiki 
page with some sketched out goals would be good too, which I 
guess would draw on the content of the previous thread.


If I remember correctly in order to make a GitHub group you 
have to make
a user with an email address and convert it to a group.  I can 
set up a
temporary mail list on my SMTP server for this so no problem. 
The real
problem is what to call the group and the project. Anyone any 
ideas?


Anyway, I can't really get too involved right now, my masters 
thesis is due in a terrifyingly small amount of time.
However, come September and onwards I could definitely spend 
some serious time on this. If everything goes to plan I might 
well be able to justify working on such a project as a part of 
my PhD.


I too have not as much time to actually code on this as I would 
like in
the short term, but it is better to actually do little bits 
than nothing
at all. So having the infrastructure in place is an aid for 
little

things to happen to keep the momentum going. Albeit a small
momentum. :-)

Good luck with the thesis writing.  What is the topic? Which 
university?


I always have a bad time explaining it haha, here's the title: 
Automated tracing of divergent ridges in tokamak magnetic spectra.


Basically, the fusion guys at culham produce load of spectrograms 
and have very little systematic workflow for analysing them. It's 
almost all done done by eye. I've developed a new ridge tracing 
algorithm and applied it to the spectra, with then some extra 
steps to identify particular magnetic events that occur in the 
reactors. It's all a bit ad-hoc, but it'll do for a masters by 
research.


I'm at Univeristy of Warwick, Engineering department (coming from 
a physics BSc). I'll be joint physics and engineering for the 
PhD, continuing (read reinventing-from-scratch) the same work.


There are so much data with so much heavy duty processing that a 
GPU solution will probably be a good choice. We have a HPC 
cluster with some GPU compute nodes* so for me, being able to 
target them efficiently - both in runtime and developer-time 
terms - would be great. Much more interesting that just spamming 
the data proc nodes, anyway! I would have to persuade the the 
sysadmins to install gdc/ldc though...


*(6 nodes, each with 2 NVIDIA Tesla M2050 GPUs, 48 GB RAM and 2 
Intel Xeon X5650s)

Re: My thoughts on D

[John Colvin]

On Monday, 19 August 2013 at 10:10:58 UTC, Larry wrote:

Hello,

Maybe nobody cares, maybe not.

I use D for a month now.

It is great, the community is great.
Really easy to handle it enables to get the productivity it 
promises.


Almost.

I used to run c++. I don't even want to look at my codes now.

Instead, I run python along with D.

D is very powerful.

But it suffers in the details.

1) The library is getting wider. Good. But as of now, it is 
still TOO MUCH in the c++ style, in which you have to go to 
github to grab some non official libraries.
Sometimes it works, sometimes it won't (of course it will 
compile but not easy to use or error prone -> not a good 
standard for a language)


2) In comparison, when you use Python, everything is under your 
hand. No real need to go on github or so on to keep working. 
Everything feels "safe".
We miss a "gathering point". A bit like pip or the deprecated 
easy-install.


dub is a D package manager. Depending on your OS, you might have 
to download *it* from github, but after that you'll have a wide 
range of tools at your fingertips. http://code.dlang.org/


3) Some pages are not documented properly. And, as i am not 
someone pointing out the problems and hiding when time comes to 
propose solutions/solve them, I cannot even figure out the way 
some standard libraries are expected to work.
(e.g:json; the json.org might be helpful but, common, we should 
have it directly here, not traversing the web (exagerated) to 
find a clue).


4) Even the merge with 4.9 is no help on these points. 
Gathering people, yes, showing them a path to follow to be able 
to stick together, double yes.

But the latter seems, ATM, a big no.
I know many of you are really smart, so just take this 
mataphorism : Napoleon, even if one of the greatest commander, 
would have got far if no backed by generals and a great army 
knowing where it is going.
Let's make a courtesy to D : please do not let it be jailed in 
Elbe island. It only asks to fly.


It is definitely not a bad criticism, please do not take it for 
such platitude.

I would like to see D far beyond what it is currently.

You made a GREAT job. Now, let the community help. We need 
batteries included (python-like). Then everyone will like it: 
compiled-ultra speed + great useful and centralized libraries.


English is not my native speaking, please be kind with it :)

Thanks,

Larry

Re: Any cryptographically secure pseudo-random number generator (CSPRNG) for D?

[John Colvin]

On Monday, 19 August 2013 at 15:56:04 UTC, ilya-stromberg wrote:

On Sunday, 18 August 2013 at 19:32:50 UTC, QAston wrote:
You may be interested in 
https://github.com/D-Programming-Deimos/openssl - D bindings 
for openssl.


How can I get access to the /dev/random or /dev/urandom (Linux 
only)? Like a file via std.file, or D have spesial function?


I don't know of any special function to access them.

Re: A Discussion of Tuple Syntax

[John Colvin]

On Monday, 19 August 2013 at 16:53:06 UTC, Wyatt wrote:
Note: I'm leading off with a reply to bearophile transplanted 
here to stop making OT noise in John's thread about TypeTuple.


On Friday, 16 August 2013 at 23:23:59 UTC, bearophile wrote:


It's short, clear, has a precedent with q{}.


Wait, what is q{}?  That's something in D?  What does that even 
do?  I can infer that q{} is probably some manner of scoping or 
grouping _something_ somehow, but I have to dig into lexical 
and manually search for q{ to find out it's [neither of the 
things I expected].  In my view, this right here is really just 
a fundamental problem with single-character prefixes and I feel 
that's something we should endeavour to avoid, if possible.



I don't like it a lot, but it's way better than not having
language support for tuples.


On this, I think we all agree.

I'd prefer just using parentheses, but I think there were 
readability problems that caused the DIP to end up with:


More than just readability problems. They were discussed when 
Kenji presented the DIP 32 in this forum. Timon found a 
significant problem with the {} syntax.


To be clear, I'm not talking about braces, {}; I'm talking 
about parentheses, ().  I read over that whole DIP32 thread a 
couple times, and didn't see any rationale offered for why the 
likely "cleanest" version "can't be used".  It wasn't even 
brought up (unless I've missed something subtle).  In the 
second thread, linked in the OP here, they were glossed over 
again.  Now, I fully believe there's a very good reason that's 
been written somewhere, but I _would_ like to know what that 
is, preferably documented somewhere less ephemeral and 
difficult to search than the newsgroup (such as in DIP32).  The 
closest I've seen so far is the pull request where Walter and 
Andrei expressed that it should be considered further.


On Friday, 16 August 2013 at 21:07:52 UTC, Meta wrote:
- #(a, b) is unambiguous and would probably be the easiest 
option. I don't think it looks too bad, but some people might 
find it ugly and noisy


The octothorpe _is_ much better than the t simply in terms of 
readability, though, even more than q{} or t{}, I have concerns 
about its ability to be found with an ordinary search engine by 
an ordinary user.  Have you tried looking for documentation on 
weird operators with a search engine lately?  They don't 
exactly take to it well. :/ (cf. Perl's <=>)




All we have left from the standard keyboard layout as far as 
single keys go is # and ¬
I don't think the mathematics crowd would be too happy with ¬ not 
meaning not.


The only op() options I can think of that aren't ambiguous:
$(a, b)
%(a, b)
^(a, b)
&(a, b) //I like this one
:(a, b)
#(a, b)
'(a, b) //I think
/(a, b)
\(a, b)

(a, b)

<(a, b)
|(a, b)
¬(a, b) //not in std ascii
?(a, b)

however, most of those are binary operators too, so it could be 
quite accident prone and confusing to look at


Some of this could be helped by enforcing at least 1 ','.

e.g.

  &(3)   //illegal
  &(3,)  //legal

There is precedent for this in python.

Re: When compiling multiple source files

[John Colvin]

On Monday, 19 August 2013 at 17:15:35 UTC, ProgrammingGhost wrote:

On Monday, 19 August 2013 at 11:01:54 UTC, Jacob Carlborg wrote:
The compiler will start compiling the files passed on the 
command line. It will read the files asynchronously and then 
lex, parse build an AST and do semantic analyze.


When the semantic analyze is done it will have access to all 
import declarations. It basically starts the same processes 
for all these imports, recursively.


The reason for waiting until semantic analyze is done because 
you can have code looking like this:


mixin("import foo;");

The expansion of the mixin and other similar features are done 
in the semantic analyze phase.


So everything is parsed once and kept in memory until the 
compiler finish every source file? Is there any ram problems 
when compiling large codebases?


Unfortunately, yes, if you give dmd a very large number of files 
all at once, it will chew through all your free RAM. But dmd does 
support separate compilation:


$dmd file1.d -c
$dmd file2.d -c
$dmd file1.o file2.o

which alleviates the problem.

My experience with D is limited. Are libraries the same as C 
libraries? From my understanding the linker figures that part 
out and the compiler needs a separate file for the definition. 
If I build a library in D is it the same as a C library or 
different which includes function definitions?


Sorry if I'm confused I know almost nothing about D. I stick to 
.NET, java and C++


Libraries in D use the same formats as C/C++ libraries.

Re: Possible solution to template bloat problem?

[John Colvin]

On Monday, 19 August 2013 at 20:23:46 UTC, H. S. Teoh wrote:
With D's honestly awesome metaprogramming features, templates 
are liable
to be (and in fact are) used a LOT. This leads to the 
unfortunate
situation of template bloat: every time you instantiate a 
template, it
adds yet another copy of the templated code into your object 
file. This
gets worse when you use templated structs/classes, each of 
which may
define some number of methods, and each instantiation adds yet 
another

copy of all those methods.

This is doubly bad if these templates are used only during 
compile-time,
and never referenced during runtime. That's a lot of useless 
baggage in

the final executable. Plus, it leads to issues like this one:

http://d.puremagic.com/issues/show_bug.cgi?id=10833

While looking at this bug, I got an idea: what if, instead of 
emitting
template instantiations into the same object file as 
non-templated code,
the compiler were to emit each instantiation into a separate 
static

*library*? For instance, if you have code in program.d, then the
compiler would emit non-templated code like main() into 
program.o, but
all template instantiations get put in, say, libprogram.a. Then 
during
link time, the compiler runs `ld -oprogram program.o 
libprogram.a`, and

then the linker will pull in symbols from libprogram.a that are
referenced by program.o.

If we were to set things up so that libprogram.a contains a 
separate
unit for each instantiated template function, then the linker 
would
actually pull in only code that is actually referenced at 
runtime. For

example, say our code looks like this:

struct S(T) {
T x;
T method1(T t) { ... }
T method2(T t) { ... }
T method3(T t) { ... }
}
void main() {
auto sbyte  = S!byte();
auto sint   = S!int();
auto sfloat = S!float();

sbyte.method1(1);
sint.method2(2);
sfloat.method3(3.0);
}

Then the compiler would put main() in program.o, and *nothing 
else*. In
program.o, there would be undefined references to 
S!byte.method1,
S!int.method2, and S!float.method3, but not the actual code. 
Instead,
when the compiler sees S!byte, S!int, and S!float, it puts all 
of the

instantiated methods inside libprogram.a as separate units:

libprogram.a:
struct_S_byte_method1.o:
S!byte.method1
struct_S_byte_method2.o:
S!byte.method2
struct_S_byte_method3.o:
S!byte.method3
struct_S_int_method1.o:
S!int.method1
struct_S_int_method2.o:
S!int.method2
struct_S_int_method3.o:
S!int.method3
struct_S_float_method1.o:
S!float.method1
struct_S_float_method2.o:
S!float.method2
struct_S_float_method3.o:
S!float.method3

Since the compiler doesn't know at instantiation time which of 
these
methods will actually be used, it simply emits all of them and 
puts them

into the static library.

Then at link-time, the compiler tells the linker to include 
libprogram.a
when linking program.o. So the linker goes through each 
undefined
reference, and resolves them by linking in the module in 
libprogram.a

that defines said reference. So it would link in the code for
S!byte.method1, S!int.method2, and S!float.method3. The other 6
instantiations are not linked into the final executable, 
because they

are never actually referenced by the runtime code.

So this way, we minimize template bloat to only the code that's 
actually
used at runtime. If a particular template function 
instantiation is only
used during CTFE, for example, it would be present in 
libprogram.a but
won't get linked, because none of the runtime code references 
it. This

would fix bug 10833.

Is this workable? Is it implementable in DMD?


T


Without link-time optimisation, this prevents inlining doesn't it?

Re: Why I chose D over Ada and Eiffel

[John Colvin]

On Monday, 19 August 2013 at 22:00:17 UTC, Walter Bright wrote:

On 8/19/2013 2:17 PM, H. S. Teoh wrote:
Time will tell, but I believe ranges may be one of the most 
significant
innovations of D. It makes writing generic algorithms 
possible, and even
pleasant, and inches us closer to the ideal of perfect code 
reuse than

ever before.


While not unique to D, I believe that ranges will become a 
killer feature - killer enough that languages that don't 
support pipeline programming will start looking like propeller 
driven airliners.


We still have a ways to go yet - Phobos support for ranges is 
not ubiquitous - but ranges are the future.


Is there an official "everything that sensibly can provide a 
range, should do" policy for phobos? If so, there's quite a bit 
of low-hanging fruit.

Re: GPGPU and D

[John Colvin]

On Sunday, 18 August 2013 at 08:40:33 UTC, Russel Winder wrote:

Luminousone, Atash, John,

Thanks for the email exchanges on this, there is a lot of good 
stuff in
there that needs to be extracted from the mail threads and 
turned into a
"manifesto" type document that can be used to drive getting a 
design and
realization together. The question is what infrastructure would 
work for
us to collaborate. Perhaps create a GitHub group and a 
repository to act

as a shared filestore?

I can certainly do that bit of admin and then try and start a 
document
summarizing the email threads so far, if that is a good way 
forward on

this.


I just downloaded cl4d and tried it: The non-derelict example 
compiles and runs, straight out of the box :)


Also, I found this fork: https://github.com/vuaru/cl4d  which 
appears to have swapped out the static bindings for the dynamic 
ones in derelict.

Re: Why I chose D over Ada and Eiffel

[John Colvin]

On Tuesday, 20 August 2013 at 00:08:31 UTC, Ramon wrote:
Needing a min(), say for strings, ints and floats in a program 
one shouldn't end up with 3 times code but with code dealing 
with e.g. "any scalar" or even "anything comparable".


No matter how you cut it, you have to pay for dealing with 
different types in one function. Either by code-bloat or 
indirection. The asm for ints, floats, reals etc. are all 
different and require different code.


See here: 
http://forum.dlang.org/post/mailman.213.1376962388.1719.digitalmar...@puremagic.com

Re: When compiling multiple source files

[John Colvin]

On Tuesday, 20 August 2013 at 06:50:12 UTC, Jacob Carlborg wrote:

On 2013-08-20 00:27, ProgrammingGhost wrote:

Is it possible that if I just try to compile 1 file it could 
imports
enough libraries that import/need the definitions for 
additional large
libraries which in turn also imports everything causing ram 
issues? I'm
sure in practice this will almost never happen. But I don't 
doubt there
are main libraries that use other large libraries and 
everything

imports/uses everything


I guess I should add that we do have some problems with RAM 
running the unit tests in Phobos (the standard library). But 
this is rather due to the heavy use of templates and other 
compile time features. Not because there is too much code/text 
in the files.


Hah, ram problems running the unittests. This old laptop 
can't even summon enough ram to compile phobos at all!

Re: A Discussion of Tuple Syntax

[John Colvin]

On Tuesday, 20 August 2013 at 03:33:51 UTC, Kenji Hara wrote:


My opinions agains various syntax proposals:

#(1, "str")
--> The character '#' is already used for the start of "Special 
Token

Sequences"
http://dlang.org/lex.html#Special Token Sequence

It is recognized in lexing phase, so adding semantic meaning to 
the '#'

character would be a contradict of D's principle.

Quote from http://dlang.org/lex.html
"The lexical analysis is independent of the syntax parsing and 
the semantic

analysis."

Kenji Hara



There are various other characters that could be substituted for #
e.g.
&(1, "string")

http://forum.dlang.org/post/cokiixatvjmngggpb...@forum.dlang.org

Re: When compiling multiple source files

[John Colvin]

On Tuesday, 20 August 2013 at 11:08:51 UTC, Jacob Carlborg wrote:

On 2013-08-20 12:45, John Colvin wrote:

Hah, ram problems running the unittests. This old laptop 
can't even

summon enough ram to compile phobos at all!


Haha, that's bad. How much RAM do you have?


Only 2GB

It can work... but I have to close everything else running first, 
otherwise it locks everything up and then crashes out complaining 
about not having enough memory to fork.

Re: When compiling multiple source files

[John Colvin]

On Tuesday, 20 August 2013 at 13:30:11 UTC, Jacob Carlborg wrote:

On 2013-08-20 13:21, John Colvin wrote:


Only 2GB

It can work... but I have to close everything else running 
first,
otherwise it locks everything up and then crashes out 
complaining about

not having enough memory to fork.


Hmm, I'm pretty sure I have compiled Phobos on my MacBook, 
which only has 2GB.


Just from looking at htop while compiling, it looks like it uses 
approx. 800MB to compile phobos. It's not unusual for me to have 
a lot less than that free at any given time.


The interesting thing is that it crashes instead of just 
swapping...

Re: Ideas for a brand new widget toolkit

[John Colvin]

On Tuesday, 20 August 2013 at 17:56:27 UTC, Adam D. Ruppe wrote:
On Tuesday, 20 August 2013 at 17:43:46 UTC, Jacob Carlborg 
wrote:

So no port for Mac OS X in sight?


I don't have a Mac, so unless someone else wants to do it 
(probably best to wait until the Windows version is more 
complete though, so you don't have to keep up with my changing 
my mind every other day), then no.


A couple years ago, someone from the ng contributed a Cocoa 
port of simpledisplay.d to me, and it is now in that file, but 
I can't actually test it myself so it is unlikely to even 
compile now with the other changes to the file.



Here's something you might be able to help with though: what 
keywords would get me search results for an acceptable but 
cheap Mac for this kind of thing? I don't even know what 
version D works best with, and don't have a lot of money to 
spend on another computer right now. But if I can get a used 
one for like a hundred bucks on ebay or something, I'll do it 
and then maintain the port myself.


Depending on where you're based and how you feel about breaking 
unenforceable EULAs, just buy an OS X install disk/usb and go 
here and DIY: http://www.tonymacx86.com/home.php

Re: Possible solution to template bloat problem?

[John Colvin]

On Tuesday, 20 August 2013 at 17:59:35 UTC, H. S. Teoh wrote:

On Tue, Aug 20, 2013 at 07:18:50PM +0200, Ramon wrote:

On Tuesday, 20 August 2013 at 17:05:21 UTC, Dicebot wrote:
>On Tuesday, 20 August 2013 at 16:59:00 UTC, Ramon wrote:
>>I'm afraid the issue is bigger.
>
>Your insight about variety of modern programming language
>applications is extremely limited. If you are willing to 
>introduce
>random runtime costs for nothing, there are lot of other 
>awesome

>languages that can satisfy your needs.
>
>As someone who does not want to write embedded'ish code in C
>anymore (and hopes to drag D there eventually) I am 
>dangerously

>close to hating you.

And that shows. Well, if that fits your definition of
"professional", so be it.

To avoid misunderstandings: I still like D and think that it's 
a
great language/solution. I still see very attractive points. I 
still
think that even templates can be attractive and are way better 
done

in D than in C++.

I just don't agree that writing "generics" in the brochure and
actually delivering templates is a good thing. And I happen to 
think

that real generics are a very good thing.

[...]

I think the problem is that your definition of "generic" is not 
the same

as ours. :)

Templates actually include your definition of generics if you 
use it

correctly. Here's an example:

interface LessThanComparable {
bool opCmp(LessThanComparable b);
}

interface LessThanComparableRange {
@property bool empty();
@property LessThanComparable front();
void popFront();
}

void sortRange(LessThanComparableRange range) {
// Note: single template instantiation of sort here
std.algorithm.sort(range);
}

class MyClass : LessThanComparable {
override bool opCmp(LessThanComparable b) { ... }
...
}

class MyClassRange : LessThanComparableRange {
override @property bool empty() { ... }
override @property LessThanComparable front() { ... }
override void popFront() { ... }
}

class MyOtherClass : LessThanComparable {
override bool opCmp(LessThanComparable b) { ... }
...
}

class MyOtherClassRange : LessThanComparableRange {
override @property bool empty() { ... }
override @property LessThanComparable front() { ... }
override void popFront() { ... }
}

void main() {
MyClassRange firstRange = ...;
MyOtherClassRange secondRange = ...;
...
sortRange(firstRange);
sortRange(secondRange);
}

A few notes:

- LessThanComparable lets you do polymorphism at runtime, so 
sortRange
  is a non-template "real generic" function that can sort any 
range

  involving LessThanComparable.

- LessThanComparableRange provides a single ABI for any range of
  LessThanComparable elements.

- sortRange instantiates the template function 
std.algorithm.sort
  exactly *once*, and it will work with any runtime type that 
implements

  LessThanComparableRange.

- The rest of the code shows how you can define a bunch of 
classes that
  implement these interfaces, and they can be used with the 
sortRange

  function with full runtime polymorphism.

You will note that there's some amount of boilerplate here -- 
because I
just typed this up off the top of my head for illustration 
purposes; in
real code you'd use mixins or other such stuff, perhaps *cough* 
use a
template for generating all the xxxRange classes *cough* 
automatically.


So this lets you have "real generics" which, as you can see, is 
really
just a subset of what is covered by the template 
std.algorithm.sort,
which can handle *any* concrete type, even those that don't 
implement

any runtime polymorphic interfaces.

Now let's talk about about how templates and "real generics" 
can work

together.

If you think about the above code carefully, you will realize 
that, at
the machine level, you cannot avoid the overhead of 
dereferencing
pointers to the various interfaces and class vtables, because 
the CPU
can only deal with concrete types, it doesn't know how to work 
with data
that can be any type. So, at *some* level, whether visible at 
the code
level or not, everything must be translated down to 
type-specific code
that the CPU can actually run. In "real generics", this is 
accomplished

by having a single ABI (the interfaces LessThanComparable and
LessThanComparableRange) that all concrete types must 
implement. Once
implemented, the sortRange function doesn't have to deal with 
concrete
types anymore: it can express the sorting algorithm directly in 
terms of
the interfaces, and when a concrete operation like '<' is 
desired, it
invokes LessThanComparable's opCmp method to accomplish it. 
(

Re: Possible solution to template bloat problem?

[John Colvin]

On Tuesday, 20 August 2013 at 22:49:40 UTC, Ramon wrote:
Happily I'm stupid and completely missed the condescending tone 
of an evident genius. Instead I'll just be grateful that it 
pleased one of the D masters to drop some statement down at me 
at all.



Awesome, thank you and keep destroying.


"destroying"??? Which part of "not to bash it" and of "D means 
a lot to me" and of "D is, no doubts, an excellent and modern 
incarnation of C/C++. As

far as I'm concerned D is *the* best C/C++ incarnation ever,
hands down." was too complicated to understand for your genius 
brain?


I knew this would happen at some point:
Andrei uses "destroy" as a positive term to denote a 
well-reasoned powerful argument/response.


Chill :)

Re: Why I chose D over Ada and Eiffel

[John Colvin]

On Tuesday, 20 August 2013 at 19:41:13 UTC, H. S. Teoh wrote:

On Tue, Aug 20, 2013 at 08:57:35PM +0200, pjmp wrote:

On Tuesday, 20 August 2013 at 14:35:19 UTC, H. S. Teoh wrote:
>On Tue, Aug 20, 2013 at 11:19:27AM +0200, Chris wrote:

[...]
>>One thing that is usually not mentioned in articles about D 
>>is that
>>you don't need an IDE to develop in D. This was, if I 
>>remember it

>>correctly, one of the design goals.
>
>Was it a design goal? If so, kudos to Walter. :) Because one 
>of my
>criteria for a better programming language when I decided 
>that I was
>fed up with C++ and needed something better, was that it must 
>not
>have undue reliance on an IDE or some other external tool to 
>be
>usable. Thus, Java was disqualified (too much boilerplate 
>that can't
>be adequately handled without an IDE -- of course, there were 
>other
>factors, but this was a big one). It must be usable with just 
>a text

>editor and a compiler. D fit that criterion rather nicely. :)
>
>
>T

Programming like the 70's, yo!  :)

[...]

LOL... to be honest, my PC "desktop" is more like a glorified 
terminal
shell than anything else, in spite of the fact that I'm running 
under
X11. My window manager is ratpoison, which is completely 
keyboard-based

(hence the name), maximizes all windows by default (no tiling /
overlapping), and has no window decorations. I don't even use 
the mouse
except when using the browser or selecting text for cut/paste. 
(And if I
had my way, I'd write a keyboard-only graphical browser that 
didn't
depend on the mouse. I'd use Elinks instead, except that 
viewing images
in a text terminal is rather a hassle, and there *is* a place 
for
graphics when you need to present non-textual information -- I 
just
don't think it's necessary when I'm dealing mostly with text 
anyway.)


I experimented with various ratpoison setups, and found that 
the most
comfortable way was to increase my terminal font size so that 
it's
approximately 80 columns wide (70's style ftw :-P), and however 
tall it
is to fill the screen. I found that I'm most productive this 
way --
thanks to Vim's split-screen features and bash's backgrounding 
features,
I find that I can do most of my work in a single terminal or 
two, and
another background window for the browser. Since I don't even 
need to
move my right hand to/from the mouse, I can get things done 
*fast*
without needing a 6GHz CPU with 16GB of RAM -- a Pentium would 
suffice
if I hadn't needed to work with CPU-intensive processes like 
povray

renders or brute-force state space search algorithms. :)

OTOH, I find that my productivity drops dramatically when I'm 
confronted
with a GUI. I honestly cannot stand working on Windows because 
of this.
*Everything* depends on the mouse and traversing endless layers 
of

nested menus just to do something simple, and almost nothing is
scriptable unless specifically designed for it (which usually 
suffers

from many limitations in how you can use it between different
applications). Give me the Unix command-line any day, thank you 
very

much.

So yes, I'm truly a relic from the 70's. ;-)


T


I think you might enjoy https://github.com/conformal/xombrero/

snapshots here: 
https://opensource.conformal.com/snapshots/xombrero/ although 
they're a month or so old and I had to edit the URL to get 
there... They clearly don't want any noobs haha


I just built from source and it works very nicely, very 
minimalist.

Re: A possible suggestion for the Foreach loop

[John Colvin]

On Wednesday, 21 August 2013 at 02:46:06 UTC, Dylan Knutson wrote:

Hello,

I'd like to open up discussion regarding allowing foreach loops 
which iterate over a tuple of types to exist outside of 
function bodies.


I would *LOVE* to have this.

however, once we go down that route, it would be very tempting to 
allow a whole lot of other compile-time imperative style 
programming. Which would be awesome.


I don't know how the compiler works with templates, but if it 
could be made to move linearly through them then we could 
potentially do this:


template allSatisfy(alias F, T...)
{
foreach(t; T)
{
static if(!F!t)
{
static return false;
//alternatively:
//  enum allSatify = False;
//  static return;
}
}
static return true;
}

which could be extended to allow static break, static continue 
etc. This does rather make the argument for allowing "static 
foreach" as valid, but not required syntax.


Or... even allow enum and alias values to be manipulated at CT:

template staticMap(alias F, T...)
{
static if(T.length == 0)
{
alias staticMap = TypeTuple!();
static return;
}
alias map = F!(T[0]);
foreach(t; T)
{
map = TypeTuple!(map, F!t);
}
alias staticMap = map;
static return;
}

I'm favouring the 2-step eponymous thing in order to prevent any 
alias/enum ambiguities. Another alternative would be

static return alias blah;
static return enum blah;


Apologies for the bike-shedding, but if some thing like this 
worked properly, it would be a complete game-changer.
We'd be light-years ahead of anyone else’s compile-time 
reflection.

Re: GPGPU and D

[John Colvin]

On Sunday, 18 August 2013 at 08:40:33 UTC, Russel Winder wrote:

Luminousone, Atash, John,

Thanks for the email exchanges on this, there is a lot of good 
stuff in
there that needs to be extracted from the mail threads and 
turned into a
"manifesto" type document that can be used to drive getting a 
design and
realization together. The question is what infrastructure would 
work for
us to collaborate. Perhaps create a GitHub group and a 
repository to act

as a shared filestore?

I can certainly do that bit of admin and then try and start a 
document
summarizing the email threads so far, if that is a good way 
forward on

this.


Just a small update:
I'm working my way through the source of cl4d, cleaning up some 
things, reformatting to phobos style, taking advantage of some 
improvements in dmd etc.


https://github.com/John-Colvin/cl4d

Re: Why I chose D over Ada and Eiffel

[John Colvin]

On Thursday, 22 August 2013 at 02:06:13 UTC, Tyler Jameson Little 
wrote:

- array operations (int[] a; int[]b; auto c = a * b;)
  - I don't think these are automagically SIMD'd, but there's 
always hope =D


That isn't allowed. The memory for c must be pre-allocated, and 
the expression then becomes c[] = a[] * b[];


Is it SIMD'd?

It depends. There is a whole load of hand-written assembler for 
simple-ish expressions on builtin types, on x86. x86_64 is only 
supported with 32bit integer types because I haven't finished 
writing the rest yet...


However, I'm not inclined to do so at the moment as we need a 
complete overhaul of that system anyway as it's currently a 
monster*.  It needs to be re-implemented as a template 
instantiated by the compiler, using core.simd. Unfortunately it's 
not a priority for anyone right now AFAIK.



*
hand-written asm loops. If fully fleshed out there would be:
  ((aligned + unaligned + legacy mmx) * (x86 + x64) + fallback 
loop)

  * number of supported expressions * number of different types
of them. Then there's unrolling considerations. See 
druntime/src/rt/arrayInt.d

Re: s/type tuple/template pack/g please

[John Colvin]

On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:
On 2013-08-22 11:55:55 +, "Tommi" 
 said:



On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:

I think it should be called either a "compile-time list" ...


And if we go with "compile-time list", then we can follow the 
example of std.regex.ctRegex and name the thing "ctList".


Will .tupleof become .ctlistof?


strictly speaking I think it would be an alias list, so perhaps 
.aliasList

Re: Range interface for std.serialization

[John Colvin]

On Thursday, 22 August 2013 at 14:48:57 UTC, Dicebot wrote:
Outputting on its own is not useful to discuss - in pipe model 
output matches input. What is the point in outputting partial 
chunks of serialized object if you still need to provide it as 
a whole to the input?


Partial chunks of serialized objects can be useful for 
applications that aren't immediately deserializing: E.g. sending 
over a network, storing to disk etc.