Re: new DIP47: Outlining member functions of aggregates

[Jacob Carlborg]

On 2013-09-09 05:46, Manu wrote:

Missed the action...

Well it's clear this is not a popular proposal.
And even to me personally, it's certainly not of critical importance. If
there was a single thing I'd like to see *DONE* in D, it would be
temporary/r-value->ref args, without question (really, really annoying
to work around).


So what's wrong with this approach, that's already working today:

class Foo
{
void foo ();

void foo ()
{

}
}

void main ()
{
auto foo = new Foo;
foo.foo();
}

BTW, this feature was implemented because you asked for it.

--
/Jacob Carlborg

Re: new DIP47: Outlining member functions of aggregates

[Jacob Carlborg]

On 2013-09-07 19:00, Walter Bright wrote:

Outlining of member functions is the practice of placing the declaration
of a member function in the struct/class/union, and placing the
definition of it at global scope in the module or even in another module.

http://wiki.dlang.org/DIP47


What's wrong with the code below, that works today:

class Foo
{
void foo ();

void foo ()
{
writeln("Foo.foo");
}
}

void main ()
{
auto foo = new Foo;
foo.foo();
}

--
/Jacob Carlborg

Re: new DIP48: Interface specifications for aggregate types

[Jacob Carlborg]

On 2013-09-08 20:13, Simen Kjaeraas wrote:

In response to Walter's DIP47 I have created my own take on what I see
as the main problem:

http://wiki.dlang.org/DIP48


As I wrote in the DIP47 thread:

What's wrong with this currently working code:

class Foo
{
void foo ();

void foo ()
{
writeln("Foo.foo");
}
}

void main ()
{
auto foo = new Foo;
foo.foo();
}

--
/Jacob Carlborg

Re: Move VisualD to github/d-programming-language ?

[Manu]

On 9 September 2013 15:05, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:

> On 9/8/13 9:32 PM, Manu wrote:
>
>> On 8 September 2013 05:04, Walter Bright > >
>> wrote:
>>
>> Recent threads here have made it pretty clear that VisualD is a
>> critical piece of D infrastructure. (VisualD integrated D usage into
>> Microsoft Visual Studio.)
>>
>> Andrei, myself and Rainer (VisualD's champion) are all in agreement
>> on this.
>>
>> What do you think?
>>
>>
>> How about the bugs?
>> When I made the suggestion, other the obvious endorsement for the
>> project, I imagined the most significant outcome would be making
>> Visual-D's bug's first-class bugs as well.
>> Giving good visibility of IDE bugs to all contributors gives the whole
>> community a good sense of the health of this aspect of the ecosystem,
>> even of they don't contribute to the IDE integration themselves...
>>
>
> I think we should use the D mainline bug flow for VisualD, effectively
> vaulting VisualD into a first-class component of the D language.
>
> This opens the door to other projects as well - e.g. emacs and vim
> integration helpers.


Perfect! I'm super happy you agree with me for once! :)

Re: Move VisualD to github/d-programming-language ?

[Jacob Carlborg]

On 2013-09-07 21:04, Walter Bright wrote:

Recent threads here have made it pretty clear that VisualD is a critical
piece of D infrastructure. (VisualD integrated D usage into Microsoft
Visual Studio.)

Andrei, myself and Rainer (VisualD's champion) are all in agreement on
this.

What do you think?


I don't think it matters that much which git repository it uses. It's 
more important, as others have suggested, to promote it, put it on 
dlang.org/downloads, integrate with bugzilla and so on.


Note, I'm not against it.

--
/Jacob Carlborg

Re: Move VisualD to github/d-programming-language ?

[Jacob Carlborg]

On 2013-09-08 23:47, Nick Sabalausky wrote:


Let's stick to grown-up words here. I'm not a fan of MS or Win either,
but every time you write "Windoze" or spell something with $ it does
nothing to hurt MS/Win and only makes you and other Posix users look
like immature brats.


Why do you put him together with the rest of us Posix users, seems a bit 
unfair.


--
/Jacob Carlborg

Re: Move VisualD to github/d-programming-language ?

[Ramon]

On Monday, 9 September 2013 at 07:21:17 UTC, Jacob Carlborg wrote:

On 2013-09-08 23:47, Nick Sabalausky wrote:

Let's stick to grown-up words here. I'm not a fan of MS or Win 
either,
but every time you write "Windoze" or spell something with $ 
it does
nothing to hurt MS/Win and only makes you and other Posix 
users look

like immature brats.


Why do you put him together with the rest of us Posix users, 
seems a bit unfair.


Don't worry, I'm pretty certain he meant only immature-brats like 
myself and not cultivated grown up persons like you.


(Note to myself: In order to get grown-up I should learn to 
insult those whose linguistic habits differ from mine)


Have a beautiful day, everyone :-)

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Russel Winder]

On Sun, 2013-09-08 at 22:05 -0700, Andrei Alexandrescu wrote:
[…]
> This opens the door to other projects as well - e.g. emacs and vim 
> integration helpers.

The Emacs mode stuff for D really needs to be in its own Git repository
I believe.  MELPA automatically pulls the current repository to create
the Emacs packages for people to install via the Emacs packaging system.

Also the more stuff is in the main repository the less and less
distributed the development of the various bits can be as only the
gatekeepers can commit to the mainline.

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


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

Re: Move VisualD to github/d-programming-language ?

[Russel Winder]

On Sun, 2013-09-08 at 20:48 +0200, Joseph Rushton Wakeling wrote:
[…]
> One thing that could help with MonoD would be if it could effectively support 
> more than the most recent stable version of MonoDevelop.  Version 3.0 is 
> still 
> the one used in many Linux distros.  (4.0 is currently in the "proposed" 
> updates 
> for Ubuntu 13.10, which means it'll probably be the default by the time 13.10 
> is 
> released.)

Debian Unstable has Monodevelop 4.0.5, which means it should be in
Ubuntu 14.04 by default. 

> If VisualD can support VS 2010, 2011 and 2013, it's surely possible for MonoD 
> to 
> do something similar.
> 
> I recognize that the developer has provided an Ubuntu PPA for the latest 
> MonoDevelop among other resources, but it's preferable not to oblige users to 
> add extra archives to their distro.

This is an important issue for take up. If something isn't in the main
repository of the distribution and requires lots of other things also
not in the main distribution then it may get take up from "bleeding
edge" folk but it will not get mainstream take up. The Ubuntu PPA is
useful for the Ubuntu distributions but of no use to Debian, Mint,
Fedora, RHEL, Arch, OS X. (Windows is just beyond the pale ;-)

Getting things into the main Debian, Fedora and Arch repositories seems
like the best way of maximizing take up in the Linux community. Getting
things into MacPorts and HomeBrew (the former for me), maximizes take up
in the OS X community, even if DMG files are provided. 

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


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

Re: Move VisualD to github/d-programming-language ?

[Vladimir Panteleev]

On Sunday, 8 September 2013 at 18:49:05 UTC, Joseph Rushton 
Wakeling wrote:
One thing that could help with MonoD would be if it could 
effectively support more than the most recent stable version of 
MonoDevelop.  Version 3.0 is still the one used in many Linux 
distros.  (4.0 is currently in the "proposed" updates for 
Ubuntu 13.10, which means it'll probably be the default by the 
time 13.10 is released.)


If VisualD can support VS 2010, 2011 and 2013, it's surely 
possible for MonoD to do something similar.


I recognize that the developer has provided an Ubuntu PPA for 
the latest MonoDevelop among other resources, but it's 
preferable not to oblige users to add extra archives to their 
distro.


Judging by the MonoD blog, that doesn't seem to be easy, because 
the MonoDevelop developers keep changing the API often.

Re: new DIP47: Outlining member functions of aggregates

[deadalnix]

On Monday, 9 September 2013 at 07:00:23 UTC, Jacob Carlborg wrote:

On 2013-09-09 05:46, Manu wrote:

Missed the action...

Well it's clear this is not a popular proposal.
And even to me personally, it's certainly not of critical 
importance. If
there was a single thing I'd like to see *DONE* in D, it would 
be
temporary/r-value->ref args, without question (really, really 
annoying

to work around).


So what's wrong with this approach, that's already working 
today:


class Foo
{
void foo ();

void foo ()
{

}
}

void main ()
{
auto foo = new Foo;
foo.foo();
}

BTW, this feature was implemented because you asked for it.


This is super useful to generate boilerplate from compile time 
reflection !

Re: Move VisualD to github/d-programming-language ?

[Russel Winder]

On Sun, 2013-09-08 at 23:00 +0200, Ramon wrote:
> Just for the sake of completeness:
> 
> mono is *detested* and considered even more inacceptable than 
> java by many linux and (even more) *BSD users.

It also appears that Microsoft are beginning to think the whole CLR
thing is on it's last legs.

The whole "all non-Windows users have to hate C#" thing has some basis
in fact but also had a lot of FUD associated with it.  The "Mono hatred"
stemmed from that. So will Microsoft go after Mono with patent suits if
they are not themselves using C# and CLR? They possibly might as an
income stream, but it is unlikely to be profitable and so may be not.

Without solid support from Microsoft the C#F#/CLR culture is unlikely to
remain strong, despite the serious success F# has had in making people
interested in CLR. And C# is not a bad language, in many ways much
better than Java. But Java has staying power in ways C#/F# do not.

> Actually I *did* try the eclipse D IDE thing ... and found it to 
> match my (utterly negative) perception of java (which has pretty 
> nothing to do with the D ide and pretty everything with eclipse). 
> Concerning Mono-D I heard about it and respect the efforts of the 
> creator(s) ... but never even looked at it (and never will until 
> hell freezes).

Eclipse is a monster, but once you get used to it, it can be good. I do
not use CDT, but I do use Eclipse sometimes for Java, Groovy, Scala and
Python. Eclipse has users because it is "corporate", and free.
Organizations , especially Java related ones, have basically made
Eclipse the core tool. However IntelliJ IDEA has a much more vocal
following mostly because it works better than Eclipse for them, and they
have to pay for it. I use IntelliJ IDEA sometimes for Java, Groovy and
Scala, and PyCharm sometimes for Python. (The IDE editors are still
nowhere near as good as Emacs (and VIM), but IDEs are great for
debugging. So I use Emacs most of the time for editing and the IDE in
the rare occasions I actually have to debug.)

Interesting to note that Android has switched from Eclipse to IntelliJ
IDEA as the base for the Android development platform.

I gave Mono-D a whirl, but as I don't do any C# or F#, it has brought in
a huge amount of dependencies. My problem is I do not understand how the
"Solution" system is the same or different to everyone else's "Project"
system. I guess I do not have much enthusiasm to find out as I can just
use Emacs.

> I vaguely remember seeing colleagues work with Visual$$ on 
> Windoze and they looked happy and productive to me.
> For a reason: Visual$$ seems to serve quite nicely the needs and 
> expectations of those developing on Windoze.

If Windows and (C or C++ or C# or F# or Python) then VisualStudio.
If Windows and Java then (Eclipse of IntelliJ IDEA)

So if D is to compete with C++ on Windows, a D plugin for Visual Studio
has to be in place and enjoyably usable.

> For fairness sake:
> It's next to impossible to do the same (as Visual$$) on linux/BSD 
> due to complexity and a fractured eco system. Gnome and QT/kde 
> basically are religious issues and no matter which one one 
> chooses one will have a large audience refusing it. Besides both 
> are monstrous (and more often than not meet resistance or at the 
> very minimum reluctance on the Windoze side). Fox and fltk are 
> nice little thingies but not up to (todays) par lacking even 
> functionality like printing. And so on.

GNOME vs. Qt may be religious to certain parties, but most people choose
either GNOME or KDE for the desktop and then load the other widget set
as well. I use GNOME but I have a many Qt-based things on here and
indeed develop PySide and PyQt5 based systems since GNOME is a
non-starter on Windows and OS X. Pragmatism is the order of the day here
not religious fervour. 

For Go I use the Eclipse Go perspective, but more usually LiteIDE which
is a Qt-based system that works fine on GNOME – and OS X and Windows.
wxWidgets used to be interesting but wxPython is not shifting to Python
3 so it is effectively dead. Phoenix is trying to create a Python 3
binding for wxWidgets but it is not finished yet. If it makes it then
wxWidgets re-enters my use sphere.

I think that now that Qt has escaped from
Microsoft^H^H^H^H^H^H^H^H^HNokia, it will return to being one of the two
primary system for cross-platform GUI systems, wxWidgets being the
other. Thus I think QtD (fot Qt4 and Qt5) should be seen as an essential
component of the D milieu.  wxD should also get some presence. It is
great we have GtkD, but I cannot see it ever having any cross-platform
traction.

> That's quite regrettable, considering that we have a quite nice 
> editor engine (Scintilla), quite good a debugger, and quite good 
> compilers for pretty every language around.
> 
> That said, maybe my first reaction was too harsh. After all, it's 
> not D's job to solve the linux gui troubles.
> Having GDC with GDB working and some editors and even IDEs more 
> or less working

Re: Move VisualD to github/d-programming-language ?

[Russel Winder]

On Mon, 2013-09-09 at 01:03 +0100, Iain Buclaw wrote:
[…]
> 
> Both the C# specification (
> http://www.ecma-international.org/publications/standards/Ecma-334.htm ) and
> the common language infrastructure (CLI)  (
> http://www.ecma-international.org/publications/standards/Ecma-335.htm )
> have been standardised for some time now, so that aspect is safe from
> Microsoft.   It is worth noting that not all C# modules are covered by CLI
> - such as the cryptography library.

Just because there are standards doesn't mean patent issues have gone
away.  Most mobile phone technology is standardized but there are some
patents that have to be licenced, supposedly on "frand" terms, but,…
(cf. Apple vs. Motorola for a classic case of how to "game the system".)

Clearly though mobile phone technology involves hardware and hardware
implemented software things so the patents tend to be real. In the
software world patents are a nightmare, well in the USA anyway. Most
countries such as UK (but not the EU, so you can get software patents in
the UK :-( do not grant software patents. So the threats Microsoft have
over C# and Mono are arguably not as real as the mobile phone ones,
except in the USA.

Of course in the USA you are not allowed to use doubly-linked lists
without paying royalties. http://www.google.co.uk/patents/US7028023
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


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

Re: new DIP48: Interface specifications for aggregate types

[Simen Kjaeraas]

On Mon, 09 Sep 2013 09:13:55 +0200, Jacob Carlborg  wrote:


On 2013-09-08 20:13, Simen Kjaeraas wrote:

In response to Walter's DIP47 I have created my own take on what I see
as the main problem:

http://wiki.dlang.org/DIP48


As I wrote in the DIP47 thread:

What's wrong with this currently working code:

class Foo
{
 void foo ();

 void foo ()
 {
 writeln("Foo.foo");
 }
}

void main ()
{
 auto foo = new Foo;
 foo.foo();
}



The fact that I can easily write this:

class Foo {
// Declarations:
void foo();

// Definitions:
void foo() {
writeln("Foo.foo");
}

void bar(int n) {
writeln("Foo.bar(",n,")");
}
}

And the compiler will keep completely quiet about bar not being
mentioned in the declarations section.

--
Simen

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Andrei Alexandrescu]

On 9/9/13 12:51 AM, Russel Winder wrote:

On Sun, 2013-09-08 at 22:05 -0700, Andrei Alexandrescu wrote:
[…]

This opens the door to other projects as well - e.g. emacs and vim
integration helpers.


The Emacs mode stuff for D really needs to be in its own Git repository
I believe.  MELPA automatically pulls the current repository to create
the Emacs packages for people to install via the Emacs packaging system.

Also the more stuff is in the main repository the less and less
distributed the development of the various bits can be as only the
gatekeepers can commit to the mainline.


I see no problem with making it a repo under the D-programming-language org.

Andrei

Re: Move VisualD to github/d-programming-language ?

[Ramon]

On Monday, 9 September 2013 at 08:29:44 UTC, Russel Winder wrote:

...
If Windows and (C or C++ or C# or F# or Python) then 
VisualStudio.

If Windows and Java then (Eclipse of IntelliJ IDEA)



I understand the point about Visual$. While I myself hardly know 
it, very many (quite possibly the majority) of programmers on 
Windoze use it and seem to be quite happy with it. That's reason 
enough for me to accept it.


This, however, is (to me) the really interesting point

So if D is to compete with C++ on Windows, a D plugin for 
Visual Studio

has to be in place and enjoyably usable.


Is it? Why compete? The only way to attracts large numbers of C++ 
developers is to become more and more like C++ (incl. of course, 
massive amounts of libraries and tools) and to end up as some 
kind of C+++.


Python is similar to - nothing (commonly used) - and yet it grew 
wildly. There are so many to complain about Python's weird 
indentation syntax. And yet they come and use it. Because it 
promises something tangible and it delivers. Because there is 
"the Python way". Because there excellent docs. And because there 
is no real competitor.
Had van Rossum tried to please the perl crowd, he might have 
attracted some more and quicker but today Python would be a small 
niche thingy nobody'd care much about.


I feel we should largely ignore C++. I feel that D is grossly 
inconsequent in a) - very smartly - aiming to be what C++ wanted 
to be and b) - not at all smartly - trying to please the C++ 
crowd and to mimick C++ up to the point of at least seriously 
considering mimicking leper and plague of C++, too.


D already *is* what C++ wanted to be, namely a more modern C with 
OO. D shouldn't measure itself against C++ but rather against 
what C++ wanted to be.


And there is another immensely important factor: reliability and 
safety.


This world gets ever more dependent on software - and software is 
ever more recognized as unreliable and insecure; hell, there is 
even an industry living from that (anti virus, anti-malware, etc, 
etc).


THAT's the sweet spot. To be what C++ wanted to be - plus - a 
strong focus on reliability and safety.


The Ada people are not stupid. There is a good reason for them to 
ponder a year or longer over a new keyword. Bertrand Meyer may 
have it implemented in a way that looks strange to many but that 
man isn't stupid at all. The lesson to learn from those two 
languages known for reliability? Have a tight definition and 
think long and hard before you make the slightest changes. And 
*always* keep your "guiding principles" in mind.



A+ -R

Re: Move VisualD to github/d-programming-language ?

[Joseph Rushton Wakeling]

On 09/09/13 09:58, Russel Winder wrote:

Debian Unstable has Monodevelop 4.0.5, which means it should be in
Ubuntu 14.04 by default.


I'm reasonably sure it'll be in Ubuntu 13.10 by default too.  I'll probably try 
it out then.



This is an important issue for take up. If something isn't in the main
repository of the distribution and requires lots of other things also
not in the main distribution then it may get take up from "bleeding
edge" folk but it will not get mainstream take up. The Ubuntu PPA is
useful for the Ubuntu distributions but of no use to Debian, Mint,
Fedora, RHEL, Arch, OS X. (Windows is just beyond the pale ;-)

Getting things into the main Debian, Fedora and Arch repositories seems
like the best way of maximizing take up in the Linux community. Getting
things into MacPorts and HomeBrew (the former for me), maximizes take up
in the OS X community, even if DMG files are provided.


I'd add Ubuntu also to that list, simply because of the number of users -- it's 
helpful to ensure that every 6 months, such a widely-used distro has the latest 
D tools.

Re: Move VisualD to github/d-programming-language ?

[Joseph Rushton Wakeling]

On 09/09/13 09:31, Ramon wrote:

(Note to myself: In order to get grown-up I should learn to insult those whose
linguistic habits differ from mine)


No, but it may help to learn to distinguish between someone saying "You're 
making yourself look like an immature brat," and someone saying you _are_ one.

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Russel Winder]

On Mon, 2013-09-09 at 01:43 -0700, Andrei Alexandrescu wrote:
[…]
> I see no problem with making it a repo under the D-programming-language org.

As long as 1 of the 21 members of the organization will take on the
responsibility for it then fine, go with it. Then we can delete the
Emacs-D-Mode-Maintainers group.

We'll need to update the MELPA entry so the pulls come from the new
repository.

We'll also have to amend Launchpad stuff as well. 

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


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

Re: Move VisualD to github/d-programming-language ?

[Ramon]

On Monday, 9 September 2013 at 09:13:16 UTC, Joseph Rushton 
Wakeling wrote:

On 09/09/13 09:31, Ramon wrote:
(Note to myself: In order to get grown-up I should learn to 
insult those whose

linguistic habits differ from mine)


No, but it may help to learn to distinguish between someone 
saying "You're making yourself look like an immature brat," and 
someone saying you _are_ one.


Well, to me someone who talks in a negative way about another 
user (or "smartly" works out subtle differences in such remarks) 
rather than about D related issues looks like an idiot.


Isn't it beautiful to experience variety of perception?

I sincerely hope it's not too immature brat looking to suggest 
that we focus on D related issues again.


Thank you so much -R

Re: Move VisualD to github/d-programming-language ?

[Regan Heath]

On Sat, 07 Sep 2013 23:35:47 +0100, Paulo Pinto   
wrote:


Am 07.09.2013 23:57, schrieb Ramon:> On Saturday, 7 September 2013 at  
20:02:37 UTC, Paulo Pinto wrote:

 >> Am 07.09.2013 21:55, schrieb Peter Alexander:
 >>> On Saturday, 7 September 2013 at 19:39:21 UTC, Russel Winder wrote:
  Sadly, Visual Studio is a huge player in the game. Make the
  connection :-)
 >>>
 >>> Why sadly? It's a fantastic product.
 >>
 >> The only thing I don't like is the reliance on Visual Assist and
 >> ReSharper for refactoring features that other IDEs offer out of the  
box.

 >>
 >> --
 >> Paulo
 >
 > I'm both pro and against it.
 >
 > Pro because VisualD seems to be (Pardon me, I don't work on Windoze  
and

 > didn't work with it but trust Windoze D users opinion on that) an
 > excellent solution and supporting nicely what seems to be *the* IDE in
 > Windoze world.
 >
 > Against because we need a solution for *all* major platforms (Lx32,
 > Lx64, *BSD, apple, w32,w64) and I'm worried that this resolution here
 > might lead to a "So, we *do* have an IDE. Case closed" attitude.
 >
 > Kudos anyway to Rainer though for his important work.
 >
 > A+ -R

Well, if you want a production quality multi-platform IDE the only  
options are InteliJ and Eclipse, both of which are not that well  
received by most C and C++ guys. The target audience for D.


Eclipse is dreadful.  I hate it with a passion.


That is my humble opinion, regarding the type of tooling I expect from
an IDE.


My solution: Do all development on windows, commit, update on build  
machine, rinse and repeat ...  that said, I haven't had to do fully cross  
platform work for at least 7 years.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: new DIP47: Outlining member functions of aggregates

[sclytrack]

On Saturday, 7 September 2013 at 17:00:08 UTC, Walter Bright 
wrote:
Outlining of member functions is the practice of placing the 
declaration of a member function in the struct/class/union, and 
placing the definition of it at global scope in the module or 
even in another module.


http://wiki.dlang.org/DIP47


---



unit Unit1;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, 
Dialogs, StdCtrls;


type

  { TForm1 }

  TForm1 = class(TForm)
Button1: TButton;
Memo1: TMemo;
procedure Button1Click(Sender: TObject);
  private
{ private declarations }
  public
{ public declarations }
procedure ChangeTitle(x:string);
procedure ChangeOtherTitle(x: string);
  end;

var
  Form1: TForm1;

implementation

{$R *.lfm}

{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
begin
  ChangeTitle('test');
end;

procedure TForm1.ChangeTitle(x: string);
begin
   Memo1.Lines.Add(x);
end;

procedure TForm1.ChangeOtherTitle(x: string);
begin
   Memo1.Lines.Add(x);
end;

end.




Here is how it looks like in Lazarus.
In the class definition you type the declaration.

  public
{ public declarations }
procedure ChangeTitle(x:string);

Then you press "control shift c" this will create the empty 
implementation.
Use "control shift up" to cycle between the interface section and 
the implementation section.



There are two keywords "interface" and "implementation" to 
separate the two sections.


Honestly. There is not much typing going on.

If you go want to go the the next procedure in the implementation 
section it is faster to go "control shift up" back to the 
interface section. And then go to the next method and go back 
"control shift up" to the implentation section than to press the 
arrow down button until you are at the next method.



Lazarus does not accept changes in the name of the parameter.

Re: Move VisualD to github/d-programming-language ?

[Joseph Rushton Wakeling]

On 09/09/13 10:29, Russel Winder wrote:

It also appears that Microsoft are beginning to think the whole CLR
thing is on it's last legs.

The whole "all non-Windows users have to hate C#" thing has some basis
in fact but also had a lot of FUD associated with it.  The "Mono hatred"
stemmed from that. So will Microsoft go after Mono with patent suits if
they are not themselves using C# and CLR? They possibly might as an
income stream, but it is unlikely to be profitable and so may be not.


I think the Mono hatred/fear stemmed from a particular time in Linux history 
which involved a combination of Novell's role as a major driver of Mono in 
GNOME, Microsoft's very aggressive patent posturing (although no actual 
lawsuits), and the close relationship between Novell and Microsoft that 
culminated in their patent agreement.


I don't think Microsoft would ever bother suing over Mono patents just for money 
-- the concern was always that Novell's pushing of Mono was a Trojan Horse that 
would enable Microsoft to take down the wider Linux community and Novell to 
clean up on the business Linux side.



Without solid support from Microsoft the C#F#/CLR culture is unlikely to
remain strong, despite the serious success F# has had in making people
interested in CLR. And C# is not a bad language, in many ways much
better than Java. But Java has staying power in ways C#/F# do not.


First-mover advantage, cross-platform for longer, less patent fear ...


I gave Mono-D a whirl, but as I don't do any C# or F#, it has brought in
a huge amount of dependencies. My problem is I do not understand how the
"Solution" system is the same or different to everyone else's "Project"
system. I guess I do not have much enthusiasm to find out as I can just
use Emacs.


Yes, the number of dependencies is very, very annoying if you don't want to work 
with C#/F#.



GNOME vs. Qt may be religious to certain parties, but most people choose
either GNOME or KDE for the desktop and then load the other widget set
as well. I use GNOME but I have a many Qt-based things on here and
indeed develop PySide and PyQt5 based systems since GNOME is a
non-starter on Windows and OS X. Pragmatism is the order of the day here
not religious fervour.


Yes, GNOME vs. KDE is the issue, not GTK vs Qt.  Installing a specifically GNOME 
or KDE app will pull in a ton of dependencies from the other desktop, installing 
a purely Qt- or GTK-based app is much less heavy (it's almost unavoidable I'd 
say to have both Qt- and GTK-based code on your system).


I found this out recently when trying to install kcachegrind, which wanted to 
pull in a ton of stuff from the KDE desktop that really didn't seem necessary. 
It does apparently include a "qcachegrind" package that's purely Qt-based, but 
it's not packaged separately for Debian or Ubuntu :-(



I think that now that Qt has escaped from
Microsoft^H^H^H^H^H^H^H^H^HNokia, it will return to being one of the two
primary system for cross-platform GUI systems, wxWidgets being the
other. Thus I think QtD (fot Qt4 and Qt5) should be seen as an essential
component of the D milieu.  wxD should also get some presence. It is
great we have GtkD, but I cannot see it ever having any cross-platform
traction.


I think that move is already happening and has been for some time -- in fact I 
think the resurgence of Qt has been happening ever since it was LGPL'd.  My 
impression is that GTK/GNOME won out historically because the Qt GPL/commercial 
dual licence meant that there were licensing compatibility issues even for free 
software, and that there was a single commercial gatekeeper for proprietary 
software.  That was an undesirable situation to have for the core graphical 
toolkit of an operating system, so GTK was preferred.


I completely agree that QtD should be a priority project -- I think Qt's 
importance is only going to grow.


Perhaps this is a nice point to re-iterate my earlier plea for consideration of 
Qt Creator as a potential cross-platform D IDE? :-)

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Joseph Rushton Wakeling]

On 09/09/13 09:51, Russel Winder wrote:

The Emacs mode stuff for D really needs to be in its own Git repository
I believe.  MELPA automatically pulls the current repository to create
the Emacs packages for people to install via the Emacs packaging system.


If it's Emacs stuff, shouldn't it be versioned in bzr? :-)


Also the more stuff is in the main repository the less and less
distributed the development of the various bits can be as only the
gatekeepers can commit to the mainline.


I don't see that necessarily needs to be so.  Different projects should be able 
to have different gatekeepers/maintainers.  If that's problematic, if GitHub 
won't support separate maintainer groups for different repositories of 
D-Programming-Language, there are probably other ways round it -- e.g. the 
maintainers could have a separate project branch, and the D-Programming-Language 
repo could auto-pull from it (and never be pushed to directly).


Also, so long as everyone is trustworthy and limits their activity to their 
sphere of responsibility, there's no reason why you shouldn't just have a large 
maintainer group.  If you can't trust maintainer-of-project-X to only use admin 
powers for project X, and not for project Y as well, then why is he/she 
maintainer of project X in the first place?

Re: Move VisualD to github/d-programming-language ?

[Iain Buclaw]

On 9 September 2013 10:31, Joseph Rushton Wakeling
 wrote:
>
> I completely agree that QtD should be a priority project -- I think Qt's
> importance is only going to grow.
>
> Perhaps this is a nice point to re-iterate my earlier plea for consideration
> of Qt Creator as a potential cross-platform D IDE? :-)

Shouldn't be difficult.  ;-)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Move VisualD to github/d-programming-language ?

[Joseph Rushton Wakeling]

On 09/09/13 11:29, Ramon wrote:

Well, to me someone who talks in a negative way about another user (or "smartly"
works out subtle differences in such remarks) rather than about D related issues
looks like an idiot.

Isn't it beautiful to experience variety of perception?


There's nothing idiotic about asking people to behave civilly and not use 
sarcastic nicknames for other software products, even when one has good reason 
to disapprove of them.  A variety of perception is good, expressing yourself in 
a way that makes people more likely to ignore or dismiss your perception isn't.


Besides, the D community ought to be a friendly environment for developers from 
any platform.  Tolerance for sneering nicknames can be offputting for people 
from the platforms being sneered at -- and if they're less likely to join the 
community as a result, the variety of perception will be decreased.



I sincerely hope it's not too immature brat looking to suggest that we focus on
D related issues again.


Making the D community a pleasant place for everyone _is_ a D-related issue.

In my experience it's a very typical problem of technical people in general (I 
don't excuse myself here) that they focus predominantly on technical issues at 
the expense of understanding how their ways of expressing themselves are 
perceived by other people.  The result is very often a lot of unnecessary 
conflict and failure of communication, and a lot of interpersonal grievances 
that are completely avoidable.


This conversation is a good example.  You seem to think that everyone is 
accusing you of being immature.  Actually, this whole thread of conversation is 
an appeal to your maturity -- to your capacity to understand why people are 
concerned about these things, and to adapt accordingly.

Re: Move VisualD to github/d-programming-language ?

[develop32]

On Monday, 9 September 2013 at 09:29:11 UTC, Ramon wrote:
Well, to me someone who talks in a negative way about another 
user (or "smartly" works out subtle differences in such 
remarks) rather than about D related issues looks like an idiot.


You do understand that by saying Windoze you *are* insulting 
users that use that platform?


On a related note, I am using VisualD for more than a year and 
I'm happy that it will get a bigger support.

Re: LLVM progress

[Chris]

Not to mention the importance of ARM support.

Re: new DIP47: Outlining member functions of aggregates

[Volcz]

On Sunday, 8 September 2013 at 04:47:04 UTC, Jonathan M Davis 
wrote:

On Saturday, September 07, 2013 10:00:05 Walter Bright wrote:
Outlining of member functions is the practice of placing the 
declaration of
a member function in the struct/class/union, and placing the 
definition of

it at global scope in the module or even in another module.

http://wiki.dlang.org/DIP47


I confess that I really don't like this idea. I think that the 
separation of
declarations and definitions is a serious downside of C++ and 
that it
negatively impacts code maintenence. And from the recent 
discussion on this,

it's clear that quite a few people agree with me.

However, at the same time, there are some folks (like Manu) who 
really prefer
to separate the declaration and definitions so that they can 
just see the
signatures for an entire class' functions at once without 
seeing any
definitions. Personally, I don't think that that's a big deal 
and that it's far
better to just use generated documentation for that, but 
clearly there's not a

consensus on that.



- Jonathan M Davis


I completely agree with Jonathan!
This will only produce more code which will lead to more bugs and 
more maintenance.

Re: Move VisualD to github/d-programming-language ?

[Nick Sabalausky]

On Mon, 09 Sep 2013 09:21:16 +0200
Jacob Carlborg  wrote:

> On 2013-09-08 23:47, Nick Sabalausky wrote:
> 
> > Let's stick to grown-up words here. I'm not a fan of MS or Win
> > either, but every time you write "Windoze" or spell something with
> > $ it does nothing to hurt MS/Win and only makes you and other Posix
> > users look like immature brats.
> 
> Why do you put him together with the rest of us Posix users, seems a
> bit unfair.
> 

Huh? What are you talking about? I'm not grouping anyone with anything.
When non-Windows users go saying things like "Windoze" or "M$" or
anything like that, it makes non-Windows users look bad. Makes it a lot
easier for people to be dismissive of OSS (or anything non-MS) when
we've trained them to associate it with immaturity like that.

Re: Move VisualD to github/d-programming-language ?

[Nick Sabalausky]

On Sun, 08 Sep 2013 23:42:52 +0200
"Ramon"  wrote:
> 
> tl;dr One is grossly mistaken when seeing myself as linux-taliban 
> like anti-MS.
> 

That's fine but you seem to go out of your way to convince people of
the exact opposite. Naturally, that *will* mislead people.

Problems importing core.sys.linux.epoll

[Mike Parker]

I'm experimenting with some Linux stuff right now and am currently 
working on something using epoll. But I've run into an issue where dmd 
just doesn't see anything in core.sys.linux.epoll. As a workaround, I've 
implemented my own declarations for the bits I'm using. I'm curious, 
though, if anyone else has encountered this as I've never seen anything 
like it. I get no errors at all about it not being able to find the 
module, just things like "epoll_event is undefined" and such. If I try 
something like this:


import core.sys.linux.epoll : epoll_event;

Then I get an error about the import not being found. Other modules in 
core.sys.linux import just fine.


If anyone else can verify this same issue, I'll file a bug report. 
Otherwise, any ideas on what could cause this?

Re: Move VisualD to github/d-programming-language ?

[Ramon]

Sorry, Joseph Rushton Wakeling

but this is getting silly.

You see, I try to be polite and to value anyones work. I will 
gladly value your (or Nicks, or ...) views on programming, no 
matter whether I agree with them, I respect your work and will 
gladly take your advise on D related matters.


But not you nor anyone else here will educate me on manners or 
alike. You will not force your private feelings on how one should 
speak upon me. Period.


You or Nick or Carl or whoever finds it insulting when I say 
Windoze because I write it in a way you don't like? Sorry, that's 
ridiculous. Similarly I write Visual$ - the $ meaning "fill in as 
appropriate" - rather than VisualStudio, VisualExpress, 
VisualBasic, VisualNet, VisualWhoKnowsWhat? Ridiculous!


Should I now make some noise, too and complain about imaginary 
insults because you evidently assume that eveyone must know the 
correct product name of some Visual$ even when he doesn't use 
Windoze?


This is getting silly. Let us stop that construed out of thin air 
"problem" ping pong and *really* behave like grown ups that is, 
return to technical issues.



A+ -R

Re: Move VisualD to github/d-programming-language ?

[Andrej Mitrovic]

On 9/9/13, Ramon  wrote:
> Windoze because I write it in a way you don't like? Sorry, that's
> ridiculous. Similarly I write Visual$ - the $ meaning "fill in as
> appropriate" - rather than VisualStudio, VisualExpress,
> VisualBasic, VisualNet, VisualWhoKnowsWhat? Ridiculous!

Drop the act.

Re: new DIP48: Interface specifications for aggregate types

[PauloPinto]

On Monday, 9 September 2013 at 01:04:16 UTC, H. S. Teoh wrote:

On Sun, Sep 08, 2013 at 08:13:33PM +0200, Simen Kjaeraas wrote:
In response to Walter's DIP47 I have created my own take on 
what I

see as the main problem:

http://wiki.dlang.org/DIP48

[...]

I don't see this as a fundamentally better or different 
solution than

DIP47, which I already vote against.

I believe the correct solution to this issue is auto-generation 
of

interface from implementation.  We should simply fix dmd's .di
generation so that it is usable as a class-at-a-glance 
interface file.

No language change is necessary.


T


This is the best way.

Re: new DIP47: Outlining member functions of aggregates

[Dicebot]

On Monday, 9 September 2013 at 00:43:39 UTC, H. S. Teoh wrote:
Therefore, the *real* solution to this problem is to fix the 
compiler's
.di output to give a proper overview of the class 
*automatically*, and

nicely pretty-printed.


Yes, that should be superior approach in general though exact 
usability is very detail-specific - currently relation between 
.di and .d and not really well-defined and pulling this off will 
requires its own DIP at the very least.


For example, it is not entirely clear to me, what should happen 
if there are both .di and .d files in the file system at the same 
time and they have minor difference (remember, it is perfectly 
legal to tweak .di manually). It is likely, that improving .di 
tool chain will require similar signature matching verification 
anyway. Also I am wondering how to differ purely auto-generated 
.di files (should be updated completely upon build) and ones with 
manual changes (should be only verified).


It is all about small details.

Re: new DIP47: Outlining member functions of aggregates

[Manu]

On 9 September 2013 18:08, deadalnix  wrote:

> On Monday, 9 September 2013 at 07:00:23 UTC, Jacob Carlborg wrote:
>
>> On 2013-09-09 05:46, Manu wrote:
>>
>>> Missed the action...
>>>
>>> Well it's clear this is not a popular proposal.
>>> And even to me personally, it's certainly not of critical importance. If
>>> there was a single thing I'd like to see *DONE* in D, it would be
>>> temporary/r-value->ref args, without question (really, really annoying
>>> to work around).
>>>
>>
>> So what's wrong with this approach, that's already working today:
>>
>> class Foo
>> {
>> void foo ();
>>
>> void foo ()
>> {
>>
>> }
>> }
>>
>> void main ()
>> {
>> auto foo = new Foo;
>> foo.foo();
>> }
>>
>> BTW, this feature was implemented because you asked for it.
>>
>
> This is super useful to generate boilerplate from compile time reflection !
>

Which is what I requested it for, and use it very extensively.

Re: LLVM progress

[Manu]

On 7 September 2013 23:20, Flamaros  wrote:

> I read an interesting news about LLVM :
> http://www.phoronix.com/scan.**php?page=news_item&px=MTQ1NjI
>
> It's certainly a great things for ldc too.
>
> Is there a hope to see ldc as the main D compiler if it's full featured
> under Windows?
>

This sounds like good news. I'm very interested to hear more news from LLDB.
It will be a marvelous day when LDC 'just works' on Windows. No worrying
about object/library formats, exception handling, runtime libraries, or
debuginfo compatibility.

Re: new DIP47: Outlining member functions of aggregates

[Joseph Rushton Wakeling]

On Monday, 9 September 2013 at 04:18:29 UTC, deadalnix wrote:
For that second, it has been discussed in the thread to improve 
the di behavior to fit that role. Do think this is a viable 
approach, and that your team of happy devs would have benefited 
from that ?


Correct me if I'm wrong, but isn't the problem of using 
manually-written .di files to separate out class declaration and 
definition, that you consequently also have to manually include 
all the declarations of all the other module content?

On inlining in D libraries

[Dmitry Olshansky]

While investigating std.regex performance in Phobos I've found that a 
lot of stuff never gets inlined (contrary to my expectations).


Namely the 3 critical ones were declared like this:
struct Bytecode{
uint raw;
//bit twiddling helpers
@property uint data() const { return raw & 0x003f_; }

//ditto
@property uint sequence() const { return 2 + (raw >> 22 & 0x3); }

//ditto
@property IR code() const { return cast(IR)(raw>>24); }
...
}

And my quick hack to get them inlined - 0-arg templates:
https://github.com/D-Programming-Language/phobos/pull/1553

The "stuff" in question turns out to be anything that is not a template 
and (consequently) is compiled into library. At first I thought it's a 
horrible bug somewhere in DMD's inliner,  but this behavior is the same 
regardless of compiler. (It could be a bug of the front-end in general)


Few days after filing the bug report with minimal test case:
http://d.puremagic.com/issues/show_bug.cgi?id=10985

I'm  not so sure if that's not an issue of separate compilation to begin 
with. I *thought* that the intended behavior is

a) Have source - compile from source
b) Don't have source (*.di files) - link in objects

But I don't have much to go on this. Somebody from compiler team could 
probably shed some light on this. If I'm wrong then 0-arg templates is 
actually the only way out to get 'explicitly inline' of C++.


In C++ that would look like this:
//header
struct A{
int foo();
}
//source
int A::foo(){ ... }

C++ explicitly inlined:
//header
struct A{
int foo(){ ... }
}

In D we don't have this distinction.
It has to be decided then if we adopt 0-arg as intended solution, or 
tweak front-end to always peruse accessible source when inlining.


Anyhow as it stands you have one of the following:
a) Do nothing. Then using e.g. isAlpha from std.ascii (or pick your 
favorite one-liner) is useless as it would never outperform a 
hand-rolled version (that could be 1:1 the same) because the latter will 
be inlined.
b) Pass all of the interesting files from Phobos on the command line to 
get them fully scanned for inlining (and get compiled anew each time I 
guess).
c) For code under your control - add an empty pair of brackets to 
anything that has to be inlined.


None of the above options is nice.

--
Dmitry Olshansky

Re: On inlining in D libraries

[Adam D. Ruppe]

On Monday, 9 September 2013 at 13:01:51 UTC, Dmitry Olshansky 
wrote:
b) Pass all of the interesting files from Phobos on the command 
line to get them fully scanned for inlining (and get compiled 
anew each time I guess).


They more or less get compiled anew anyway since there's so many 
templates it has to run through, as well as the web of 
dependencies meaning it reads those files thanks to imports too.


Listing the files could be made easy with the dmd -r people have 
talked about (taking what rdmd does and putting it in the 
compiler). Then it does it automatically.


I doubt you'll see much impact on compile speed. Importing a 
phobos module is dog slow already, so it can't get much worse in 
any case.

Re: new DIP47: Outlining member functions of aggregates

[Daniel Murphy]

"Jacob Carlborg"  wrote in message 
news:l0jrm7$3199$1...@digitalmars.com...
> On 2013-09-09 05:46, Manu wrote:
>> Missed the action...
>>
>> Well it's clear this is not a popular proposal.
>> And even to me personally, it's certainly not of critical importance. If
>> there was a single thing I'd like to see *DONE* in D, it would be
>> temporary/r-value->ref args, without question (really, really annoying
>> to work around).
>
> So what's wrong with this approach, that's already working today:
>
> class Foo
> {
> void foo ();
>
> void foo ()
> {
>
> }
> }
>
> void main ()
> {
> auto foo = new Foo;
> foo.foo();
> }
>
> BTW, this feature was implemented because you asked for it.
>
> -- 
> /Jacob Carlborg

Whoa, I didn't think of applying that to member functions.  This seems like 
the answer.  Put your variables and function prototypes at the top of your 
class.  Done. 

Re: On inlining in D libraries

[Andrej Mitrovic]

On 9/9/13, Adam D. Ruppe  wrote:
> Listing the files could be made easy with the dmd -r people have
> talked about (taking what rdmd does and putting it in the
> compiler). Then it does it automatically.
>
> I doubt you'll see much impact on compile speed. Importing a
> phobos module is dog slow already, so it can't get much worse in
> any case.

W.r.t -r (recursive build), it's gives you a performance boost since
the compiler doesn't have to be invoked multiple times and do the same
work over and over again (compared to using it from RDMD).

But I've ran into a bug with that pull request, and I haven't reduced
the test-case of the failure yet.

Re: Move VisualD to github/d-programming-language ?

[PauloPinto]

On Monday, 9 September 2013 at 10:15:13 UTC, develop32 wrote:

On Monday, 9 September 2013 at 09:29:11 UTC, Ramon wrote:
Well, to me someone who talks in a negative way about another 
user (or "smartly" works out subtle differences in such 
remarks) rather than about D related issues looks like an 
idiot.


You do understand that by saying Windoze you *are* insulting 
users that use that platform?


On a related note, I am using VisualD for more than a year and 
I'm happy that it will get a bigger support.


Maybe he should discuss D issues on Slashdot...

Re: new DIP47: Outlining member functions of aggregates

[PauloPinto]

On Monday, 9 September 2013 at 12:28:54 UTC, Dicebot wrote:

On Monday, 9 September 2013 at 00:43:39 UTC, H. S. Teoh wrote:
Therefore, the *real* solution to this problem is to fix the 
compiler's
.di output to give a proper overview of the class 
*automatically*, and

nicely pretty-printed.


Yes, that should be superior approach in general though exact 
usability is very detail-specific - currently relation between 
.di and .d and not really well-defined and pulling this off 
will requires its own DIP at the very least.


For example, it is not entirely clear to me, what should happen 
if there are both .di and .d files in the file system at the 
same time and they have minor difference (remember, it is 
perfectly legal to tweak .di manually). It is likely, that 
improving .di tool chain will require similar signature 
matching verification anyway. Also I am wondering how to differ 
purely auto-generated .di files (should be updated completely 
upon build) and ones with manual changes (should be only 
verified).


It is all about small details.


In languages like Modula-2, it is a compile error if there are 
differences.


So I would say D compilers should follow the same behavior, 
unless it is requested to generate .di files automatically, which 
will then overwrite the corresponding .di files.

Re: Move VisualD to github/d-programming-language ?

[Dicebot]

Just in case someone has not understood it already: Ramon is 
using a pretty common trolling approach which can be shortly 
described as "make an insult, interpret any answer as a personal 
insult, appeal to cultural differences, loop". He has been doing 
it since the very first posts here and people are still taking it 
seriously.


Unless someone starts banning people for not being constructive 
(hope it will never happen), only thing that can be done is 
simply ignoring it and focusing on topic. At the very least it 
will help to keep threads less bloated, at most - force him find 
more amusing trolling methods.


Trying to reason with him is exactly what he needs to be able to 
provoke you more.


Peace.

Re: new DIP47: Outlining member functions of aggregates

[Joseph Rushton Wakeling]

On 09/09/13 15:12, Daniel Murphy wrote:

"Jacob Carlborg"  wrote in message
news:l0jrm7$3199$1...@digitalmars.com...


So what's wrong with this approach, that's already working today:

class Foo
{
 void foo ();

 void foo ()
 {

 }
}

void main ()
{
 auto foo = new Foo;
 foo.foo();
}

BTW, this feature was implemented because you asked for it.

--
/Jacob Carlborg


Whoa, I didn't think of applying that to member functions.  This seems like
the answer.  Put your variables and function prototypes at the top of your
class.  Done.


Problem -- what about:

class Foo
{
// Declarations
void foo();
int bar(double n);

// Definitions
void foo() {  }
int bar(double n) { }

// Whoops!  Forgot to include this one in the
// declarations list, but it's still accepted
// as part of the class
void goo() { ... }
}

A well-defined rule for separating out declarations and definitions would check 
for that and throw a compile error.

Re: Move VisualD to github/d-programming-language ?

[Walter Bright]

On 9/8/2013 10:05 PM, Andrei Alexandrescu wrote:

I think we should use the D mainline bug flow for VisualD, effectively vaulting
VisualD into a first-class component of the D language.

This opens the door to other projects as well - e.g. emacs and vim integration
helpers.


VisualD is now a component on Bugzilla, so Manu can start reporting bugs there!

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Walter Bright]

On 9/9/2013 2:13 AM, Russel Winder wrote:

On Mon, 2013-09-09 at 01:43 -0700, Andrei Alexandrescu wrote:
[…]

I see no problem with making it a repo under the D-programming-language org.


If someone can point me to how to make it so, I'll take care of it.



As long as 1 of the 21 members of the organization will take on the
responsibility for it then fine, go with it. Then we can delete the
Emacs-D-Mode-Maintainers group.


Even better, I can create a TeamEmacs group that will have pull power for the 
Emacs repository, and they can be the people who have it for the previous group.

Re: Move VisualD to github/d-programming-language ?

[Iain Buclaw]

On 9 September 2013 14:49, Dicebot  wrote:
> Just in case someone has not understood it already: Ramon is using a pretty
> common trolling approach which can be shortly described as "make an insult,
> interpret any answer as a personal insult, appeal to cultural differences,
> loop". He has been doing it since the very first posts here and people are
> still taking it seriously.
>
> Unless someone starts banning people for not being constructive (hope it
> will never happen), only thing that can be done is simply ignoring it and
> focusing on topic. At the very least it will help to keep threads less
> bloated, at most - force him find more amusing trolling methods.
>
> Trying to reason with him is exactly what he needs to be able to provoke you
> more.
>
> Peace.

Being direct isn't helpful either, as it just causes more flames and
provocation.  I think it is generally well agreed here that attacks
and derogatory terms of any kind are not welcome, but this does not
require any form of moderation other than a gentle reminder.

With respect, if you wish your posts to be taken seriously and your
posts to have a more "adult" air to them, then using tired and
somewhat immature terms such as "Visual$, Windoze" etc is not going to
achieve that.  You do not need to use an insulting tone to promote D,
and using such terms only makes you look bad.

Of course, some of us (myself being included as pretty big FSF
advocate) like the GNU/Linux way of doing things better, but as they
say, there's more than one way to cook a goose. Do we really need to
treat people disrespectfully?


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Move VisualD to github/d-programming-language ?

[Ramon]

Wow. So many people turning so many circles around so little as 
"ze" instead of "ws".


What's your objective in all this? To make me nicely say 
"Windows" as desired by you? A storm in the tea pot for 2 letters?


If that is "grown up" I'd prefer to be an "immature brat".

Is it enough, now? Can we finally return to technical issues? Or 
are some more "grown up" circles needed?


(Note: This is not in response to dicebot specifially)

@dicebot

I'm generous enough to not feel insulted by your repeated "troll" 
accusations. Sure enough this is just another symbol of being 
grown up ;)

Re: new DIP47: Outlining member functions of aggregates

[Joseph Rushton Wakeling]

On 09/09/13 05:46, Manu wrote:

For the record, I tend to agree with the arguments of many in the 'against' camp
*from a purist point of view*, but the problem remains, and the reason I raised
it; this has demonstrated to me and my colleagues on a number of occasions that
it is a consistent productivity hindrance.


For what it's worth, I think this kind of baptism-by-fire practical experience 
is very valuable, and that it's worth considering carefully even if the final 
decision is not to implement the requested feature.


Question: do you have any access to information about similar short-deadline 
programming activity using other languages (Java, C# ...) that also forbid the 
separation of declaration and definition, and how devs using those languages 
cope with that?  It might offer an alternative solution that no one here has 
thought of.



I support this DIP, obviously, but I'd suggest perhaps a conservative
restriction that definitions should only be allowed to appear within the same
module as the declaration. This would seem to simplify things like mangling
issues and access rights. In my own use case, I have no reason to spread
definitions across files. I just want to see class outlines clearly summarised
at the top of the file. This saves time, and time is money.


I think the conservative approach is probably correct -- the class outline and 
the function definitions should have to be in the same module, and the outline 
and definitions should match precisely.  Any mismatch (including in variable 
names)?  Compile error.  A function in the outline that isn't implemented? 
Compile error.  A function implemented that isn't in the outline?  Compile 
error.  That should greatly reduce the possibility of error caused by code 
duplication.


Then it simply becomes a question of deciding if the manual labour of writing 
separate outlines and definitions is worth it.  I guess this is probably 
somewhere where a tool really _can_ be useful, to ensure that the definitions 
and the outline stay in sync.


Writing D code in this way should probably be disapproved of in the D style 
guidelines, but with the proviso that it's there for the circumstances where it 
really is useful.

Re: Move VisualD to github/d-programming-language ?

[Joseph Rushton Wakeling]

On 09/09/13 16:06, Ramon wrote:

Wow. So many people turning so many circles around so little as "ze" instead of
"ws".


Why is a little "ze" as opposed to a "ws" so important to you that you choose to 
persist in using it even though lots of people have suggested to you that it's 
impolite?

review queue: next?

[Dicebot]

While Jacob is working on improving std.serialization, there is 
some time to do more reviews. Review manager role does not seem 
to be very stressing, so I can step up as one for any of the 
projects currently in queue as soon as their authors express the 
desire to do so.


Personally, I'd love to move forward with std.d.lexer - Brian, 
what is your opinion on this?

Re: On inlining in D libraries

[Joseph Rushton Wakeling]

On 09/09/13 15:01, Dmitry Olshansky wrote:

While investigating std.regex performance in Phobos I've found that a lot of
stuff never gets inlined (contrary to my expectations).


Is that just with dmd, or with gdc and ldc as well?

Re: new DIP47: Outlining member functions of aggregates

[Dicebot]

On Monday, 9 September 2013 at 14:22:15 UTC, Joseph Rushton 
Wakeling wrote:
Then it simply becomes a question of deciding if the manual 
labour of writing separate outlines and definitions is worth 
it.  I guess this is probably somewhere where a tool really 
_can_ be useful, to ensure that the definitions and the outline 
stay in sync.


Writing D code in this way should probably be disapproved of in 
the D style guidelines, but with the proviso that it's there 
for the circumstances where it really is useful.


Very well spoken, this is exactly how I see it.

Re: new DIP47: Outlining member functions of aggregates

[Jacob Carlborg]

On 2013-09-09 14:36, Manu wrote:


Which is what I requested it for, and use it very extensively.


Doesn't this already solve what this DIP47 is trying to solve?

--
/Jacob Carlborg

Re: On inlining in D libraries

[Dmitry Olshansky]

09-Sep-2013 18:26, Joseph Rushton Wakeling пишет:

On 09/09/13 15:01, Dmitry Olshansky wrote:

While investigating std.regex performance in Phobos I've found that a
lot of
stuff never gets inlined (contrary to my expectations).


Is that just with dmd, or with gdc and ldc as well?


For DMD and LDC confirmed. Would be interesting to test GDC but I bet 
it's the same (does LTO work here btw?).


On the bright side of things std.regex is real fast on LDC *when hacked* 
to inline the critical bits :)


--
Dmitry Olshansky

Re: On inlining in D libraries

[Dmitry Olshansky]

09-Sep-2013 17:05, Adam D. Ruppe пишет:

On Monday, 9 September 2013 at 13:01:51 UTC, Dmitry Olshansky wrote:

b) Pass all of the interesting files from Phobos on the command line
to get them fully scanned for inlining (and get compiled anew each
time I guess).


They more or less get compiled anew anyway since there's so many
templates it has to run through, as well as the web of dependencies
meaning it reads those files thanks to imports too.


This was my intuition, but currently it won't go beyond templates 
code-gen wise. It however seems to analyze the whole code.




Listing the files could be made easy with the dmd -r people have talked
about (taking what rdmd does and putting it in the compiler). Then it
does it automatically.


It would still be a hack.. while I'm looking for a fix (or a 
clarification that we need a hack).


If it was my personal problem I'd "solve" it with:
dmd ~/dmd2/phobos/std/*.d 

maybe even alias it like this. Hm this way I could even inline some of 
druntime...




I doubt you'll see much impact on compile speed.


Agreed.


Importing a phobos
module is dog slow already, so it can't get much worse in any case.


And that could be improved.. once it starts going into finer-grained 
imports/packages. The general felling is that it'd be *soon*.



--
Dmitry Olshansky

Re: new DIP47: Outlining member functions of aggregates

[H. S. Teoh]

On Mon, Sep 09, 2013 at 03:26:23PM +0200, PauloPinto wrote:
> On Monday, 9 September 2013 at 12:28:54 UTC, Dicebot wrote:
> >On Monday, 9 September 2013 at 00:43:39 UTC, H. S. Teoh wrote:
> >>Therefore, the *real* solution to this problem is to fix the
> >>compiler's .di output to give a proper overview of the class
> >>*automatically*, and nicely pretty-printed.
> >
> >Yes, that should be superior approach in general though exact
> >usability is very detail-specific - currently relation between .di
> >and .d and not really well-defined and pulling this off will
> >requires its own DIP at the very least.
> >
> >For example, it is not entirely clear to me, what should happen if
> >there are both .di and .d files in the file system at the same
> >time and they have minor difference (remember, it is perfectly
> >legal to tweak .di manually).

I'd propose to make it such that you *don't* have to tweak the .di
manually. Maybe the use of UDAs could help get rid of the need to edit
.di by hand, by instructing the compiler what kind of output is desired.

Anything that requires hand-tweaking is unreliable and prone to errors
and careless bugs. The best way is to have .di completely automated.


> > It is likely, that improving .di
> >tool chain will require similar signature matching verification
> >anyway. Also I am wondering how to differ purely auto-generated .di
> >files (should be updated completely upon build) and ones with
> >manual changes (should be only verified).
> >
> >It is all about small details.
> 
> In languages like Modula-2, it is a compile error if there are
> differences.
> 
> So I would say D compilers should follow the same behavior, unless
> it is requested to generate .di files automatically, which will then
> overwrite the corresponding .di files.

I think it is a bug for the .di and .d to have mismatches. For example,
I don't see how the following code could be correct:

---module.di---
int func(int x) pure;

---module.d---
int global;
int func(int x) { return global; }

Any such mismatch should be considered a bug.

In fact, the current lax enforcement of matching makes it possible for
something to be declared pure @safe nothrow in .di, but impure @system
throwing in .d. I think there has been a few bugs like this in druntime
that got fixed.


T

-- 
Microsoft is to operating systems & security ... what McDonalds is to gourmet 
cooking.

Re: On inlining in D libraries

[Joseph Rushton Wakeling]

On 09/09/13 16:34, Dmitry Olshansky wrote:

On the bright side of things std.regex is real fast on LDC *when hacked* to
inline the critical bits :)


Do you mean when manually inlined, or when the design is tweaked to facilitate 
inlining?


My experience is that LDC is starting to pull ahead in the speed stakes these 
days [*], although it does seem to depend a bit on exactly what kind of code 
you're writing.


[* Caveat: that might be due to me switching to an LLVM 3.3 backend, although I 
was starting to observe this even when I was still working with 3.2.]

Re: review queue: next?

[Jacob Carlborg]

On 2013-09-09 16:21, Dicebot wrote:


Personally, I'd love to move forward with std.d.lexer - Brian, what is
your opinion on this?


I would love to see that as well.

--
/Jacob Carlborg

The definitive guide to Trolls (was Move VisualD to github).

[Iain Buclaw]

Rather off topic but amusing source of information just to 
lighten up the attitude of some.  I'm sure everyone here probably 
relates vaguely to at least one of the characters - which one are 
you? :o)


http://www.flamewarriorsguide.com/


Regards
Iain.


On Monday, 9 September 2013 at 14:02:42 UTC, Iain Buclaw wrote:


Being direct isn't helpful either, as it just causes more 
flames and
provocation.  I think it is generally well agreed here that 
attacks
and derogatory terms of any kind are not welcome, but this does 
not

require any form of moderation other than a gentle reminder.

With respect, if you wish your posts to be taken seriously and 
your

posts to have a more "adult" air to them, then using tired and
somewhat immature terms such as "Visual$, Windoze" etc is not 
going to
achieve that.  You do not need to use an insulting tone to 
promote D,

and using such terms only makes you look bad.

Of course, some of us (myself being included as pretty big FSF
advocate) like the GNU/Linux way of doing things better, but as 
they
say, there's more than one way to cook a goose. Do we really 
need to

treat people disrespectfully?


Regards

Re: review queue: next?

[H. S. Teoh]

On Mon, Sep 09, 2013 at 04:21:16PM +0200, Dicebot wrote:
> While Jacob is working on improving std.serialization, there is some
> time to do more reviews. Review manager role does not seem to be
> very stressing, so I can step up as one for any of the projects
> currently in queue as soon as their authors express the desire to do
> so.
> 
> Personally, I'd love to move forward with std.d.lexer - Brian, what
> is your opinion on this?

+1. I've been itching to get a high-quality D lexer in my hands.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??

Re: new DIP47: Outlining member functions of aggregates

[Joseph Rushton Wakeling]

On 09/09/13 16:34, Jacob Carlborg wrote:

Doesn't this already solve what this DIP47 is trying to solve?


See the objection given in my reply to Daniel Murphy.

Re: Move VisualD to github/d-programming-language ?

[Manu]

On 9 September 2013 23:53, Walter Bright  wrote:

> On 9/8/2013 10:05 PM, Andrei Alexandrescu wrote:
>
>> I think we should use the D mainline bug flow for VisualD, effectively
>> vaulting
>> VisualD into a first-class component of the D language.
>>
>> This opens the door to other projects as well - e.g. emacs and vim
>> integration
>> helpers.
>>
>
> VisualD is now a component on Bugzilla, so Manu can start reporting bugs
> there!
>

Another thought... what do you reckon about including Visual-D as an
optional component in the windows DMD installer?
One-click install that includes an environment for windows users would
probably kick-start a lot of users.
It can also simplify the Visual-D installation, which expects you to have
pre-installed DMD, and prompts for the path to the exe. Since this is known
during the DMD installer, it removes a few steps from the install process.

Re: Move VisualD to github/d-programming-language ?

[Manu]

On 9 September 2013 23:53, Walter Bright  wrote:

> On 9/8/2013 10:05 PM, Andrei Alexandrescu wrote:
>
>> I think we should use the D mainline bug flow for VisualD, effectively
>> vaulting
>> VisualD into a first-class component of the D language.
>>
>> This opens the door to other projects as well - e.g. emacs and vim
>> integration
>> helpers.
>>
>
> VisualD is now a component on Bugzilla, so Manu can start reporting bugs
> there!
>

Did you migrate the existing bug list?
It's already fairly extensive... let's get those out of the way first ;)

Re: On inlining in D libraries

[Dmitry Olshansky]

09-Sep-2013 18:39, Joseph Rushton Wakeling пишет:

On 09/09/13 16:34, Dmitry Olshansky wrote:

On the bright side of things std.regex is real fast on LDC *when
hacked* to
inline the critical bits :)


Do you mean when manually inlined, or when the design is tweaked to
facilitate inlining?


When I put extra () to indicate that said functions are templates.
Then compiler gets its grip on them and finally inlines.
Otherwise it generates calls and links in object code from libphobos.

Which is the whole reason for the topic - is THAT is the way to go?
Shouldn't compiler look into source for inlinable stuff (when source is 
available)?




My experience is that LDC is starting to pull ahead in the speed stakes
these days [*], although it does seem to depend a bit on exactly what
kind of code you're writing.

[* Caveat: that might be due to me switching to an LLVM 3.3 backend,
although I was starting to observe this even when I was still working
with 3.2.]


I'm using LLVM 3.3 and fresh git clone of LDC.

--
Dmitry Olshansky

Re: review queue: next?

[Dicebot]

On Monday, 9 September 2013 at 14:52:46 UTC, H. S. Teoh wrote:

On Mon, Sep 09, 2013 at 04:21:16PM +0200, Dicebot wrote:
While Jacob is working on improving std.serialization, there 
is some
time to do more reviews. Review manager role does not seem to 
be

very stressing, so I can step up as one for any of the projects
currently in queue as soon as their authors express the desire 
to do

so.

Personally, I'd love to move forward with std.d.lexer - Brian, 
what

is your opinion on this?


+1. I've been itching to get a high-quality D lexer in my hands.


T


..and I'd love it to be nicely field tested by the time DDMD is 
done so that latter can possibly be ported to use standard lexer 
:P

Re: Move VisualD to github/d-programming-language ?

[Walter Bright]

On 9/9/2013 7:55 AM, Manu wrote:

Another thought... what do you reckon about including Visual-D as an optional
component in the windows DMD installer?
One-click install that includes an environment for windows users would probably
kick-start a lot of users.
It can also simplify the Visual-D installation, which expects you to have
pre-installed DMD, and prompts for the path to the exe. Since this is known
during the DMD installer, it removes a few steps from the install process.


Yes, we can start working towards that.

Re: Move VisualD to github/d-programming-language ?

[Walter Bright]

On 9/9/2013 7:47 AM, Manu wrote:

Did you migrate the existing bug list?


No. I just added the component.

Re: new DIP47: Outlining member functions of aggregates

[Paulo Pinto]

Am 09.09.2013 02:03, schrieb Andrei Alexandrescu:

On 9/8/13 5:33 AM, Andrej Mitrovic wrote:

On 9/8/13, Michel Fortin  wrote:

So I'd like to suggest this: allow a .d file to "import" its
corresponding
.di file.


This is actually what Andrei proposed as well.


I have to say I was a lot more in favor of the proposal before this thread.

The problem as I see it has two facets:

1. Code duplication

2. Modularity and logistics

Regarding (1), we currently force duplication of the entire class
layout. My understanding is that this is the way it's done:

// file acme.di

class A {
   int x;
   double y;
   void fun();
}

// file acme.d
// cannot import acme.di
class A {
   int x;
   double y;
   void fun() { ... }
}

The fact that acme.d cannot import acme.di is an unforced error of
embarrassing proportions and consequence. That should be fixed yesterday
no matter how we proceed otherwise.

The problem with acme.d not having access to acme.di is that any error
in duplicating the layout of A (e.g. swapping x and y or adding some
other members etc) will have undefined behavior, and there is no
reasonable way for the compiler to check against that.

Assuming that bug is fixed, the problem of duplication remains - all
state of the class must be duplicated.

(I also suspect constructors might need to be white-boxed (i.e.
available in the .di) for raw/cooked typechecking, but I'm not sure.)

If we go with DIP47, the duplication of state goes away. However we have
a distinct problem - modularity, which segues into (2).

Allowing out-of-module implementations of individual methods poses
additional modularity problems. Consider:

// file acme.di

class A {
   int x;
   double y;
   void fun();
}
private int a;
private void gun();

// file acme.d
// assume we solve the import problem
import acme;
void A.fun() { gun(); a = 42; }

If A.fun() were defined inside acme.di, it would have access to gun()
and a. Defining it outside asks the question - do we allow such access,
or not?

Intuitively the body of a method should not be all too sensitive to
where it's placed, so that argues in favor of visibility.

D's module system has always favored a file-granular approach, e.g.
private stuff is module-private. This notion of spilling private access
outside the file into methods defined in various other files works
against that nice tenet.

So it looks there's no obvious and obviously good solution. Probably the
first one is more sensible.


Andrei



The approach should be like in Modula-2 family, only public stuff is 
allowed in .di files.


--
Paulo

Re: LLVM progress

[Flamaros]

On Monday, 9 September 2013 at 10:29:56 UTC, Chris wrote:

Not to mention the importance of ARM support.


It's an evidence that is a major target today. :-)

I work only on ARM compatible application for my day job, that 
why DQuick is tough to be easy to port those devices.

Re: new DIP47: Outlining member functions of aggregates

[Paulo Pinto]

Am 09.09.2013 16:36, schrieb H. S. Teoh:

On Mon, Sep 09, 2013 at 03:26:23PM +0200, PauloPinto wrote:

On Monday, 9 September 2013 at 12:28:54 UTC, Dicebot wrote:

On Monday, 9 September 2013 at 00:43:39 UTC, H. S. Teoh wrote:

Therefore, the *real* solution to this problem is to fix the
compiler's .di output to give a proper overview of the class
*automatically*, and nicely pretty-printed.


Yes, that should be superior approach in general though exact
usability is very detail-specific - currently relation between .di
and .d and not really well-defined and pulling this off will
requires its own DIP at the very least.

For example, it is not entirely clear to me, what should happen if
there are both .di and .d files in the file system at the same
time and they have minor difference (remember, it is perfectly
legal to tweak .di manually).


I'd propose to make it such that you *don't* have to tweak the .di
manually. Maybe the use of UDAs could help get rid of the need to edit
.di by hand, by instructing the compiler what kind of output is desired.

Anything that requires hand-tweaking is unreliable and prone to errors
and careless bugs. The best way is to have .di completely automated.



It is likely, that improving .di
tool chain will require similar signature matching verification
anyway. Also I am wondering how to differ purely auto-generated .di
files (should be updated completely upon build) and ones with
manual changes (should be only verified).

It is all about small details.


In languages like Modula-2, it is a compile error if there are
differences.

So I would say D compilers should follow the same behavior, unless
it is requested to generate .di files automatically, which will then
overwrite the corresponding .di files.


I think it is a bug for the .di and .d to have mismatches. For example,
I don't see how the following code could be correct:

---module.di---
int func(int x) pure;

---module.d---
int global;
int func(int x) { return global; }

Any such mismatch should be considered a bug.

In fact, the current lax enforcement of matching makes it possible for
something to be declared pure @safe nothrow in .di, but impure @system
throwing in .d. I think there has been a few bugs like this in druntime
that got fixed.


T




I should have read your earlier post better.

The better approach would then be like the compilers of the Oberon 
language family do, by generating the interface file when compiling the 
packages.


--
Paulo

Re: Move VisualD to github/d-programming-language ?

[Brian Rogoff]

On Sunday, 8 September 2013 at 11:48:06 UTC, Paulo Pinto wrote:

Am 08.09.2013 13:24, schrieb Russel Winder:

On Sun, 2013-09-08 at 00:35 +0200, Paulo Pinto wrote:
[…]

And why is the target audience for D only C and C++ people? 
Surely the

target audience for D is any programmer wanting a native code
executable.



Because many of us are actually aware of compilers that produce 
native code for our languages, even if they are not the default 
way to use them.


If you're used to using an IDE, let's say IntelliJ for Java, and 
you may also want to develop in D, why shouldn't you be able to 
use that IDE, and not context switch? There may be more of a 
market for Java/Python/whatever programmers interested in D than 
you think.


To make it more clear, the ML family of languages, Pascal 
family of
languages, even JVM and .NET environments have native compilers 
available. You just have to look for them.


IMO, D has more potential as a native code compilation target 
than Java, C#, and ML, at least in theory, because I should be 
able to control and even disable garbage collection. So, even 
users of managed languages may want to examine D.


-- Brian

Re: new DIP47: Outlining member functions of aggregates

[Ettienne Gilbert]

On Monday, 9 September 2013 at 13:51:20 UTC, Joseph Rushton 
Wakeling wrote:

On 09/09/13 15:12, Daniel Murphy wrote:

[snip]

/


Whoa, I didn't think of applying that to member functions.  
This seems like
the answer.  Put your variables and function prototypes at the 
top of your

class.  Done.


Problem -- what about:

class Foo
{
// Declarations
void foo();
int bar(double n);

// Definitions
void foo() {  }
int bar(double n) { }

// Whoops!  Forgot to include this one in the
// declarations list, but it's still accepted
// as part of the class
void goo() { ... }
}

A well-defined rule for separating out declarations and 
definitions would check for that and throw a compile error.


I would argue that it is actually better this way (that not all 
functions need to be in the declarations list) - its way more 
flexible! This way you can leave out function declarations that 
you are not really interested to see from a "functional overview 
perspective" of the class.


AFAIC the cost of implementing this would be way too high for any 
potential benefit gained from this. And, since Walter already 
stated that this would "no way be mandatory", the implications 
are that the compiler would need to enforce it once any one 
function is declared in the declarations list, but... not enforce 
it if no functions are declared in the list!


Also, leaving it flexible as it is now cannot silently break 
anything. Worse that can happen is that you may inadvertently try 
to implement goo() twice (since you may think the missing 
declaration imply there is no definition), but then the compiler 
will anyway complain about the duplicate definition.


So I agree with Jacob Carlborg - I would also like to know why 
the above is not already sufficient...?

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Andrei Alexandrescu]

On 9/9/13 2:13 AM, Russel Winder wrote:

On Mon, 2013-09-09 at 01:43 -0700, Andrei Alexandrescu wrote:
[…]

I see no problem with making it a repo under the D-programming-language org.


As long as 1 of the 21 members of the organization will take on the
responsibility for it then fine, go with it. Then we can delete the
Emacs-D-Mode-Maintainers group.

We'll need to update the MELPA entry so the pulls come from the new
repository.

We'll also have to amend Launchpad stuff as well.


OK, so what's the next step? To whom should we talk? Could you carry the 
message?


Andrei

Re: Move VisualD to github/d-programming-language ?

[Paulo Pinto]

Am 09.09.2013 10:29, schrieb Russel Winder:

On Sun, 2013-09-08 at 23:00 +0200, Ramon wrote:

Just for the sake of completeness:

mono is *detested* and considered even more inacceptable than
java by many linux and (even more) *BSD users.


It also appears that Microsoft are beginning to think the whole CLR
thing is on it's last legs.

The whole "all non-Windows users have to hate C#" thing has some basis
in fact but also had a lot of FUD associated with it.  The "Mono hatred"
stemmed from that. So will Microsoft go after Mono with patent suits if
they are not themselves using C# and CLR? They possibly might as an
income stream, but it is unlikely to be profitable and so may be not.

Without solid support from Microsoft the C#F#/CLR culture is unlikely to
remain strong, despite the serious success F# has had in making people
interested in CLR. And C# is not a bad language, in many ways much
better than Java. But Java has staying power in ways C#/F# do not.
...


I wonder where you got this idea from.

.NET is pretty strong at Microsoft conferences, even this year BUILD had 
lots of new goodies announced.


They can decide to target the WinRT runtime instead of the CLR, go fully
native instead of generating MSIL bytecodes, or keep using CLR.

There are lots of options still open and as someone that is active in 
both JVM and .NET worlds, I don't see .NET slowing down in the 
enterprise space. Pretty much the contrary actually, looking at the

requests for proposals my employer receives.


--
Paulo

Re: new DIP47: Outlining member functions of aggregates

[jostly]

On Monday, 9 September 2013 at 14:22:15 UTC, Joseph Rushton 
Wakeling wrote:
Question: do you have any access to information about similar 
short-deadline programming activity using other languages 
(Java, C# ...) that also forbid the separation of declaration 
and definition, and how devs using those languages cope with 
that?  It might offer an alternative solution that no one here 
has thought of.


As a long-time Java developer, my answer would be that it's dealt 
with via careful code crafting. Keep classes small, follow the 
principle of single responsibility etc. There are tons of good 
advice for writing maintainable, easy-to-understand code. And 
there's certainly nothing stopping us from doing the same in D.


However, if I understood Manu correctly, the issue here is those 
instances where there is not a lot of time, as in 48-hour game 
jams and game industry crunch mode. The cases where it is felt 
that code quality takes second place to getting things out fast.


In those cases, I think Java people would feel the same problem. 
It can be alleviated, in Java, by making sure you write 
interfaces for all public-facing code. The same could be done in 
D, but I am unsure if that would involve a performance hit that 
might actually matter in games programming. So at that point, the 
Java programmer would rely on the IDE to make sense of the 
bigfiles they are producing.


Now, I think an argument could be made that the initial 
productivity loss from performing refactorings to make sure you 
are producing maintainable code will pay off in a short while, 
even in crunchmode, but I realise this is something the games 
industry in general would have to deal with, and it should not be 
a burden put upon the individuals wishing to adopt D for making 
games.


As for the DIP, I would not want to code using that style myself, 
but I wouldn't mind it if the requirement was to keep all parts 
of the same class in the same module. Once we start crossing file 
boundaries, finding out where stuff is is going to be terrible 
unless you have a good IDE support for things like "Go to 
definition".

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Russel Winder]

On Mon, 2013-09-09 at 19:37 +0200, Joseph Rushton Wakeling wrote:
[…]
> Actually this was just a shout-out to a few years back when we were both 
> fairly 
> active members of the bzr mailing list :-)  I do still follow it, but I think 
> sadly you are now one of the few remaining active list members ... ?

:-)

and 

:-(

Bazaar (and Mercurial) were the only usable DVCSs early on, but already
by 2006, O'Reilly had decided that Git was the winner and everything
else was history – they effectively created a self-fulfilling prophecy.
Git has over the years been bullied into being almost usable, Bazaar has
lost it's major supporter and Mercurial drifts on the edge of being
mainstream relevant. The USP of Git for me is remote tracking branches.
I forgive a lot of unusability in Git for that.

The interesting player in the game that is still around and really good,
but very few have heard of is Fossil.

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


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

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Joseph Rushton Wakeling]

On 09/09/13 19:47, Russel Winder wrote:

Bazaar (and Mercurial) were the only usable DVCSs early on, but already
by 2006, O'Reilly had decided that Git was the winner and everything
else was history – they effectively created a self-fulfilling prophecy.
Git has over the years been bullied into being almost usable, Bazaar has
lost it's major supporter and Mercurial drifts on the edge of being
mainstream relevant. The USP of Git for me is remote tracking branches.
I forgive a lot of unusability in Git for that.


I have personally drifted quite strongly towards git over the last 4 years.  I 
agree the UI of bzr is still friendlier, but I have come to appreciate many of 
the features of git and these days the extra complexity is not that much 
greater.  That said, partly it's simply a consequence of the projects I'm 
involved with these days.


Whatever my personal software choices, I'm very sad that bzr is no longer really 
in the game.  It was an excellent tool, the first VCS I really used, and a great 
way to learn the principles of DVCS.



The interesting player in the game that is still around and really good,
but very few have heard of is Fossil.


I have heard of it, but never tried it.  I really must give it a look, though -- 
its choice to include bug tracking, wiki pages, etc. within the versioned 
history was something I found both intriguing and very attractive.


How does it fare on the speed/scale front?

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Russel Winder]

On Mon, 2013-09-09 at 11:38 +0200, Joseph Rushton Wakeling wrote:
[…]
> If it's Emacs stuff, shouldn't it be versioned in bzr? :-)

It used to be, but a decision was made that it should be in the VCS of D
rather than the VCS of Emacs. Given MELPA copes with Git and Bazaar,
this turned into a free-choice.

[…]
> I don't see that necessarily needs to be so.  Different projects should be 
> able 
> to have different gatekeepers/maintainers.  If that's problematic, if GitHub 
> won't support separate maintainer groups for different repositories of 
> D-Programming-Language, there are probably other ways round it -- e.g. the 
> maintainers could have a separate project branch, and the 
> D-Programming-Language 
> repo could auto-pull from it (and never be pushed to directly).

As far as I am aware there is no concept of distinct and separately
managed "sub-organization". So if a repository is owned by an
organization only members of that organization have write permission. Or
can the write permissions be managed per repository so that additional
individual write members are allowed per repository. If the latter is
possible it solves all the problems I am concerned over.

I think we need to keep the repositories simple with branches only for
feature work and maintenance work. Having branches for internal
management would just indicate an inability of GitHub to handle the
workflow.

> Also, so long as everyone is trustworthy and limits their activity to their 
> sphere of responsibility, there's no reason why you shouldn't just have a 
> large 
> maintainer group.  If you can't trust maintainer-of-project-X to only use 
> admin 
> powers for project X, and not for project Y as well, then why is he/she 
> maintainer of project X in the first place?

There is that :-)

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


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

Re: new DIP47: Outlining member functions of aggregates

[Joseph Rushton Wakeling]

On 09/09/13 18:41, Ettienne Gilbert wrote:

I would argue that it is actually better this way (that not all functions need
to be in the declarations list) - its way more flexible! This way you can leave
out function declarations that you are not really interested to see from a
"functional overview perspective" of the class.


AFAICS the request is for separation of declaration and definition, so you'd be 
able to do things like this:


class Foo
{
void foo();
int bar(double x);
void goo(int n);
// ... etc.
}

... and then later in the same file:

void Foo.foo()
{
/* ... function body ... */
}

int Foo.bar(double x)
{
/* ... ditto ... */
}

void Foo.goo(int n)
{
/* ... and so on ... */
}

Now, you'd be at liberty to mix declarations and definitions in the _class_ (or 
struct) declaration, e.g.:


class Foo
{
void foo(); // we define this somewhere else

int bar(double x)
{
/* ... but we define this here */
}

// ... etc.
}

But supposing that a function is declared but not defined inside the class 
declaration, it should be obligatory that it _is_ defined somewhere else in the 
file -- and conversely, if a class function is defined somewhere else in the 
file, it should be obligatory that it's declared in the class declaration.


And on top of that, it should be obligatory that the declaration and definition 
match perfectly.  (Note that for any function defined in the class declaration, 
this is automatically and unavoidably true:-)



AFAIC the cost of implementing this would be way too high for any potential
benefit gained from this. And, since Walter already stated that this would "no
way be mandatory", the implications are that the compiler would need to enforce
it once any one function is declared in the declarations list, but... not
enforce it if no functions are declared in the list!


I am personally inclined to leave it to Walter to decide whether the cost of 
this is too much.  At the very least having this possibility seems to be in line 
with earlier plans.



Also, leaving it flexible as it is now cannot silently break anything. Worse
that can happen is that you may inadvertently try to implement goo() twice
(since you may think the missing declaration imply there is no definition), but
then the compiler will anyway complain about the duplicate definition.

So I agree with Jacob Carlborg - I would also like to know why the above is not
already sufficient...?


Because it allows a situation where you can have an incomplete list of member 
function declarations for a class or struct, and yet not know that it's 
incomplete without manual checking -- which I think fails to satisfy the needs 
Manu has identified.


We can reasonably debate whether those needs are worth addressing at all, and 
whether addressing them comes at too high a cost, but we should be clear on what 
solutions address them properly and what don't.

Re: On inlining in D libraries

[Johannes Pfau]

On Monday, 9 September 2013 at 14:58:56 UTC, Dmitry Olshansky 
wrote:

09-Sep-2013 18:39, Joseph Rushton Wakeling пишет:

On 09/09/13 16:34, Dmitry Olshansky wrote:
On the bright side of things std.regex is real fast on LDC 
*when

hacked* to
inline the critical bits :)


Do you mean when manually inlined, or when the design is 
tweaked to

facilitate inlining?


When I put extra () to indicate that said functions are 
templates.

Then compiler gets its grip on them and finally inlines.
Otherwise it generates calls and links in object code from 
libphobos.


Which is the whole reason for the topic - is THAT is the way to 
go?
Shouldn't compiler look into source for inlinable stuff (when 
source is available)?




I only know about GDC and GDC doesn't implement cross-module 
inlining right now. If the modules are compiled in a single run 
it might work but if the modules are compiled separately then 
only LTO (not tested with GDC though!) can help.


AFAIK the problem is this: There's no high-level way to tell the 
backend "hey, I have the source code for this function. if you 
consider inlining call me back and I'll compile it for you". The 
only hack which could work is _always_ compiling _all_ functions 
from all modules. But compile times will explode.


Another issue is that whether a function will be inlined depends 
on details like the number of compiled instructions. Those 
details are only available once the function is compiled, the 
source code is not enough.


Maybe a reasonable compromise could be made with some help from 
the frontend. The frontent could give us some hints ("Likely 
inlineable"). Then we could compile all "likely inlineable" 
functions and let the backend decide if it really wants to inline 
those.


(Another options is inlining in the frontend. DMD does that right 
now but IIRC it causes problems with the GCC backend and is 
disabled in GDC). Iain can probably give a better answer here.


(Note: there's a low-level way to do this: LTO actually adds 
intermediate code to the object files. If the linker wants to 
inline a function, it calls the compiler to compile that 
intermediate code: 
http://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html . In the 
end working LTO is probably the best solution.)

Re: new DIP47: Outlining member functions of aggregates

[Jesse Phillips]

On Sunday, 8 September 2013 at 19:47:06 UTC, Andrej Mitrovic 
wrote:

On 9/8/13, Jesse Phillips  wrote:

I realize that we want to make it as painless as possible for
Remedy to switch from C++ to D (along with the rest of the game
developers).


FWIW I don't think this has anything to do with Remedy (afaik 
Manu

doesn't work there anymore).


I did not realize he had left, but I did realize he was speaking 
for himself. I'm mostly just using Remedy as the symbol of large 
C++ code bases/programmers which want to use D because they 
actually are. I could see Manu's position being common for this 
user type, I don't think it is common for most D or other 
language programmers.

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Joseph Rushton Wakeling]

On 09/09/13 19:41, Russel Winder wrote:

I can handle all the Launchpad and Bazaar end of things as we leave that
infrastructure exactly as it is now. It is only there really as
terminating Launchpad projects seems to need personal authority from
Mark Shuttleworth.


Really?!!  Seems a bit extreme.

I suppose though there is a benefit in making it impossible for a project 
maintainer to unilaterally declare an end to the project and take down its pages 
(cf. the whole openMosix mess).

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Russel Winder]

On Mon, 2013-09-09 at 09:34 -0700, Andrei Alexandrescu wrote:
> On 9/9/13 2:13 AM, Russel Winder wrote:
[…]
> > We'll need to update the MELPA entry so the pulls come from the new
> > repository.

I'll have to check this. I didn't set it up, it all seemed to happen by
magic, i.e. someone with MELPA control powers just started pulling and
packaging our repository. Which was good.

> > We'll also have to amend Launchpad stuff as well.
> 
> OK, so what's the next step? To whom should we talk? Could you carry the 
> message?

I can handle all the Launchpad and Bazaar end of things as we leave that
infrastructure exactly as it is now. It is only there really as
terminating Launchpad projects seems to need personal authority from
Mark Shuttleworth.

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


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

Re: Move VisualD to github/d-programming-language ?

[Russel Winder]

On Mon, 2013-09-09 at 11:11 +0200, Joseph Rushton Wakeling wrote:
[…]
> I'd add Ubuntu also to that list, simply because of the number of users -- 
> it's 
> helpful to ensure that every 6 months, such a widely-used distro has the 
> latest 
> D tools.

Unless Ubuntu changes it's strategy being in Debian Unstable means you
get slurped into the next Ubuntu.

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


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

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Joseph Rushton Wakeling]

On 09/09/13 19:29, Russel Winder wrote:

On Mon, 2013-09-09 at 11:38 +0200, Joseph Rushton Wakeling wrote:
[…]

If it's Emacs stuff, shouldn't it be versioned in bzr? :-)


It used to be, but a decision was made that it should be in the VCS of D
rather than the VCS of Emacs. Given MELPA copes with Git and Bazaar,
this turned into a free-choice.


Actually this was just a shout-out to a few years back when we were both fairly 
active members of the bzr mailing list :-)  I do still follow it, but I think 
sadly you are now one of the few remaining active list members ... ?

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Russel Winder]

On Mon, 2013-09-09 at 06:57 -0700, Walter Bright wrote:
[…]
> If someone can point me to how to make it so, I'll take care of it.

I will check, but I think ownership change is a push operation rather
than a pull operation. Andrei has write powers in both organizations and
so is the person who can action the ownership transfer. At that point
the other members of the current organization will lose write permission
and will have to resort to pull requests themselves.

It is really that someone with write permission has to ensure pull
requests get actioned in reasonable time with reasonable evidence. Sadly
this generally involves running the updates themselves as E-Lisp has
very poor testing facilities so TDD is not really an option :-(

> > As long as 1 of the 21 members of the organization will take on the
> > responsibility for it then fine, go with it. Then we can delete the
> > Emacs-D-Mode-Maintainers group.
> 
> Even better, I can create a TeamEmacs group that will have pull power for the 
> Emacs repository, and they can be the people who have it for the previous 
> group.

We already have an organization Emacs-D-Mode-Maintainers is that what
you need?

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


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

Re: On inlining in D libraries

[Adam D. Ruppe]

On Monday, 9 September 2013 at 17:42:04 UTC, Johannes Pfau wrote:

But compile times will explode.


Are you sure?

time dmd hello.d # import std.stdio; void main() { 
writeln("hello"); }

real0m0.665s

$ time dmd hello.d d/dmd2/src/phobos/std/*.d
std.md5 is scheduled for deprecation. Please use std.digest.md 
instead


real0m2.367s


That's slow for hello world, but not a dealbreaker to me since 
larger projects can easily exceed that anyway (especially with 
optimizations turned on). And that's making no attempt to only 
compile the files actually imported.


If we try to be smarter about it:

time dmd hello.d 
d/dmd2/src/phobos/std/{stdio,conv,format,string,traits,typetuple,typecons,bitmanip,system,functional,utf,uni,container,random,numeric,complex,regex,stdiobase}.d


real0m1.119s


It's adding about 1/2 second to the compile time - note, not 
really doubling it since more complex user code would take a 
bigger fraction of the total than phobos as the app grows - 
which really isn't awful.



At least when specifically asking for -inline, I think this is 
worth the extra compile time.

Re: D and Emacs [ was Re: Move VisualD to github/d-programming-language ? ]

[Paulo Pinto]

Am 09.09.2013 19:47, schrieb Russel Winder:

On Mon, 2013-09-09 at 19:37 +0200, Joseph Rushton Wakeling wrote:
[…]

Actually this was just a shout-out to a few years back when we were both fairly
active members of the bzr mailing list :-)  I do still follow it, but I think
sadly you are now one of the few remaining active list members ... ?


:-)

and

:-(

Bazaar (and Mercurial) were the only usable DVCSs early on, but already
by 2006, O'Reilly had decided that Git was the winner and everything
else was history – they effectively created a self-fulfilling prophecy.
Git has over the years been bullied into being almost usable, Bazaar has
lost it's major supporter and Mercurial drifts on the edge of being
mainstream relevant. The USP of Git for me is remote tracking branches.
I forgive a lot of unusability in Git for that.

The interesting player in the game that is still around and really good,
but very few have heard of is Fossil.



On Windows world, Mercurial still has the edge over Git, given the poor 
Windows support.


This will eventually change given the recent endorsement Microsoft has 
given to Git on their tooling, but it will still take some time to change.


--
Paulo

Re: Move VisualD to github/d-programming-language ?

[Joseph Rushton Wakeling]

On 09/09/13 19:59, Russel Winder wrote:

Unless Ubuntu changes it's strategy being in Debian Unstable means you
get slurped into the next Ubuntu.


Yes, I know, but GDC is still fast-moving enough that the latest update might 
not make it via the Debian Unstable slurp.  Unless there's a close enough 
relationship that any updates to GCC in Debian Unstable also get pulled through 
into Ubuntu whenever they're made?

Re: On inlining in D libraries

[Dmitry Olshansky]

09-Sep-2013 21:42, Johannes Pfau пишет:

On Monday, 9 September 2013 at 14:58:56 UTC, Dmitry Olshansky wrote:

09-Sep-2013 18:39, Joseph Rushton Wakeling пишет:

On 09/09/13 16:34, Dmitry Olshansky wrote:

On the bright side of things std.regex is real fast on LDC *when
hacked* to
inline the critical bits :)


Do you mean when manually inlined, or when the design is tweaked to
facilitate inlining?


When I put extra () to indicate that said functions are templates.
Then compiler gets its grip on them and finally inlines.
Otherwise it generates calls and links in object code from libphobos.

Which is the whole reason for the topic - is THAT is the way to go?
Shouldn't compiler look into source for inlinable stuff (when source
is available)?



I only know about GDC and GDC doesn't implement cross-module inlining
right now. If the modules are compiled in a single run it might work but
if the modules are compiled separately then only LTO (not tested with
GDC though!) can help.

AFAIK the problem is this: There's no high-level way to tell the backend
"hey, I have the source code for this function. if you consider inlining
call me back and I'll compile it for you". The only hack which could
work is _always_ compiling _all_ functions from all modules. But compile
times will explode.


Precisely the problem we have and the current state of things. Compiling 
everything would be option B).


The solution sought after is not how to hack this around but how to make 
everything work nicely out of the box (for everybody).



Another issue is that whether a function will be inlined depends on
details like the number of compiled instructions. Those details are only
available once the function is compiled, the source code is not enough.

Maybe a reasonable compromise could be made with some help from the
frontend. The frontent could give us some hints ("Likely inlineable").
Then we could compile all "likely inlineable" functions and let the
backend decide if it really wants to inline those.

(Another options is inlining in the frontend. DMD does that right now
but IIRC it causes problems with the GCC backend and is disabled in
GDC). Iain can probably give a better answer here.


DMD's AST re-writing inliner is rather lame currently, hence just not 
worth the trouble I suspect.




(Note: there's a low-level way to do this: LTO actually adds
intermediate code to the object files. If the linker wants to inline a
function, it calls the compiler to compile that intermediate code:
http://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html . In the end
working LTO is probably the best solution.)


LTO would be the best solution but at the moment it's rather rarely used 
optimization with obscure issues of its own.


It makes me think that generating generic (& sensible) IR instead of 
object code and doing inlining of that is a cute idea.. but wait that's 
what LLVM analog of LTO should do.


--
Dmitry Olshansky

Re: The definitive guide to Trolls (was Move VisualD to github).

[H. S. Teoh]

On Mon, Sep 09, 2013 at 04:48:29PM +0200, Iain Buclaw wrote:
> Rather off topic but amusing source of information just to lighten
> up the attitude of some.  I'm sure everyone here probably relates
> vaguely to at least one of the characters - which one are you? :o)
> 
> http://www.flamewarriorsguide.com/
[...]

Thanks for the link! I had a good belly laugh at some of the Flame
Warriors, especially since they are very pertinent to some of the recent
exchanges. :)


T

-- 
My program has no bugs! Only undocumented features...

Re: The definitive guide to Trolls (was Move VisualD to github).

[Joseph Rushton Wakeling]

On 09/09/13 20:05, H. S. Teoh wrote:

Thanks for the link! I had a good belly laugh at some of the Flame
Warriors, especially since they are very pertinent to some of the recent
exchanges. :)


Who do you think is who? :-)

Re: Move VisualD to github/d-programming-language ?

[Russel Winder]

On Mon, 2013-09-09 at 18:31 +0200, Paulo Pinto wrote:
[…]
> I wonder where you got this idea from.

It may just be FUD, but…

> .NET is pretty strong at Microsoft conferences, even this year BUILD had 
> lots of new goodies announced.
> 
> They can decide to target the WinRT runtime instead of the CLR, go fully
> native instead of generating MSIL bytecodes, or keep using CLR.

There appears to be a lowering of the CLR position in the Microsoft
public stances, and a rise of the native position (mostly C++).
Clearly .NET remains a strong Microsoft technology in the short term,
but it has not really achieved the penetration recently that perhaps it
should. Many organizations I deal with are planning to replace CLR-based
technologies.

A lot of the organizations that were Java at the centre, and C# on the
leaf nodes, are switching to Scala at the centre and Python at the leaf
nodes. I present as personal evidence the amount of training work I am
doing, but others are reporting similar. Admittedly this is areas where
number crunching is an important component. So instead of CLR, there is
a focus on JVM and native for crunching and Python for control and
visualization. D could be a strong part of this and I keep making
miniature technical marketing pitches whenever possible, but the C++
codes are already in place, and their strategy is already in place.

> There are lots of options still open and as someone that is active in 
> both JVM and .NET worlds, I don't see .NET slowing down in the 
> enterprise space. Pretty much the contrary actually, looking at the
> requests for proposals my employer receives.

Clearly we are in very different sectors. Everywhere I am going JVM and
native is displacing CLR. I can quite happily believe both our
observations are correct!


PS It has not passed my notice that revolutionary technical change often
follows from the appointment of new CTOs, not necessarily from any
burning need to change the technology. However it is sometimes easier to
put in place needed replacement of components by revolutionary rather
than evolutionary methods.
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


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

Re: new DIP47: Outlining member functions of aggregates

[Jesse Phillips]

On Monday, 9 September 2013 at 03:46:23 UTC, Manu wrote:
People make claims like "write better code, split it up better, 
document
your code better, use the IDE folding", blah blah, but it's 
simply not the
practical reality. The budget and schedule does not typically 
allow for
careful consideration, design, and documentation of such throw 
away code

which glues the project together.


I think DDOC should be improved to handle this scenario. Being 
able to generate docs with undocumented members would be great 
for internal development of the module. I realize that doesn't 
address all your problems, but I think that is the correct 
direction.

Re: new DIP47: Outlining member functions of aggregates

[Joseph Rushton Wakeling]

On 09/09/13 20:05, Jesse Phillips wrote:

I think DDOC should be improved to handle this scenario. Being able to generate
docs with undocumented members would be great for internal development of the
module. I realize that doesn't address all your problems, but I think that is
the correct direction.


Better DDoc is always going to be nice, but come on -- that doesn't address the 
issue of looking at code in a diff or a copy-paste via chat software, and in the 
scenarios Manu has described, no one's going to have time to write documentation 
comments.


OK, you could have a DDoc setting to at least _list_ all elements of class 
interfaces etc., even if there's no doc comment, but that doesn't address the 
other factors.

Re: The definitive guide to Trolls (was Move VisualD to github).

[H. S. Teoh]

On Mon, Sep 09, 2013 at 08:08:05PM +0200, Joseph Rushton Wakeling wrote:
> On 09/09/13 20:05, H. S. Teoh wrote:
> >Thanks for the link! I had a good belly laugh at some of the Flame
> >Warriors, especially since they are very pertinent to some of the
> >recent exchanges. :)
> 
> Who do you think is who? :-)

I think I'll refrain from answering that, lest I add fuel to the flames.
:-P


T

-- 
"Computer Science is no more about computers than astronomy is about 
telescopes." -- E.W. Dijkstra