www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - If you had money to place for a bounty, what would you choose?

reply "Fra" <Fra b.it> writes:
Personally I would love to see this old issue finally 
implemented/fixed:
There can be only one alias this.
https://d.puremagic.com/issues/show_bug.cgi?id=6083

What would your choice be?
Nov 28 2013
next sibling parent "eles" <eles eles.com> writes:
On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


http://d.puremagic.com/issues/show_bug.cgi?id=11365
Nov 28 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


http://d.puremagic.com/issues/show_bug.cgi?id=9238
Nov 28 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
If I had the money, I'd not just place a bounty, I'd hire a team of
dedicated programmers to work full-time to fix the current AA
implementation, once and for all.  There are at least 76 AA-related
issues[1] on my list, many of which are not just trifling bugs but
fundamental design issues.

I know of at least one person who got turned off D due to an AA bug
(fortunately I rescued the situation by fixing said bug). I'd like for
that not to happen again.

[1] https://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc=aa%20associative%20hash&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=anywordssubstr&version=D1%20%26%20D2&version=D2&known_name=aa&query_based_on=aa


T

-- 
Кто везде - тот нигде.
Nov 28 2013
parent reply "Fra" <Fra b.it> writes:
On Thursday, 28 November 2013 at 21:38:12 UTC, H. S. Teoh wrote:

 If I had the money, I'd not just place a bounty, I'd hire a 
 team of
 dedicated programmers to work full-time to fix the current AA
 implementation, once and for all.  There are at least 76 
 AA-related
 issues[1] on my list, many of which are not just trifling bugs 
 but
 fundamental design issues.


How much would it take? Really, it looks like a few monts of 
man-work, maybe even a year?
Nov 28 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 28, 2013 at 11:06:41PM +0100, Fra wrote:

 On Thursday, 28 November 2013 at 21:38:12 UTC, H. S. Teoh wrote:

If I had the money, I'd not just place a bounty, I'd hire a team of
dedicated programmers to work full-time to fix the current AA
implementation, once and for all.  There are at least 76 AA-related
issues[1] on my list, many of which are not just trifling bugs but
fundamental design issues.


 How much would it take? Really, it looks like a few monts of
 man-work, maybe even a year?


The thing is, it *looks* relatively manageable on the surface, but the
more you get into it, the more you realize how fundamentally and
irreparably broken it really is.

One of the most problematic things is that its implementation is
sprinkled throughout DMD (each bit interacting in intricate ways with
its surroundings), object_.d (a sort of hybrid half-user, half-built-in
struct AssociativeArray), and aaA.d (the core runtime implementation).
Each of these pieces interact in complex ways with each other, and don't
always share the same information together.

My favorite gripe is how struct AssociativeArray knows about the
compile-time types of keys and values, but aaA.d has no direct access to
that information except via the TypeInfo of the key, passed in at
runtime... but it *doesn't* know anything about the *value* type except
as an opaque block of bytes, so for example storing value types with
non-default .init values does not initialize it correctly -- but most of
the time the problem doesn't show up because when you write aa[x]=y, the
wrong default initial value gets overwritten by y, which presumably is
initialized correctly. But should you write aa[x]++ instead, then the
problem suddenly pops up its head.

Not to mention, anything involving type qualifiers like const or
immutable are horribly broken except for the simplest cases, and are so
fundamentally broken it would take a complete rewrite to get it right.

To even begin to do anything about this mess, the team has to thoroughly
understand dmd internals, aaA.d, and struct AssociativeArray. Then they
have to figure out how to extricate the AA-dependent parts of dmd out of
all the places they're sprinkled in, *without* breaking the rest of the
language, so that a proper library replacement can be put in its place.
(Not to mention that said replacement must be 100% compatible with
existing D code, lest hordes of angry users knock down your door -- not
a trivial task given the current quirks of AA.) And all the while dmd
receives a continuous stream of pull requests every day, so when it's
all finally said and done, you'll have a veritable nightmare resolving
the conflicts when you merge all the inevitable large-scale changes back
to git HEAD.

It's not an insurmountable task, of course. But it's not gonna get done
with a few scattered volunteer hours here, a few minutes of spare time
there.  You need a dedicated team of coders actively working on it
continuously to get through it all.


T

-- 
This is not a sentence.
Nov 28 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:


 Then they
 have to figure out how to extricate the AA-dependent parts of 
 dmd out of
 all the places they're sprinkled in, *without* breaking the 
 rest of the
 language, so that a proper library replacement can be put in 
 its place.
 (Not to mention that said replacement must be 100% compatible 
 with
 existing D code, lest hordes of angry users knock down your 
 door -- not
 a trivial task given the current quirks of AA.)


The new AAs should be allowed to drop some of the precedent 
quirks and to introduce several new fresh quicks.

Bye,
bearophile
Nov 28 2013
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.152.1385681675.3242.digitalmars-d puremagic.com...

 One of the most problematic things is that its implementation is
 sprinkled throughout DMD (each bit interacting in intricate ways with
 its surroundings), object_.d (a sort of hybrid half-user, half-built-in
 struct AssociativeArray), and aaA.d (the core runtime implementation).
 Each of these pieces interact in complex ways with each other, and don't
 always share the same information together.


We can at least fix the hybrid situation:

https://github.com/D-Programming-Language/dmd/pull/2856
Nov 28 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 29, 2013 at 01:52:19PM +1100, Daniel Murphy wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.152.1385681675.3242.digitalmars-d puremagic.com...

 One of the most problematic things is that its implementation is
 sprinkled throughout DMD (each bit interacting in intricate ways
 with its surroundings), object_.d (a sort of hybrid half-user,
 half-built-in struct AssociativeArray), and aaA.d (the core runtime
 implementation).  Each of these pieces interact in complex ways with
 each other, and don't always share the same information together.


 
 We can at least fix the hybrid situation:
 
 https://github.com/D-Programming-Language/dmd/pull/2856


[...]

Excellent!! This will cut my budget in half! ;-)

What about the AA value type issue?


T

-- 
"Life is all a great joke, but only the brave ever get the point." -- Kenneth
Rexroth
Nov 29 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.165.1385740581.3242.digitalmars-d puremagic.com...

 On Fri, Nov 29, 2013 at 01:52:19PM +1100, Daniel Murphy wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.152.1385681675.3242.digitalmars-d puremagic.com...

 One of the most problematic things is that its implementation is
 sprinkled throughout DMD (each bit interacting in intricate ways
 with its surroundings), object_.d (a sort of hybrid half-user,
 half-built-in struct AssociativeArray), and aaA.d (the core runtime
 implementation).  Each of these pieces interact in complex ways with
 each other, and don't always share the same information together.


 We can at least fix the hybrid situation:

 https://github.com/D-Programming-Language/dmd/pull/2856


 [...]

 Excellent!! This will cut my budget in half! ;-)

 What about the AA value type issue?


I don't think we do anything.  Let the builtin AA type be simple, slow, and 
reliable.  When performance matters, use a library type you can customize.
Nov 29 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Nov 30, 2013 at 05:47:37PM +1100, Daniel Murphy wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.165.1385740581.3242.digitalmars-d puremagic.com...


[...]

 What about the AA value type issue?


 
 I don't think we do anything.  Let the builtin AA type be simple,
 slow, and reliable.  When performance matters, use a library type you
 can customize. 


[...]

Sorry, I meant, what to do about aaA.d not being passed the TypeInfo of
AA values. This causes things like aa[key]++ to produce wrong results
when the value's .init isn't binary zero.


T

-- 
Life is complex. It consists of real and imaginary parts. -- YHL
Nov 30 2013
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.184.1385824673.3242.digitalmars-d puremagic.com...

 On Sat, Nov 30, 2013 at 05:47:37PM +1100, Daniel Murphy wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.165.1385740581.3242.digitalmars-d puremagic.com...


 [...]

 What about the AA value type issue?


 I don't think we do anything.  Let the builtin AA type be simple,
 slow, and reliable.  When performance matters, use a library type you
 can customize.


 [...]

 Sorry, I meant, what to do about aaA.d not being passed the TypeInfo of
 AA values. This causes things like aa[key]++ to produce wrong results
 when the value's .init isn't binary zero.


Oh ok.  I guess we fix it.
Nov 30 2013
prev sibling next sibling parent =?UTF-8?B?U2ltZW4gS2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On 28.11.2013 22:01, Fra wrote:

 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


https://d.puremagic.com/issues/show_bug.cgi?id=8570
https://d.puremagic.com/issues/show_bug.cgi?id=11616

Actually, 8570 should be closed, and a DIP be written about implicit 
conversions.

-- 
   Simen
Nov 28 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Nice game "guess linked bug by poster nickname" :)
Nov 28 2013
parent "eles" <eles eles.com> writes:
On Friday, 29 November 2013 at 00:52:27 UTC, Dicebot wrote:

 Nice game "guess linked bug by poster nickname" :)


mine quite works
Nov 29 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-28 22:01, Fra wrote:

 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


Binary compatibility with Objective-C:

http://michelf.ca/projects/d-objc/

Or dynamic libraries for Mac OS X.

-- 
/Jacob Carlborg
Nov 29 2013
parent reply Manu <turkeyman gmail.com> writes:
On 29 November 2013 23:27, Jacob Carlborg <doob me.com> wrote:


 On 2013-11-28 22:01, Fra wrote:


 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


 Binary compatibility with Objective-C:

 http://michelf.ca/projects/d-objc/



I've been very excited about this for a long time... why is it sitting in
limbo?
How is the implementation? Is there a reason nobody seems to be actually
considering it for inclusion?
OSX/iOS are 2 very important platforms, and I too would really love to see
movement on this work.
Nov 29 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-29 15:08, Manu wrote:


 I've been very excited about this for a long time... why is it sitting
 in limbo?


I don't know. It seems Walter don't want us to be worse than 
Objective-C, meaning he want ARC. But as far as I understand it, we 
couldn't come to an agreement on how to implement ARC. But to be able to 
be compatible with ARC in Objective-C we would need to follow that very


 How is the implementation?


Unfortunately only for 32bit and the legacy runtime. iOS uses the modern 
runtime. It's also missing some features like blocks and categories.


 Is there a reason nobody seems to be actually considering it for inclusion?
 OSX/iOS are 2 very important platforms, and I too would really love to
 see movement on this work.


I could try and get it up to date again, just do a pull and see what 
happens.

-- 
/Jacob Carlborg
Nov 29 2013
parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-29 15:10:27 +0000, Jacob Carlborg <doob me.com> said:


 On 2013-11-29 15:08, Manu wrote:
 

 I've been very excited about this for a long time... why is it sitting
 in limbo?


 
 I don't know. It seems Walter don't want us to be worse than 
 Objective-C, meaning he want ARC. But as far as I understand it, we 
 couldn't come to an agreement on how to implement ARC. But to be able 
 to be compatible with ARC in Objective-C we would need to follow that 
 very


Actually, if you want ARC to be compatible with Objective-C, someone 
familiar with Objective-C memory management has to design and implement 
the thing. Anything designed to work for Objective-C can easily be 
retrofitted to work with other D types, but the reverse is not true. So 
I'd tend to say it'd be better to implement ARC as part of the 
D/Objective-C project first, otherwise you're trying to solve too many 
problems at the same time and it becomes a mess.


-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Nov 29 2013
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-11-29 14:08:25 +0000, Manu <turkeyman gmail.com> said:


 On 29 November 2013 23:27, Jacob Carlborg <doob me.com> wrote:
 

 Binary compatibility with Objective-C:
 
 http://michelf.ca/projects/d-objc/


 
 I've been very excited about this for a long time... why is it sitting in
 limbo?
 How is the implementation? Is there a reason nobody seems to be actually
 considering it for inclusion?
 OSX/iOS are 2 very important platforms, and I too would really love to see
 movement on this work.


If I were Walter, I wouldn't accept it in the state it is currently in. 
The missing support for the modern runtime makes it look like a 
gimmick, as the legacy runtime is dead end (Apple is already dropping 
32-bit support with new OS X frameworks). And no ARC makes it look bad 
compared to regular Objective-C. Lacking support for Objective-C 
categories and for blocks is also problematic.

I'm no longer working on D/Objective-C. And while Jacob has updated it 
to a more modern incarnation of DMD, it's just the minimum to keep it 
afloat. What this project need is sustained development for I don't 
know how many months.

The implementation is quite good, in my opinion. But then I'm the one 
who wrote it. ;-) The important thing to keep in mind is that this is a 
huge and far reaching changeset. It adds things in the parser, in the 
semantic phase, in code generation, in the back end, and in the 
runtime. It's full of internal design decisions which I didn't really 
discuss much with anyone, in most part because most people here are not 
familiar enough with Objective-C (be it the language, its runtime or 
its compiled representation) to know what to do. There's also some 
reverse engineering work to figure out the correct output for compiled 
code, as this is not much documented.

Honestly, this thing is not mere bounty material, it'd be worthy to be 
a Kickstarter project for about a full year of development time.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Nov 29 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-29 20:33, Michel Fortin wrote:


 If I were Walter, I wouldn't accept it in the state it is currently in.
 The missing support for the modern runtime makes it look like a gimmick,
 as the legacy runtime is dead end (Apple is already dropping 32-bit
 support with new OS X frameworks). And no ARC makes it look bad compared
 to regular Objective-C. Lacking support for Objective-C categories and
 for blocks is also problematic.


The advantage of having it merged would be to avoid keeping the fork up 
to date. Although this might risk breaking it, don't know how complete 
the test suite is.


 I'm no longer working on D/Objective-C. And while Jacob has updated it
 to a more modern incarnation of DMD, it's just the minimum to keep it
 afloat. What this project need is sustained development for I don't know
 how many months.

 The implementation is quite good, in my opinion. But then I'm the one
 who wrote it. ;-) The important thing to keep in mind is that this is a
 huge and far reaching changeset. It adds things in the parser, in the
 semantic phase, in code generation, in the back end, and in the runtime.
 It's full of internal design decisions which I didn't really discuss
 much with anyone, in most part because most people here are not familiar
 enough with Objective-C (be it the language, its runtime or its compiled
 representation) to know what to do. There's also some reverse
 engineering work to figure out the correct output for compiled code, as
 this is not much documented.

 Honestly, this thing is not mere bounty material, it'd be worthy to be a
 Kickstarter project for about a full year of development time.


This is most likely correct.

-- 
/Jacob Carlborg
Dec 01 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-12-02 07:54:11 +0000, Jacob Carlborg <doob me.com> said:


 On 2013-11-29 20:33, Michel Fortin wrote:
 

 If I were Walter, I wouldn't accept it in the state it is currently in.
 The missing support for the modern runtime makes it look like a gimmick,
 as the legacy runtime is dead end (Apple is already dropping 32-bit
 support with new OS X frameworks). And no ARC makes it look bad compared
 to regular Objective-C. Lacking support for Objective-C categories and
 for blocks is also problematic.


 
 The advantage of having it merged would be to avoid keeping the fork up 
 to date. Although this might risk breaking it, don't know how complete 
 the test suite is.


I think the test suite is solid enough to catch most regression for the 
current features. But someone familiar with the matter needs to be 
there and have the time to put some understanding in how fix things 
when they break.

More importantly, someone needs to regularly compile on OS X and run 
the Objective-C tests. That last part should be done by the auto-tester 
of course, but since for many contributors it'll be inconvenient to 
test locally those OS-X-only features I predict it'd slow things down a 
little.

Also, there's some parts of the syntax I'd likely want to revise given 
that D has UDAs now. Would it make sense to merge changes to the parser 
just to roll them back later?

(I also had an idea of something better for class extensions 
(categories), but those aren't implemented yet so it does not really 
matter.)

I'm usually quite adverse about releasing unfinished features or 
products, which probably explains why *I* wouldn't merge. Although I 
obviously won't oppose it being merged if someone wants to. I'm just 
not sure it is worth the trouble for the core team right now given the 
lack of some key features.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Dec 02 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-02 14:27, Michel Fortin wrote:


 Also, there's some parts of the syntax I'd likely want to revise given
 that D has UDAs now. Would it make sense to merge changes to the parser
 just to roll them back later?


That's true, and no, we don't want to roll them back later.


 I'm usually quite adverse about releasing unfinished features or
 products, which probably explains why *I* wouldn't merge. Although I
 obviously won't oppose it being merged if someone wants to. I'm just not
 sure it is worth the trouble for the core team right now given the lack
 of some key features.


I understand that. Although I think it's still usable as it is. It's so 
cumbersome and verbose to use Objective-C libraries from D that I think 
it's worth adding these features, even they're not complete.

-- 
/Jacob Carlborg
Dec 02 2013
parent reply Manu <turkeyman gmail.com> writes:
On 3 December 2013 17:43, Jacob Carlborg <doob me.com> wrote:


 On 2013-12-02 14:27, Michel Fortin wrote:


 I'm usually quite adverse about releasing unfinished features or
 products, which probably explains why *I* wouldn't merge. Although I
 obviously won't oppose it being merged if someone wants to. I'm just not
 sure it is worth the trouble for the core team right now given the lack
 of some key features.


 I understand that. Although I think it's still usable as it is. It's so
 cumbersome and verbose to use Objective-C libraries from D that I think
 it's worth adding these features, even they're not complete.



C++ support in D is 'not complete', but what's there now is still very
important and not considered a bad partial feature to have.
I'd imagine that likewise, if the 'core' of Obj-C support is solid, then
maybe it's worth it in the same sense?
OSX and iOS are 2 of the most popular platforms on earth. The mobile space
is probably the most important prospective target for D.
I can't comment on the state it's in. But if what's there is solid and
useful like the current C++ support, then it's an important start...?
Dec 03 2013
next sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-12-03 16:55:28 +0000, Manu <turkeyman gmail.com> said:


 C++ support in D is 'not complete', but what's there now is still very
 important and not considered a bad partial feature to have.
 I'd imagine that likewise, if the 'core' of Obj-C support is solid, then
 maybe it's worth it in the same sense?
 OSX and iOS are 2 of the most popular platforms on earth. The mobile space
 is probably the most important prospective target for D.
 I can't comment on the state it's in. But if what's there is solid and
 useful like the current C++ support, then it's an important start...?


Here are some issues to consider if you ship it right now:

- transitioning to ARC when that is implemented (do we require a 
compiler flag to enable ARC because it was off by default before and 
turning it on changes the semantics?)
- it's 32-bit-OS-X-only right now, iOS and 64-bit OS X both use a 
different runtime which requires different codegen, and Apple has been 
phasing out 32-bit for some time already
- missing categories will force bindings to be somewhat contorted
- missing blocks will make some of the newer Objective-C APIs inaccessible.

It might have been fine to release that thing 3 years ago with a 
promise that it'll improve. But today it's plain outdated on all 
fronts, and if it doesn't come with a believable roadmap about filling 
the gaps it's going to be seen as a clever gimmick that is not 
particularly useful. That's not unlike a 16-bit pre-C++98 compiler is 
not terribly useful today. We're at a transition, and currently on the 
wrong side of it.

The only way to bring it up-to-date is for someone to redo the codegen 
and to design and implement the missing language features. If merging 
it will accomplish that, then by all means go ahead. But I somewhat 
doubt that magically people will start to work a lot more on 
Objective-C support because it has been merged in. I might be wrong 
though.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Dec 03 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-04 04:47, Michel Fortin wrote:


 - it's 32-bit-OS-X-only right now, iOS and 64-bit OS X both use a
 different runtime which requires different codegen, and Apple has been
 phasing out 32-bit for some time already


BTW, is there much difference between the modern runtime for 32bit and 
64bit? I'm thinking, is things like the optimization of using the 
pointer for storing the data for types like NSNumber used on 32bit with 
the modern runtime?

-- 
/Jacob Carlborg
Dec 04 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-12-04 08:32:15 +0000, Jacob Carlborg <doob me.com> said:


 On 2013-12-04 04:47, Michel Fortin wrote:
 

 - it's 32-bit-OS-X-only right now, iOS and 64-bit OS X both use a
 different runtime which requires different codegen, and Apple has been
 phasing out 32-bit for some time already


 
 BTW, is there much difference between the modern runtime for 32bit and 
 64bit? I'm thinking, is things like the optimization of using the 
 pointer for storing the data for types like NSNumber used on 32bit with 
 the modern runtime?


The pointer magic for NSNumber is pretty much inconsequential: it just 
means you need to use the runtime functions everywhere, such as 
objc_getClass to get a pointer to the class object instead of 
dereferencing the object yourself. But it's a detail to keep in mind.

A big change in the modern runtime is that classes are completely 
non-fragile, in that you can add a member in a superclass without 
breaking binary compatibility with derived classes. Which means that 
instance variables are accessed differently, by checking a global 
constant to find the right offset (initialized when first loading the 
class). I think the compiler also has to emit that constant that the 
runtime will initialize.

Another big change is exception handling which now piggyback on the C++ 
exception mechanism instead of using the inefficient longjump 
implementation of the previous runtime.

There's an optimized path for calling certain methods using a virtual 
table, but we can skip that in a first release as it's an optimisation 
(objc_msgSend still work fine in every case).

Beside that, they changed all the section names for the binary output, 
and probably did a some alterations to the binary structure I'm 
forgetting right now.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Dec 04 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-04 12:43, Michel Fortin wrote:


 The pointer magic for NSNumber is pretty much inconsequential: it just
 means you need to use the runtime functions everywhere, such as
 objc_getClass to get a pointer to the class object instead of
 dereferencing the object yourself. But it's a detail to keep in mind.

 A big change in the modern runtime is that classes are completely
 non-fragile, in that you can add a member in a superclass without
 breaking binary compatibility with derived classes. Which means that
 instance variables are accessed differently, by checking a global
 constant to find the right offset (initialized when first loading the
 class). I think the compiler also has to emit that constant that the
 runtime will initialize.

 Another big change is exception handling which now piggyback on the C++
 exception mechanism instead of using the inefficient longjump
 implementation of the previous runtime.

 There's an optimized path for calling certain methods using a virtual
 table, but we can skip that in a first release as it's an optimisation
 (objc_msgSend still work fine in every case).

 Beside that, they changed all the section names for the binary output,
 and probably did a some alterations to the binary structure I'm
 forgetting right now.


What I actually was asking is if there's any difference in the 32bit 
modern runtime as used by iOS and the 64bit modern runtime? Except for 
the usual differences that exists in C.

-- 
/Jacob Carlborg
Dec 04 2013
parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-12-04 15:08:23 +0000, Jacob Carlborg <doob me.com> said:


 What I actually was asking is if there's any difference in the 32bit 
 modern runtime as used by iOS and the 64bit modern runtime? Except for 
 the usual differences that exists in C.


Nothing different from the compiler perspective, that I know of. The 
modern runtime is pretty much the same everywhere.

-- 
Michel Fortin
michel.fortin michelf.ca
http://michelf.ca
Dec 04 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-12-04 17:23, Michel Fortin wrote:


 Nothing different from the compiler perspective, that I know of. The
 modern runtime is pretty much the same everywhere.


Ok, thanks.

-- 
/Jacob Carlborg
Dec 04 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-03 17:55, Manu wrote:


 C++ support in D is 'not complete', but what's there now is still very
 important and not considered a bad partial feature to have.
 I'd imagine that likewise, if the 'core' of Obj-C support is solid, then
 maybe it's worth it in the same sense?
 OSX and iOS are 2 of the most popular platforms on earth. The mobile
 space is probably the most important prospective target for D.
 I can't comment on the state it's in. But if what's there is solid and
 useful like the current C++ support, then it's an important start...?


I agree but Michel has a point as well. Walter, I think it was, has also 
said that D will never have complete support for C++ because that will 
require to build in a C++ compiler in the D compiler. That's not 
something we would like to do.

Objective-C, on the other hand, would be much more realistic to add 
complete support for.

You can always help if you like :)

-- 
/Jacob Carlborg
Dec 04 2013
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 4 December 2013 08:28, Jacob Carlborg <doob me.com> wrote:

 On 2013-12-03 17:55, Manu wrote:


 C++ support in D is 'not complete', but what's there now is still very
 important and not considered a bad partial feature to have.
 I'd imagine that likewise, if the 'core' of Obj-C support is solid, then
 maybe it's worth it in the same sense?
 OSX and iOS are 2 of the most popular platforms on earth. The mobile
 space is probably the most important prospective target for D.
 I can't comment on the state it's in. But if what's there is solid and
 useful like the current C++ support, then it's an important start...?



 I agree but Michel has a point as well. Walter, I think it was, has also
 said that D will never have complete support for C++ because that will
 require to build in a C++ compiler in the D compiler. That's not something
 we would like to do.


What complete support?  All you really need is:
1) ABI compatibility when passing around basic types.... check [1]
2) ABI compatibility when passing around structs.... check [1]
3) C++ mangling when declaring functions/decls as extern(C++).... check
4) ABI compatibility with C++ classes.... check

[1] Oh wait... dmd has a problem...
https://d.puremagic.com/issues/show_bug.cgi?id=5570

Forget templates and everything else...
Dec 04 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-04 10:12, Iain Buclaw wrote:


 Forget templates and everything else...


Then it's not complete, just as I said.

-- 
/Jacob Carlborg
Dec 04 2013
parent reply Manu <turkeyman gmail.com> writes:
On 4 December 2013 19:24, Jacob Carlborg <doob me.com> wrote:


 On 2013-12-04 10:12, Iain Buclaw wrote:

  Forget templates and everything else...


 Then it's not complete, just as I said.



In a sense. But I don't think the goal is to be able to write C++ code in
D. It's just to achieve binary compatibility.
Templates in C++ must be declared in header files, and are rarely present
in libs. You almost never link a template instance.
In the extremely rare event that you want to (I've never wanted to), it's
not inconceivable that an extern(C++) template with super-restrictive
template parameter rules could be made to mangle the same as C++, and then
it truly would be complete :)
I personally have no use for this though... but it's probably technically
possible.



 Dec 04 2013



  parent  "Paulo Pinto" <pjmlp progtools.org>  writes:


On Wednesday, 4 December 2013 at 09:31:06 UTC, Manu wrote:

 On 4 December 2013 19:24, Jacob Carlborg <doob me.com> wrote:


 On 2013-12-04 10:12, Iain Buclaw wrote:

  Forget templates and everything else...


 Then it's not complete, just as I said.



 In a sense. But I don't think the goal is to be able to write 
 C++ code in
 D. It's just to achieve binary compatibility.
 Templates in C++ must be declared in header files, and are 
 rarely present
 in libs. You almost never link a template instance.
 In the extremely rare event that you want to (I've never wanted 
 to), it's
 not inconceivable that an extern(C++) template with 
 super-restrictive
 template parameter rules could be made to mangle the same as 
 C++, and then
 it truly would be complete :)
 I personally have no use for this though... but it's probably 
 technically
 possible.


In Windows you have COM and now WinRT as a C++ ABI of some sort,
what about all the other platforms?

--
Paulo



 Dec 04 2013



prev sibling next sibling parent reply Manu <turkeyman gmail.com>  writes:


* ARC
* rvalue -> ref
* virtual-by-default
* GC improvements
* AA fixes


On 29 November 2013 07:01, Fra <Fra b.it> wrote:


 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?





 Nov 29 2013



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/29/13 5:43 AM, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


These are good themes but a conversation with one of the bountysource 
founders revealed to me that smaller, precise tasks for moderate amounts 
tend to do better than large projects that are only partially specified, 
even for large amounts.

We should break each of these down into bite-sized bugzilla issues.


Andrei



 Nov 29 2013



 next sibling parent  Manu <turkeyman gmail.com>  writes:


On 30 November 2013 01:23, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 11/29/13 5:43 AM, Manu wrote:


 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 These are good themes but a conversation with one of the bountysource
 founders revealed to me that smaller, precise tasks for moderate amounts
 tend to do better than large projects that are only partially specified,
 even for large amounts.

 We should break each of these down into bite-sized bugzilla issues.



Sure, any tasks that lead towards those goals are within my interest :)



 Nov 29 2013



prev sibling next sibling parent reply "Nick" <nmsmith65 gmail.com>  writes:


On Friday, 29 November 2013 at 15:23:13 UTC, Andrei Alexandrescu 
wrote:

 On 11/29/13 5:43 AM, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 These are good themes but a conversation with one of the 
 bountysource founders revealed to me that smaller, precise 
 tasks for moderate amounts tend to do better than large 
 projects that are only partially specified, even for large 
 amounts.

 We should break each of these down into bite-sized bugzilla 
 issues.


 Andrei


A bite-sized GC-related improvement is the  nogc attribute I've 
been craving for for quite some time. See: 
https://d.puremagic.com/issues/show_bug.cgi?id=5219

If I had money, I'd be putting it on this for sure. For system 
and game programmers it's a godsend, and it will put some C++ 
fanatics at ease with D's GC. With this feature I can protect the 
critical sections of my code with a firm guarantee that I won't 
see any unexpected activity from the GC.



 Nov 29 2013



 next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org>  writes:


On Nov 30, 2013 3:01 AM, "Nick" <nmsmith65 gmail.com> wrote:

 On Friday, 29 November 2013 at 15:23:13 UTC, Andrei Alexandrescu wrote:

 On 11/29/13 5:43 AM, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes



 These are good themes but a conversation with one of the bountysource




founders revealed to me that smaller, precise tasks for moderate amounts
tend to do better than large projects that are only partially specified,
even for large amounts.

 We should break each of these down into bite-sized bugzilla issues.


 Andrei



 A bite-sized GC-related improvement is the  nogc attribute I've been


craving for for quite some time. See:
https://d.puremagic.com/issues/show_bug.cgi?id=5219

 If I had money, I'd be putting it on this for sure. For system and game


programmers it's a godsend, and it will put some C++ fanatics at ease with
D's GC. With this feature I can protect the critical sections of my code
with a firm guarantee that I won't see any unexpected activity from the GC.

But how do you expect this to be implemented? Implicitly putting
GC.disable/GC.enable at the prologue / epilogue of a function?

Regards
-- 
Iain Buclaw

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



 Nov 30 2013



 next sibling parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Iain Buclaw:


 But how do you expect this to be implemented? Implicitly putting
 GC.disable/GC.enable at the prologue / epilogue of a function?


The point of annotations like  nogc or  noheap is not to disable 
the GC, but to statically disallow its usage transitively inside 
a function.

Bye,
bearophile



 Nov 30 2013



  parent reply Iain Buclaw <ibuclaw gdcproject.org>  writes:


On Nov 30, 2013 9:30 AM, "bearophile" <bearophileHUGS lycos.com> wrote:

 Iain Buclaw:



 But how do you expect this to be implemented? Implicitly putting
 GC.disable/GC.enable at the prologue / epilogue of a function?



 The point of annotations like  nogc or  noheap is not to disable the GC,


but to statically disallow its usage transitively inside a function.


Ok,  but what you describe is a different meaning to "no unexpected
activity from the GC in critical sections". I'll have to double check, but
do we still have a sort of global lock system in the GC for handling
multiple threads?

Regards
-- 
Iain Buclaw

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



 Nov 30 2013



  parent  "Nick" <nmsmith65 gmail.com>  writes:


On Saturday, 30 November 2013 at 11:33:06 UTC, Iain Buclaw wrote:

 On Nov 30, 2013 9:30 AM, "bearophile" 
 <bearophileHUGS lycos.com> wrote:

 The point of annotations like  nogc or  noheap is not to 
 disable the GC,


 but to statically disallow its usage transitively inside a 
 function.


 Ok,  but what you describe is a different meaning to "no 
 unexpected
 activity from the GC in critical sections". I'll have to double 
 check, but
 do we still have a sort of global lock system in the GC for 
 handling
 multiple threads?

 Regards


Ah, yes. When we have multiple threads running  nogc won't 
guarantee "no unexpected activity" alone, that is true. It can 
however, be combined with the non-suspendable threads feature 
that was proposed a few months ago here:
https://github.com/D-Programming-Language/druntime/pull/493
I would think it would be possible to force a non-suspendable 
thread to accept only a  nogc function as an entry point, too, if 
the thread's suspendability is fixed at creation.

These two enhancements plus DIP46 would together give D 
programmers some serious freedom with respect to working with the 
GC. Not only would it greatly simplify GC-free programming, but 
it would allow for (trustworthy) hybrid GC/manual memory 
management for applications which need to have total control over 
only specific sections of code or specific threads.



 Nov 30 2013



prev sibling  parent  "Nick" <nmsmith65 gmail.com>  writes:


On Saturday, 30 November 2013 at 08:42:11 UTC, Iain Buclaw wrote:

 But how do you expect this to be implemented? Implicitly putting
 GC.disable/GC.enable at the prologue / epilogue of a function?


The purpose of  nogc is not to prevent the GC from running when 
you make an allocation, it's to have compile-time assurance that 
the function (and any other functions it calls) won't set off any 
GC allocations in the first place. It should work the same way as 
 nothrow which guarantees a function won't throw an exception.



 Nov 30 2013



prev sibling  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


On Saturday, 30 November 2013 at 02:57:54 UTC, Nick wrote:

 On Friday, 29 November 2013 at 15:23:13 UTC, Andrei 
 Alexandrescu wrote:

 On 11/29/13 5:43 AM, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 These are good themes but a conversation with one of the 
 bountysource founders revealed to me that smaller, precise 
 tasks for moderate amounts tend to do better than large 
 projects that are only partially specified, even for large 
 amounts.

 We should break each of these down into bite-sized bugzilla 
 issues.


 Andrei


 A bite-sized GC-related improvement is the  nogc attribute I've 
 been craving for for quite some time. See: 
 https://d.puremagic.com/issues/show_bug.cgi?id=5219

 If I had money, I'd be putting it on this for sure. For system 
 and game programmers it's a godsend, and it will put some C++ 
 fanatics at ease with D's GC. With this feature I can protect 
 the critical sections of my code with a firm guarantee that I 
 won't see any unexpected activity from the GC.


DIP46 can help:
http://wiki.dlang.org/DIP46

Quote:
A further observation is that class GC has virtual functions in 
it. This opens up the possibility of doing a gc_push() with a 
different GC. Two possibilities come to mind:
1. Allocate-but-never-free, like DMD does. This would be very 
fast.
2. Assert-on-any-allocation, used for code that wants to be 
"nogc". This avoids the complexity of adding a "nogc" attribute 
to D. More discussion of "nogc": 
https://github.com/D-Programming-Language/druntime/pull/493



 Nov 30 2013



  parent  "Nick" <nmsmith65 gmail.com>  writes:


On Saturday, 30 November 2013 at 09:28:54 UTC, Namespace wrote:

 DIP46 can help:
 http://wiki.dlang.org/DIP46

 Quote:
 A further observation is that class GC has virtual functions in 
 it. This opens up the possibility of doing a gc_push() with a 
 different GC. Two possibilities come to mind:
 1. Allocate-but-never-free, like DMD does. This would be very 
 fast.
 2. Assert-on-any-allocation, used for code that wants to be 
 "nogc". This avoids the complexity of adding a "nogc" attribute 
 to D. More discussion of "nogc": 
 https://github.com/D-Programming-Language/druntime/pull/493


While having the ability to create 'tossable' regions of 
garbage-collected memory would be fantastic (I would really love 
to see that implemented), it does not completely solve the 
problem that  nogc (and  noheap) tries to solve. The point of 
 nogc is to have the compiler check for you that you didn't 
accidentally make allocations. It works on the presumption that 
you were trying to write allocation-free code. The 
assert-on-allocation idea from DIP46 won't achieve this either, 
as it leaves it to chance whether or not the execution of your 
code will reach an allocating call. There's no guarantee there.



 Nov 30 2013



prev sibling  parent reply "Jason den Dulk" <public2 jasondendulk.com>  writes:


On Friday, 29 November 2013 at 15:23:13 UTC, Andrei Alexandrescu 
wrote:

 On 11/29/13 5:43 AM, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 These are good themes but a conversation with one of the 
 bountysource founders revealed to me that smaller, precise 
 tasks for moderate amounts tend to do better than large 
 projects that are only partially specified, even for large 
 amounts.


That's because BountySource is only suited to bite-sized tasks. 
It is not capable of supporting large, complex projects.

As an analogy, BountySource may be great to get potholes filled, 
but incapable of getting a whole motorway or public transport 
network developed.


 We should break each of these down into bite-sized bugzilla 
 issues.


Instead of re-organising the project to suit the model of 
third-party website services, the D community needs to recognise 
that H. S. Teoh is right. The project needs an organised team of 
full time developers complete with team leadership and project 
management.

Regards
Jason



 Nov 30 2013



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/30/13 2:12 AM, Jason den Dulk wrote:

 On Friday, 29 November 2013 at 15:23:13 UTC, Andrei Alexandrescu wrote:

 These are good themes but a conversation with one of the bountysource
 founders revealed to me that smaller, precise tasks for moderate
 amounts tend to do better than large projects that are only partially
 specified, even for large amounts.


 That's because BountySource is only suited to bite-sized tasks. It is
 not capable of supporting large, complex projects.

 As an analogy, BountySource may be great to get potholes filled, but
 incapable of getting a whole motorway or public transport network
 developed.


It's a reasonable speculation to make, but without evidence it's only 
this - speculation. What experience are you drawing from?

One reason the bountysource founder mentioned was that large tasks tend 
to be insufficiently specified, which creates trouble (the worker claim 
task has been completed but the payer disagrees etc).


 We should break each of these down into bite-sized bugzilla issues.


 Instead of re-organising the project to suit the model of third-party
 website services, the D community needs to recognise that H. S. Teoh is
 right. The project needs an organised team of full time developers
 complete with team leadership and project management.


Totally. We're just missing the funds...


Andrei



 Nov 30 2013



  parent reply "Jason den Dulk" <public2 jasondendulk.com>  writes:


On Saturday, 30 November 2013 at 11:37:24 UTC, Andrei 
Alexandrescu wrote:

 On 11/30/13 2:12 AM, Jason den Dulk wrote:

 Instead of re-organising the project to suit the model of 
 third-party
 website services, the D community needs to recognise that H. 
 S. Teoh is
 right. The project needs an organised team of full time 
 developers
 complete with team leadership and project management.


 Totally. We're just missing the funds...


Not to criticise your current efforts, but might I suggest you 
shift some emphasis to obtaining sponsorship? I may be wrong, but 
it appears that this is something D seriously lacks. All major 
open source projects have financial backing. Organisations like 
the Linux Foundation, the Mozilla Foundation, the Apache 
Foundation and others exist in part to raise money for the 
projects they look after. If D has serious aspirations of "making 
it", it should have the same.

Regards
Jason



 Nov 30 2013



  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Sat, Nov 30, 2013 at 02:39:10PM +0100, Jason den Dulk wrote:

 On Saturday, 30 November 2013 at 11:37:24 UTC, Andrei Alexandrescu
 wrote:

On 11/30/13 2:12 AM, Jason den Dulk wrote:

Instead of re-organising the project to suit the model of
third-party website services, the D community needs to recognise
that H. S.  Teoh is right. The project needs an organised team of
full time developers complete with team leadership and project
management.


Totally. We're just missing the funds...


 
 Not to criticise your current efforts, but might I suggest you shift
 some emphasis to obtaining sponsorship? I may be wrong, but it
 appears that this is something D seriously lacks. All major open
 source projects have financial backing. Organisations like the Linux
 Foundation, the Mozilla Foundation, the Apache Foundation and others
 exist in part to raise money for the projects they look after. If D
 has serious aspirations of "making it", it should have the same.


[...]

Seeing how much we raised for DConf last year through kickstarter, I
wonder if it might be possible to use kickstarter to raise funds for
hiring a team of developers to work full-time on D?


T

-- 
Caffeine underflow. Brain dumped.



 Nov 30 2013



 next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Saturday, 30 November 2013 at 15:22:13 UTC, H. S. Teoh wrote:

 Seeing how much we raised for DConf last year through 
 kickstarter, I wonder if it might be possible to use
 kickstarter to raise funds for hiring a team of developers
 to work full-time on D?


Aye, And since D rox it might not even be terribly expensive - 
I'd be willing to devote half-time to D (~15-25 hours / week) at 
the community's direction for $1,500 / month, give or take. (And 
that's actually enough to cover my bills, so a good chunk of that 
other half time might also go to D! But I can't devote full time 
at a discount.)



 Nov 30 2013



prev sibling  parent reply "Nick" <nmsmith65 gmail.com>  writes:


On Saturday, 30 November 2013 at 15:22:13 UTC, H. S. Teoh wrote:

 Seeing how much we raised for DConf last year through 
 kickstarter, I
 wonder if it might be possible to use kickstarter to raise 
 funds for
 hiring a team of developers to work full-time on D?


Even as a student, I'd be happy to throw money at D, if someone 
could give me a good reason to. I really want to see D succeed. 
I'm just not rich enough to be putting $20 bounties up on 
(multiple) individual bugs.

I like the idea of a Kickstarter, if it could be done 
effectively. It would need some planning out.



 Nov 30 2013



  parent reply "Jason den Dulk" <public2 jasondendulk.com>  writes:


On Saturday, 30 November 2013 at 23:13:05 UTC, Nick wrote:

 On Saturday, 30 November 2013 at 15:22:13 UTC, H. S. Teoh wrote:

 Seeing how much we raised for DConf last year through 
 kickstarter, I
 wonder if it might be possible to use kickstarter to raise 
 funds for
 hiring a team of developers to work full-time on D?


 Even as a student, I'd be happy to throw money at D, if someone 
 could give me a good reason to. I really want to see D succeed. 
 I'm just not rich enough to be putting $20 bounties up on 
 (multiple) individual bugs.

 I like the idea of a Kickstarter, if it could be done 
 effectively. It would need some planning out.


The D decision makers would have to decide what would work best, 
but setting up a non-profit organisation, and using that to raise 
funds is the standard model, and is known to work. I can 
contribute a small amount each month, and I'm sure other D 
enthusiasts could do the same. 170 sponsors contributing an 
average of $50 a month would pay for 1 full time developer and 
$50/hr at 38 hrs/wk.

As for a good reason, the success of D is that reason. As I 
mentioned in an earlier post, all successful projects (AFAIK) 
have financial backing, and projects that rely purely on 
volunteer efforts tend to die of asphyxiation.

Regards
Jason



 Nov 30 2013



  parent reply Manu <turkeyman gmail.com>  writes:


On 1 December 2013 10:54, Jason den Dulk <public2 jasondendulk.com> wrote:


 On Saturday, 30 November 2013 at 23:13:05 UTC, Nick wrote:


 On Saturday, 30 November 2013 at 15:22:13 UTC, H. S. Teoh wrote:


 Seeing how much we raised for DConf last year through kickstarter, I
 wonder if it might be possible to use kickstarter to raise funds for
 hiring a team of developers to work full-time on D?


 Even as a student, I'd be happy to throw money at D, if someone could
 give me a good reason to. I really want to see D succeed. I'm just not rich
 enough to be putting $20 bounties up on (multiple) individual bugs.

 I like the idea of a Kickstarter, if it could be done effectively. It
 would need some planning out.


 The D decision makers would have to decide what would work best, but
 setting up a non-profit organisation, and using that to raise funds is the
 standard model, and is known to work. I can contribute a small amount each
 month, and I'm sure other D enthusiasts could do the same. 170 sponsors
 contributing an average of $50 a month would pay for 1 full time developer
 and $50/hr at 38 hrs/wk.


I wonder what that would do to the existing contributors though?
I have a suspicion that guys like Kenji and Daniel Murphy already spend
something close to 'full time' hours on D voluntarily.



 Nov 30 2013



  parent  "CJS" <Prometheus85 hotmail.com>  writes:


 I wonder what that would do to the existing contributors though?
 I have a suspicion that guys like Kenji and Daniel Murphy 
 already spend
 something close to 'full time' hours on D voluntarily.


An interesting comparison is some of the projects in the 
scientific python ecosystem. Important stuff that a lot of 
scientists, both in academia and industry, use on a daily basis. 
For a long time they've struggled with how to pay coders to deal 
with maintenance/compatibility of important foundational code 
bases. This is a difficult problem since the users are largely 
python programmers but, for example, some of the packages are 
mostly low-level C extension modules with some code generation 
tools (so you need to know C, the C-Python API, and how the 
packages generate C code) and additionally specialized 
open-source libraries in C and Fortran. Other packages are 
friendlier, but to get speed they're still in cython, which 
requires some C knowledge.

I think matplotlib, scikit-learn, ipython, and numpy/scipy get 
the most money/love-and-attention. And each has their own core 
contributor groups and money pools. Recently it's gotten more 
organized with the NumFocus (http://numfocus.org/) non-profit. 
It's an umbrella organization for supporting scientific python 
efforts across the spectrum of available libraries. I'm sure 
anyone who was interested in doing something similar for D could 
ask some of the NumFocus folks how they setup their organization, 
and then the D community could similarly have a focal point for 
gathering funds which could be used for various maintenance and 
enhancements in the D ecosystem.

I think the current state involves a fair amount of funding for 
high contributors, especially student contributors (who are 
usually in need of funds) to take anywhere between a quarter and 
a year to just work on maintenance issues, bug-fixing, and some 
high priority enhancements.



 Nov 30 2013



prev sibling  parent reply "Dejan Lekic" <dejan.lekic gmail.com>  writes:


On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:


 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?




I hope virtual-by-default never gets approved. I read DIP51 and 
quite frankly I am not convinced at all. It is basically "I do 
not want to put final in front of my methods. Well, I do not want 
to put virtual in front of my methods... But this is perhaps 
something for another discussion...



 Dec 02 2013



 next sibling parent  Iain Buclaw <ibuclaw gdcproject.org>  writes:


On 2 December 2013 09:33, Dejan Lekic <dejan.lekic gmail.com> wrote:

 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:


 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?





 I hope virtual-by-default never gets approved. I read DIP51 and quite
 frankly I am not convinced at all. It is basically "I do not want to put
 final in front of my methods. Well, I do not want to put virtual in front of
 my methods... But this is perhaps something for another discussion...


Come to Dconf 2014 and we'll have another round of talks over beer. :-)



 Dec 02 2013



prev sibling next sibling parent reply "Namespace" <rswhite4 googlemail.com>  writes:


On Monday, 2 December 2013 at 09:33:02 UTC, Dejan Lekic wrote:

 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:


 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?




 I hope virtual-by-default never gets approved. I read DIP51 and 
 quite frankly I am not convinced at all. It is basically "I do 
 not want to put final in front of my methods. Well, I do not 
 want to put virtual in front of my methods... But this is 
 perhaps something for another discussion...


final by default is far more efficient than virtual by default. 
So final by default is preferable. And (AFAIK) it is already 
approved by Walter: 
http://forum.dlang.org/thread/yzsqwejxqlnzryhrkfuq forum.dlang.org?page=28#post-koqkhc:244nn:241:40digitalmars.com

So let us thank Manu and let us hope it comes with 2.065!



 Dec 02 2013



 next sibling parent  =?UTF-8?B?U2ltZW4gS2rDpnLDpXM=?= <simen.kjaras gmail.com>  writes:


On 2013-12-02 12:14, Namespace wrote:

 On Monday, 2 December 2013 at 09:33:02 UTC, Dejan Lekic wrote:

 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:


 Personally I would love to see this old issue finally
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?




 I hope virtual-by-default never gets approved. I read DIP51 and quite
 frankly I am not convinced at all. It is basically "I do not want to
 put final in front of my methods. Well, I do not want to put virtual
 in front of my methods... But this is perhaps something for another
 discussion...


 final by default is far more efficient than virtual by default. So final
 by default is preferable.


Also, while a JIT may be able to devirtualize some functions, D 
compilers do not have that privilege.



 So let us thank Manu and let us hope it comes with 2.065!


Indeed.

--
   Simen



 Dec 02 2013



prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Monday, 2 December 2013 at 11:14:58 UTC, Namespace wrote:

 final by default is far more efficient than virtual by default. 
 So final by default is preferable.


The *whole point* of classes is to have virtual functions. If you 
don't want them, don't write class methods! Use structs or UFCS 
instead.

Perhaps a counter argument is that the whole point of 
*interfaces* is virtual functions, and classes just implement 
them and thus ought to be final, if you want virtual stuff go 
through the interface.

But, regardless, I think the real problem here isn't virtual by 
default. The real problem is there's things written as class 
methods that really shouldn't me methods at all. The ideal 
"method" is actually a UFCS function that operates on the 
interface, without touching any private state at all. Next best 
is a  UFCS function that works on the class and needs private 
state.

The only time it, at least ideally speaking, should be in the 
class itself is if it has something to do with implementing 
interfaces. And that means virtual generally makes sense.



 Dec 02 2013



  parent  "Dejan Lekic" <dejan.lekic gmail.com>  writes:


On Monday, 2 December 2013 at 13:51:39 UTC, Adam D. Ruppe wrote:


 The *whole point* of classes is to have virtual functions. If 
 you don't want them, don't write class methods! Use structs or 
 UFCS instead.


+1
I can only agree...



 Dec 03 2013



prev sibling  parent  Iain Buclaw <ibuclaw gdcproject.org>  writes:


On 2 December 2013 12:17, Simen Kjærås <simen.kjaras gmail.com> wrote:

 On 2013-12-02 12:14, Namespace wrote:

 On Monday, 2 December 2013 at 09:33:02 UTC, Dejan Lekic wrote:

 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:

 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:


 Personally I would love to see this old issue finally
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?





 I hope virtual-by-default never gets approved. I read DIP51 and quite
 frankly I am not convinced at all. It is basically "I do not want to
 put final in front of my methods. Well, I do not want to put virtual
 in front of my methods... But this is perhaps something for another
 discussion...


 final by default is far more efficient than virtual by default. So final
 by default is preferable.



 Also, while a JIT may be able to devirtualize some functions, D compilers do
 not have that privilege.


There's actually some development being brewed up in GCC (and I've
heard ushers from LLVM too) around the ability to devirtualise
functions at compile time if it is able to prove that there is only
one place where the call can go based off the information built up
about type inheritance and basetypes.



 Dec 02 2013



prev sibling  parent reply Manu <turkeyman gmail.com>  writes:


On 2 December 2013 19:33, Dejan Lekic <dejan.lekic gmail.com> wrote:


 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:


 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:

  Personally I would love to see this old issue finally implemented/fixed:

 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?




 I hope virtual-by-default never gets approved. I read DIP51 and quite
 frankly I am not convinced at all. It is basically "I do not want to put
 final in front of my methods. Well, I do not want to put virtual in front
 of my methods... But this is perhaps something for another discussion...


There's been endless discussions on the topic. There was a link to a thread
with loads of discussion.
The problem is that virtual is irrevocable. It can't be removed without
breaking the API, which means it's not possible to optimise a library in
that way at any time after it has already been released to the wild. The
converse is not true.
It has also been agreed that there is very little the compiler/optimiser
can do to help.
It's a dangerous default, it's got absolutely nothing to do with "I don't
want to type final" as you helpfully simplified it. You can type 'virtual:'
at the top, and you're set. Again, the converse doesn't stand, you can't
practically type 'final:' at the top since there will inevitable by SOME
virtual methods.

We can spin off another thread if you like, or you can read through the old
ones. I don't think it's going to go any further than the other threads
already did.



 Dec 02 2013



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/2/13 4:19 AM, Manu wrote:

 The problem is that virtual is irrevocable. It can't be removed without
 breaking the API


Here we go again. No, that's not the problem. A similar issue goes about 
final.


, which means it's not possible to optimise a library in
 that way at any time after it has already been released to the wild. The
 converse is not true.


Conversely final makes it impossible tweak behavior after the library 
has been released in the wild. You could reasonably argue that you care 
more about performance optimization than tweaking behavior.


 It has also been agreed that there is very little the compiler/optimiser
 can do to help.


Same goes about "virtualizing" final.


 It's a dangerous default,


How is it "dangerous"?


 it's got absolutely nothing to do with "I
 don't want to type final" as you helpfully simplified it. You can type
 'virtual:' at the top, and you're set.


Can't _you_ type 'final:' at the top and be set? Why is it that, to 
paraphrase a recent crazy twitter flamewar (http://goo.gl/h9NMxK), your 
Thanksgiving is more important than everybody else's?


 Again, the converse doesn't
 stand, you can't practically type 'final:' at the top since there will
 inevitable by SOME virtual methods.


Group them before the final: or go through the trouble of typing final { 
... }.


 We can spin off another thread if you like, or you can read through the
 old ones. I don't think it's going to go any further than the other
 threads already did.


We'll see. If I learned anything from the past, is this has just restarted.


Andrei



 Dec 02 2013



 next sibling parent  =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu>  writes:


On Monday, 2 December 2013 at 22:43:44 UTC, Andrei Alexandrescu 
wrote:

 We'll see. If I learned anything from the past, is this has 
 just restarted.


I don't have a horse in this race, but I though that this had 
already been decided, to the satisfaction of Manu? Did anything 
change after the mentioned thread?



 Dec 02 2013



prev sibling  parent reply Manu <turkeyman gmail.com>  writes:


On 3 December 2013 08:43, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org

 wrote:



 On 12/2/13 4:19 AM, Manu wrote:


 The problem is that virtual is irrevocable. It can't be removed without
 breaking the API


 Here we go again. No, that's not the problem. A similar issue goes about
 final.



You can safely add virtual to a function where it wasn't previously present
without breaking code.


 , which means it's not possible to optimise a library in

 that way at any time after it has already been released to the wild. The
 converse is not true.


 Conversely final makes it impossible tweak behavior after the library has
 been released in the wild. You could reasonably argue that you care more
 about performance optimization than tweaking behavior.



If you're making the kind of library where you want everything to be
overridable, writing 'virtual:' at the top is easy. Do that, you're happy,
and your intentions are made explicit, and there's also no room for error.
It's nowhere near as simple approaching from the other angle, extremely
prone to human error, and if a mistake is made, it it's a breaking
change any time you want to fix it.


 It has also been agreed that there is very little the compiler/optimiser

 can do to help.


 Same goes about "virtualizing" final.



What?


 It's a dangerous default,


 How is it "dangerous"?



Because it's a breaking change. You can't add final after it's ever seen
the light of day. No code is fully optimal after revision 0.01b, people
always make mistakes, or react to feedback.
Library authors are always very apprehensive to make breaking changes to
their libs, so it's very hard to get things fixed.
It also requires bumping the major version with semantic versioning to make
performance tweaks, and library authors don't like to do that if they can
avoid it. It creates a situation where it's very hard to get fixes.


 it's got absolutely nothing to do with "I

 don't want to type final" as you helpfully simplified it. You can type
 'virtual:' at the top, and you're set.


 Can't _you_ type 'final:' at the top and be set? Why is it that, to
 paraphrase a recent crazy twitter flamewar (http://goo.gl/h9NMxK), your
 Thanksgiving is more important than everybody else's?



No. Classes have virtual functions, that's the point. So you have to micro
manage it.
There is not much sense in a class with 'final:', there is sense in a class
with 'virtual:', if you want to write your code that way, and the intention
is made explicit, which is rarely a bad thing.

With virtual-by-default, there is strong tendency to leave it in it's
default state (everything virtual) because it 'just works', and there's no
warnings or compile errors to remind you what you've committed to.
What I mean is, the author of the code never deliberately made a _choice_,
but they have (probably unknowingly) made a strong commitment. If you're a
library author, you can't correct it later without bumping the major
version, and risk breaking client code.

I don't have thanksgiving; you're welcome to it.
I don't see the parallel, I don't consider this a flamewar.


 Again, the converse doesn't

 stand, you can't practically type 'final:' at the top since there will
 inevitable by SOME virtual methods.


 Group them before the final: or go through the trouble of typing final {
 ... }.



Just type 'virtual:' at the top. Much simpler.



 Dec 02 2013



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/2/13 5:30 PM, Manu wrote:

 On 3 December 2013 08:43, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org <mailto:SeeWebsiteForEmail erdani.org>>
 wrote:

     On 12/2/13 4:19 AM, Manu wrote:

         The problem is that virtual is irrevocable. It can't be removed
         without
         breaking the API


     Here we go again. No, that's not the problem. A similar issue goes
     about final.


 You can safely add virtual to a function where it wasn't previously
 present without breaking code.


If not breaking code is something of value to you, you should appreciate 
that final-by-default would break a bunch of code.


Andrei



 Dec 02 2013



  parent reply Manu <turkeyman gmail.com>  writes:


On 3 December 2013 13:14, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org

 wrote:



 On 12/2/13 5:30 PM, Manu wrote:


 On 3 December 2013 08:43, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org <mailto:SeeWebsiteForEmail erdani.org>>

 wrote:

     On 12/2/13 4:19 AM, Manu wrote:

         The problem is that virtual is irrevocable. It can't be removed
         without
         breaking the API


     Here we go again. No, that's not the problem. A similar issue goes
     about final.


 You can safely add virtual to a function where it wasn't previously
 present without breaking code.


 If not breaking code is something of value to you, you should appreciate
 that final-by-default would break a bunch of code.



Only once upon changing the default, and with the opportunity for a
controlled deprecation path which clearly communicates with users.
Otherwise this remains an ongoing issue forever.



 Dec 02 2013



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


On Tuesday, 3 December 2013 at 04:33:07 UTC, Manu wrote:

 On 3 December 2013 13:14, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org

 wrote:



 On 12/2/13 5:30 PM, Manu wrote:


 On 3 December 2013 08:43, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org 
 <mailto:SeeWebsiteForEmail erdani.org>>

 wrote:

     On 12/2/13 4:19 AM, Manu wrote:

         The problem is that virtual is irrevocable. It can't 
 be removed
         without
         breaking the API


     Here we go again. No, that's not the problem. A similar 
 issue goes
     about final.


 You can safely add virtual to a function where it wasn't 
 previously
 present without breaking code.


 If not breaking code is something of value to you, you should 
 appreciate
 that final-by-default would break a bunch of code.



 Only once upon changing the default, and with the opportunity 
 for a
 controlled deprecation path which clearly communicates with 
 users.
 Otherwise this remains an ongoing issue forever.


Sorry but again we stray from the topic (Seems to happen in this 
forum almost always).
The first step is to introduce a virtual keyword to avoid the 
"grouping" of your methods in final blocks. If the next step 
comes and change from virtual by default to final by default is 
another matter and should be discussed somewhere else after 
virtual was introduced.



 Dec 03 2013



  parent  "Daniel Murphy" <yebblies nospamgmail.com>  writes:


"Namespace" <rswhite4 googlemail.com> wrote in message 
news:ixafkrtzclqsrvtsovut forum.dlang.org...

 The first step is to introduce a virtual keyword to avoid the "grouping" 
 of your methods in final blocks. If the next step comes and change from 
 virtual by default to final by default is another matter and should be 
 discussed somewhere else after virtual was introduced.


Yeah.  https://github.com/D-Programming-Language/dmd/pull/2895 



 Dec 03 2013



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2013-12-03 02:30, Manu wrote:


 With virtual-by-default, there is strong tendency to leave it in it's
 default state (everything virtual) because it 'just works', and there's
 no warnings or compile errors to remind you what you've committed to.


I showed how you can get "compile errors" for this with some UDA's, CTFE 
and a minor modification to druntime. I know that's not optimal, but it 
has to be better than nothing at all.

-- 
/Jacob Carlborg



 Dec 02 2013



prev sibling  parent reply "Dejan Lekic" <dejan.lekic gmail.com>  writes:


On Monday, 2 December 2013 at 12:19:12 UTC, Manu wrote:

 On 2 December 2013 19:33, Dejan Lekic <dejan.lekic gmail.com> 
 wrote:


 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:


 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:

  Personally I would love to see this old issue finally 
 implemented/fixed:

 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?




 I hope virtual-by-default never gets approved. I read DIP51 
 and quite
 frankly I am not convinced at all. It is basically "I do not 
 want to put
 final in front of my methods. Well, I do not want to put 
 virtual in front
 of my methods... But this is perhaps something for another 
 discussion...


 There's been endless discussions on the topic. There was a link 
 to a thread
 with loads of discussion.
 The problem is that virtual is irrevocable. It can't be removed 
 without
 breaking the API, which means it's not possible to optimise a 
 library in
 that way at any time after it has already been released to the 
 wild. The
 converse is not true.
 It has also been agreed that there is very little the 
 compiler/optimiser
 can do to help.
 It's a dangerous default, it's got absolutely nothing to do 
 with "I don't
 want to type final" as you helpfully simplified it. You can 
 type 'virtual:'
 at the top, and you're set. Again, the converse doesn't stand, 
 you can't
 practically type 'final:' at the top since there will 
 inevitable by SOME
 virtual methods.

 We can spin off another thread if you like, or you can read 
 through the old
 ones. I don't think it's going to go any further than the other 
 threads
 already did.


No offense, so far I haven's seen a GOOD reason for making final 
to be the default. Your DIP51 is, to put mildly, pretty 
subjective. You care about performance, I get it, but I do not. 
Developers like me use classes exactly because methods are 
virtual. In my career I *rarely* had situation that I knew ahead 
my class method is *definitely* final.

You say "dangerous". - I am quite sure people are aware of those 
"dangers".
You say "people agreed". Who agreed? :)
You say there have been endless discussions. Yes, I remember them 
but I do not remember anything conclusive after reading them.

This is *a radical change*, and instead of "(unknown) people 
agreed" the community deserves a better explanation why are we 
switching to final as default storage class...



 Dec 03 2013



 next sibling parent  "Namespace" <rswhite4 googlemail.com>  writes:


On Tuesday, 3 December 2013 at 18:10:43 UTC, Dejan Lekic wrote:

 On Monday, 2 December 2013 at 12:19:12 UTC, Manu wrote:

 On 2 December 2013 19:33, Dejan Lekic <dejan.lekic gmail.com> 
 wrote:


 On Friday, 29 November 2013 at 13:44:10 UTC, Manu wrote:


 * ARC
 * rvalue -> ref
 * virtual-by-default
 * GC improvements
 * AA fixes


 On 29 November 2013 07:01, Fra <Fra b.it> wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:

 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?




 I hope virtual-by-default never gets approved. I read DIP51 
 and quite
 frankly I am not convinced at all. It is basically "I do not 
 want to put
 final in front of my methods. Well, I do not want to put 
 virtual in front
 of my methods... But this is perhaps something for another 
 discussion...


 There's been endless discussions on the topic. There was a 
 link to a thread
 with loads of discussion.
 The problem is that virtual is irrevocable. It can't be 
 removed without
 breaking the API, which means it's not possible to optimise a 
 library in
 that way at any time after it has already been released to the 
 wild. The
 converse is not true.
 It has also been agreed that there is very little the 
 compiler/optimiser
 can do to help.
 It's a dangerous default, it's got absolutely nothing to do 
 with "I don't
 want to type final" as you helpfully simplified it. You can 
 type 'virtual:'
 at the top, and you're set. Again, the converse doesn't stand, 
 you can't
 practically type 'final:' at the top since there will 
 inevitable by SOME
 virtual methods.

 We can spin off another thread if you like, or you can read 
 through the old
 ones. I don't think it's going to go any further than the 
 other threads
 already did.


 No offense, so far I haven's seen a GOOD reason for making 
 final to be the default. Your DIP51 is, to put mildly, pretty 
 subjective. You care about performance, I get it, but I do not.


Just because you do not care, it does not mean that it does not 
bother the majority. ;) But back to the topic.



 Dec 03 2013



prev sibling next sibling parent  "Namespace" <rswhite4 googlemail.com>  writes:


Ok one more thing: Are you also against the introducing of the 
virtual keyword without introducing final by default?



 Dec 03 2013



prev sibling next sibling parent  =?UTF-8?B?U2ltZW4gS2rDpnLDpXM=?= <simen.kjaras gmail.com>  writes:


On 03.12.2013 19:10, Dejan Lekic wrote:


 No offense, so far I haven's seen a GOOD reason for making final to be
 the default.


The best reason I've got is that making something final is a breaking 
change, while making something virtual is not. That means:

(with virtual by default) If you write a library and forget to make a 
function final, you're stuck with it.

(with final by default) If you write a library and forget to make a 
function virtual, you just fix it.



 In my career I *rarely* had situation that I knew ahead my class method
 is *definitely* final.


Of course not. But see above.



 You say "dangerous". - I am quite sure people are aware of those "dangers".


I am absolutely certain some people are not aware of the dangers.

-- 
   Simen



 Dec 03 2013



prev sibling  parent reply "Kapps" <opantm2+spam gmail.com>  writes:


On Tuesday, 3 December 2013 at 18:10:43 UTC, Dejan Lekic wrote:

 This is *a radical change*, and instead of "(unknown) people 
 agreed" the community deserves a better explanation why are we 
 switching to final as default storage class...


Let me state in advance that I believe that in most situations 
people will leave the default option unless they have reason to 
(that is, stick with the virtual unless they have reason to mark 
something final, or stick with final unless they have reason to 
mark something virtual). For virtual, there is often less reason 
to realize something should be final as things look like they 
work until much later. Forgetting to stick a 'final' in front of 
your function will never give you a compiler error. That being 
said, some pros / cons of virtual/final by default. Obviously 
heavily biased.

1) The most obvious reason is final has better performance. Some 
effort can be taken to reduce the impact of virtual methods but 
ultimately there will always be a performance hit. In a large 
program, this may not be too substantial a hit. I consider this 
the weakest argument for final-by-default, but others who attempt 
to deliver as efficient as possible code consider it very 
important.

2) A function that is virtual cannot be changed to be final 
without breaking existing code. If you are writing a library and 
have a virtual method which you wish to change to final, anyone 
using that library that overrides your method will have their 
code break and require substantial design changes if they were 
relying on simply being able to override your method. If a method 
was final and is changed to be virtual later on, no code will 
break unless the developer then decides to change it back to 
final afterwards.

3) Related to the above, if a method is not virtual there is 
nothing you can do about it. A method might be perfectly capable 
of being virtual without issues, yet if the developer forgot to 
mark it as 'virtual' you cannot override it even though it may be 
safe to do so.

4) If we assume that the statement about people sticking with the 
default is true (which I strongly believe it is, yet lack actual 
data for), final by default means more 'virtual' keywords being 
stuck everywhere. For a language that may already be considered 
to have too many modifiers to stick in front of your methods, 
this would add yet another one for many class methods.

5) Marking something virtual is a huge commitment and makes 
substantial guarantees about implementation details. A simple 
example is a property. Making a property virtual is a statement 
that you will never access the field behind the property 
(assuming there is one), as someone may have overridden the 
property to use a different backing field or a constant value. 
This is something that requires actual acknowledgement, yet 
virtual by default does not require you to think about this as 
it's automatically virtual. This is actually a mistake I catch 
myself making not infrequently.

A less obvious example is add vs addRange. If you implement a 
class to extend an existing collection yet add capabilities for 
storing length by overriding add/remove to increase/decrease 
length, should you override addRange and add range.length? What 
if something then overrides addRange for more efficient adding of 
multiple elements rather than calling add N times, or something 
that only sometimes calls add depending on the element type or 
state? These are considerations that require actual thought, and 
while simply adding a "virtual" keyword to them doesn't mean you 
thought about the implications, the very action of having to add 
this keyword makes it a conscious effort and so helps you 
consider the side-effects of adding it and what it means.


I don't understand how virtual-by-default is even considered for 
new languages. It provides slight convenience while being error 
prone. Yet breaking almost every single D program is a huge issue 
and stability is something that D is desperately trying to 
achieve. I'd like virtual by default, but it's a hard sell now. I 
wouldn't mind updating my code for this and I feel it better to 
do this sort of change now rather than later when more/larger 
code uses D, but it is still a substantial code break. If it was 
actually done it would need a transition flag or such to help the 
process (final by default normally, virtual by default with the 
transition flag), and likely a virtual keyword implemented well 
ahead of time so people could start making their changes early 
and gradually.



 Dec 03 2013



  parent reply Manu <turkeyman gmail.com>  writes:


On 4 December 2013 12:58, Kapps <opantm2+spam gmail.com> wrote:


 On Tuesday, 3 December 2013 at 18:10:43 UTC, Dejan Lekic wrote:


 This is *a radical change*, and instead of "(unknown) people agreed" the
 community deserves a better explanation why are we switching to final as
 default storage class...


 Let me state in advance that I believe that in most situations people will
 leave the default option unless they have reason to (that is, stick with
 the virtual unless they have reason to mark something final, or stick with
 final unless they have reason to mark something virtual). For virtual,
 there is often less reason to realize something should be final as things
 look like they work until much later. Forgetting to stick a 'final' in
 front of your function will never give you a compiler error. That being
 said, some pros / cons of virtual/final by default. Obviously heavily
 biased.

 1) The most obvious reason is final has better performance. Some effort
 can be taken to reduce the impact of virtual methods but ultimately there
 will always be a performance hit. In a large program, this may not be too
 substantial a hit. I consider this the weakest argument for
 final-by-default, but others who attempt to deliver as efficient as
 possible code consider it very important.


I think this has a tendency to be underestimated until it is a project
requirement. Consider that there may be any number of useful libraries
available - many of which didn't explicitly try to deliver the most
efficient possible code, by they are still useful libraries nonetheless -
but pervasive use of virtual may unintentionally inhibit their usage in
performance critical software.

This is not conjecture, I've run in to this professionally on many
occasions. And worse than C++, D has 1st class properties, which makes it
much more important a consideration than in C++.
What I'm proposing is simply that, with this change, it will not be a
hidden/unintentional cost, but the placement of the keyword one way or
another will result in library authors considering, even for just a moment,
the reality of the _choice_ they are making. It can't be default, or the
choice will be overlooked and the damage is done, since it can't be revoked.

Library authors are very apprehensive to make breaking changes to their API
and go bumping the major version of their software to fix an otherwise
trivial performance issue.


2) A function that is virtual cannot be changed to be final without

 breaking existing code. If you are writing a library and have a virtual
 method which you wish to change to final, anyone using that library that
 overrides your method will have their code break and require substantial
 design changes if they were relying on simply being able to override your
 method. If a method was final and is changed to be virtual later on, no
 code will break unless the developer then decides to change it back to
 final afterwards.

 3) Related to the above, if a method is not virtual there is nothing you
 can do about it. A method might be perfectly capable of being virtual
 without issues, yet if the developer forgot to mark it as 'virtual' you
 cannot override it even though it may be safe to do so.


You can change it easily (open source), or request the change (which
usually wouldn't be objected, since it's not a breaking change). And if
neither of those are to your taste, you can very easily wrap it as a last
resort; in D, 'alias this' makes wrapping things easier than ever. Those
aren't options when going the other direction, rather, there is no
option... you're simply screwed. And I have been on the receiving end of
this on many occasions in C++, and it sucks!
It will be much worse for D, since properties are more pervasive.


4) If we assume that the statement about people sticking with the default

 is true (which I strongly believe it is, yet lack actual data for), final
 by default means more 'virtual' keywords being stuck everywhere. For a
 language that may already be considered to have too many modifiers to stick
 in front of your methods, this would add yet another one for many class
 methods.


I have hard experience that shows that even when people know it's a
critical performance penalty and a project requirement, they STILL stick
with the default, either from habit, or ignorance/inexperience, or they
simply forget.

WRT adding additional modifiers, I'd make the argument that looking from
the other (current) perspective where virtual is default and you need to
explicitly mark functions final everywhere, you will end up with far more
'final' spam than you would with 'virtual' as you suggest.
If that's not the case, then it's likely the truth is that D libraries are
over-virtualised, and will suffer performance penalties as a result.

The majority of functions in most OOP classes are properties and trivial
accessors which should almost never be virtual. Imagine, making virtual
function calls to access trivial properties? They can't be inlined anymore;
inlining trivial accessors is one of the most important optimisations for
OOP that there is.
If people stick with the default, then D suffers severe performance

optimise the calls. And like you say, you (and I) agree that most people
will stick with the default in most cases unless they have good reason not
to (ie, a compile error).


5) Marking something virtual is a huge commitment and makes substantial

 guarantees about implementation details. A simple example is a property.
 Making a property virtual is a statement that you will never access the
 field behind the property (assuming there is one), as someone may have
 overridden the property to use a different backing field or a constant
 value. This is something that requires actual acknowledgement, yet virtual
 by default does not require you to think about this as it's automatically
 virtual. This is actually a mistake I catch myself making not infrequently.


Yes, another very important point that I have tried to make many times. I
support that it is important to acknowledge this commitment you have made.
It can't reasonably be a default commitment, since it has severe
performance and maintainability implications.


A less obvious example is add vs addRange. If you implement a class to

 extend an existing collection yet add capabilities for storing length by
 overriding add/remove to increase/decrease length, should you override
 addRange and add range.length? What if something then overrides addRange
 for more efficient adding of multiple elements rather than calling add N
 times, or something that only sometimes calls add depending on the element
 type or state? These are considerations that require actual thought, and
 while simply adding a "virtual" keyword to them doesn't mean you thought
 about the implications, the very action of having to add this keyword makes
 it a conscious effort and so helps you consider the side-effects of adding
 it and what it means.


+1 hundred :)


I don't understand how virtual-by-default is even considered for new

 languages. It provides slight convenience while being error prone. Yet
 breaking almost every single D program is a huge issue and stability is
 something that D is desperately trying to achieve. I'd like virtual by
 default, but it's a hard sell now. I wouldn't mind updating my code for
 this and I feel it better to do this sort of change now rather than later
 when more/larger code uses D, but it is still a substantial code break. If
 it was actually done it would need a transition flag or such to help the
 process (final by default normally, virtual by default with the transition
 flag), and likely a virtual keyword implemented well ahead of time so
 people could start making their changes early and gradually.


You mean you'd like virtual-by-default as you say (as is now), or you'd
like final-by-default at the cost of the transition?

There is a proposed transition process across a few releases which should
make the transition relatively painless, at least, it wouldn't be error
prone, since warnings/deprecation messages would assist the process.
1. 'virtual' keyword is introduced, 'override'-ing unattributed methods is
a warning.
2. it becomes deprecated, but you can still compile with -d.
3. it becomes an error, but surely you've already taken the opportunity to
update your software, right?



 Dec 03 2013



 next sibling parent reply "Kapps" <opantm2+spam gmail.com>  writes:


On Wednesday, 4 December 2013 at 07:00:58 UTC, Manu wrote:

 You mean you'd like virtual-by-default as you say (as is now), 
 or you'd
 like final-by-default at the cost of the transition?


Sorry, I meant to say I'd like final by default, but I can 
understand people being hesitant with the breakage required.


 There is a proposed transition process across a few releases 
 which should
 make the transition relatively painless, at least, it wouldn't 
 be error
 prone, since warnings/deprecation messages would assist the 
 process.
 1. 'virtual' keyword is introduced, 'override'-ing unattributed 
 methods is
 a warning.
 2. it becomes deprecated, but you can still compile with -d.
 3. it becomes an error, but surely you've already taken the 
 opportunity to
 update your software, right?


This transition also works well. It does mean that the 
performance benefits would not occur until step 3, but while 
giving time to transition it also immediately provides the safety 
benefits. Ideally it would even catch bugs in peoples code as 
they make the required changes to add virtual where needed. The 
only issue is that it pretty much guarantees that most libraries 
that make use of classes and are no longer maintained will fail 
to compile, but honestly, I don't know think many projects will 
compile anyways when using a compiler / Phobos version that's 
more than a year newer than when the library was last modified.



 Dec 03 2013



  parent reply Manu <turkeyman gmail.com>  writes:


On 4 December 2013 17:24, Kapps <opantm2+spam gmail.com> wrote:


 On Wednesday, 4 December 2013 at 07:00:58 UTC, Manu wrote:


 There is a proposed transition process across a few releases which should


 make the transition relatively painless, at least, it wouldn't be error

 prone, since warnings/deprecation messages would assist the process.
 1. 'virtual' keyword is introduced, 'override'-ing unattributed methods is
 a warning.
 2. it becomes deprecated, but you can still compile with -d.
 3. it becomes an error, but surely you've already taken the opportunity to
 update your software, right?


 This transition also works well. It does mean that the performance
 benefits would not occur until step 3, but while giving time to transition
 it also immediately provides the safety benefits. Ideally it would even
 catch bugs in peoples code as they make the required changes to add virtual
 where needed. The only issue is that it pretty much guarantees that most
 libraries that make use of classes and are no longer maintained will fail
 to compile, but honestly, I don't know think many projects will compile
 anyways when using a compiler / Phobos version that's more than a year
 newer than when the library was last modified.


Indeed. I think it's very safe to say that any un-maintained code already
won't compile. This isn't the first, or even the greatest in magnitude
breaking change that there's been recently.



 Dec 04 2013



  parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Wednesday, 4 December 2013 at 08:01:25 UTC, Manu wrote:

 Indeed. I think it's very safe to say that any un-maintained 
 code already won't compile. This isn't the first, or even the 
 greatest in magnitude breaking change that there's been 
 recently.


Actually, a lot of my old code still compiles, and part of the 
reason is a lot of it is written in a more Java style than using 
the fancier, more likely to change features....

Though, to tell you the truth, I'm not sure just how many methods 
I've overridden in child classes. There's definitely some but 
probably not a huge number (at least excluding interfaces).



 Dec 04 2013



prev sibling next sibling parent  "Nick" <nmsmith65 gmail.com>  writes:


On Wednesday, 4 December 2013 at 07:00:58 UTC, Manu wrote:

 The majority of functions in most OOP classes are properties 
 and trivial
 accessors which should almost never be virtual. Imagine, making 
 virtual
 function calls to access trivial properties? They can't be 
 inlined anymore;
 inlining trivial accessors is one of the most important 
 optimisations for
 OOP that there is.


This is an absolutely important point that should be considered 
the foundation for the argument for final-by-default. Your 
average programmer is NOT going to tag everything as final, and 
the cost of virtual accessors could be tremendous. There's no 
argument for virtual-by-default that is nearly as powerful as 
this.



 Dec 04 2013



prev sibling  parent reply "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 4 December 2013 at 07:00:58 UTC, Manu wrote:

 ...


Can you address proposal to move all such functions into UFCS 
instead? What are possible issues in your opinion as compared to 
declaring them as final inside class?



 Dec 04 2013



  parent  Joseph Rushton Wakeling <joseph.wakeling webdrake.net>  writes:


On 04/12/13 14:22, Dicebot wrote:

 Can you address proposal to move all such functions into UFCS instead? What are
 possible issues in your opinion as compared to declaring them as final inside
 class?


This was discussed at length previously, so it may be an idea to search the 
archives for the original debate.

The killer argument really came down to two points -- of which I'd say the 
second was the one that really swung it:

     * Performance -- with virtual-by-default, we also have slower performance
       by default.  Users who casually try out D will probably be put off by
this
       and not bother to explore far enough to realize they have to use "final"
       to get better performance.

     * Breaking changes -- with final by default, if you accidentally forget to
       mark a method as virtual, you can correct this without affecting
       downstream users.  By contrast with virtual by default, if you
incorrectly
       forget to mark a method as final, you can't correct it later without
       potentially breaking downstream code.

The latter argument is explained in some detail in an interview with one of the 

design.



 Dec 04 2013



prev sibling next sibling parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


https://d.puremagic.com/issues/show_bug.cgi?id=9800
https://d.puremagic.com/issues/show_bug.cgi?id=11530

We seriously need to get debugging output solved! IMHO this is 
biggest hurdle to mainstream adoption. Devs love debuggers and 
the current state of affairs using a debugger with D is simply 
woeful.



 Nov 29 2013



 next sibling parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Fri, Nov 29, 2013 at 06:13:58PM +0100, Gary Willoughby wrote:

 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

Personally I would love to see this old issue finally
implemented/fixed:
There can be only one alias this.
https://d.puremagic.com/issues/show_bug.cgi?id=6083

What would your choice be?


 
 https://d.puremagic.com/issues/show_bug.cgi?id=9800
 https://d.puremagic.com/issues/show_bug.cgi?id=11530
 
 We seriously need to get debugging output solved! IMHO this is
 biggest hurdle to mainstream adoption. Devs love debuggers and the
 current state of affairs using a debugger with D is simply woeful.


+1.

I have to admit I rarely use a debugger, but just this week, I had to
debug a few segfaults in my D code, and trying to use gdb with a
dmd-compiled executable was very painful. The debugger seemed to just
jump about with only an approximate idea of where the code was actually
going, and half the symbols weren't recognized. I had to resort to
writeln debugging to track down the problem. I can see how someone used
to a debugger would throw up their hands at this situation.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze



 Nov 29 2013



prev sibling  parent  "eles" <eles eles.com>  writes:


On Friday, 29 November 2013 at 17:14:00 UTC, Gary Willoughby 
wrote:

 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


 https://d.puremagic.com/issues/show_bug.cgi?id=9800
 https://d.puremagic.com/issues/show_bug.cgi?id=11530

 We seriously need to get debugging output solved! IMHO this is 
 biggest hurdle to mainstream adoption. Devs love debuggers and 
 the current state of affairs using a debugger with D is simply 
 woeful.


++1++



 Nov 29 2013



prev sibling next sibling parent  "bearophile" <bearophileHUGS lycos.com>  writes:


Fra:


 What would your choice be?


Some I like:
- Strongly typed array indexes (this gives safer and more clear 
code, and faster code in debug builds).
- More tuple syntax (that allows shorter, more handy and readable 
code).
- 596 switch on structs + unapply.
- 3999 Enum equality to an int.
- 4085 Steps toward a static foreach.
- 5409 Disallow (!x & y).
- 5713 Broken final switch on ints.
- 9850 Compiler support to implement efficient safe integrals.

Bye,
bearophile



 Nov 30 2013



prev sibling next sibling parent reply "sclytrack" <sclytrack fake.com>  writes:


Re: If you had money to place for a bounty, what would you choose?

Official debian packages for gdc, derelict, gtkd, vibed.



 Dec 01 2013



 next sibling parent  Iain Buclaw <ibuclaw gdcproject.org>  writes:


On Dec 1, 2013 8:10 AM, "sclytrack" <sclytrack fake.com> wrote:

 Re: If you had money to place for a bounty, what would you choose?

 Official debian packages for gdc, derelict, gtkd, vibed.


The gdc packages in Debian are official. :)

Regards
-- 
Iain Buclaw

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



 Dec 01 2013



prev sibling  parent reply Marco Leise <Marco.Leise gmx.de>  writes:


Am Sun, 01 Dec 2013 09:09:32 +0100
schrieb "sclytrack" <sclytrack fake.com>:


 
 Re: If you had money to place for a bounty, what would you choose?
 
 Official debian packages for gdc, derelict, gtkd, vibed.


What compiler and D version should those libraries be compiled
with? The reason I ask this is that current D compilers
produce incompatible ecosystems. You would need a gtkd-dmd,
gtkd-gdc and gtkd-ldc package (or one big package with all
three) and give what is supposedly one library three different
file names to link against.

-- 
Marco



 Dec 04 2013



  parent  "sclytrack" <sclytrack fake.com>  writes:


On Thursday, 5 December 2013 at 05:09:03 UTC, Marco Leise wrote:

 Am Sun, 01 Dec 2013 09:09:32 +0100
 schrieb "sclytrack" <sclytrack fake.com>:


 
 Re: If you had money to place for a bounty, what would you 
 choose?
 
 Official debian packages for gdc, derelict, gtkd, vibed.


 What compiler and D version should those libraries be compiled
 with? The reason I ask this is that current D compilers
 produce incompatible ecosystems. You would need a gtkd-dmd,
 gtkd-gdc and gtkd-ldc package (or one big package with all
 three) and give what is supposedly one library three different
 file names to link against.


	gdc version.

	ldc seems to be stuck in unstable.



 Jun 10 2014



prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com>  writes:


On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


1) C++ namespace support
2) AA fixes
3) std.lexer in Phobos.
4) curl out of Phobos. Replaced by std.net.http package would be 
an extra plus. And yes, I know that curl is more than just a http 
client, all other supported protocols would go into std.net 
eventually.



 Dec 02 2013



 next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/2/13 1:36 AM, Dejan Lekic wrote:

 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


 1) C++ namespace support
 2) AA fixes
 3) std.lexer in Phobos.
 4) curl out of Phobos. Replaced by std.net.http package would be an
 extra plus. And yes, I know that curl is more than just a http client,
 all other supported protocols would go into std.net eventually.


Which of these have bugzilla entries associated with them?

Andrei



 Jan 10 2014



prev sibling  parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Monday, 2 December 2013 at 09:36:03 UTC, Dejan Lekic wrote:

 4) curl out of Phobos. Replaced by std.net.http package would 
 be an extra plus. And yes, I know that curl is more than just a 
 http client, all other supported protocols would go into 
 std.net eventually.


I don't remember if I already said this or not but I started 
slapping together some new http stuff last year

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/http2.d

check out the main() function at the bottom to see how it works 
(so far). Not fancy D code, but I don't think fancy code is 
necessary here.

All requests are done async and it automatically reuses 
connections when it can.



 Jan 10 2014



prev sibling next sibling parent  "safety0ff" <safety0ff.dev gmail.com>  writes:


On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 What would your choice be?


Personally I'd like to see this one fixed:
http://d.puremagic.com/issues/show_bug.cgi?id=5710

In fact I tried to cash in on one of the early back-end bugs to 
shift the bounty to it, but I was beat to the punch by ~10 
minutes (had to do other things before finalizing/re-reviewing my 
commit.)



 Dec 02 2013



prev sibling next sibling parent  "Momo Zilla" <MZ yahoo.mx>  writes:


On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


Personnaly I think there is something incoherant with "this" and 
"pointer to this", it often leads to cast "this" as a pointer ( 
e.g: return cast(void*) this: for the outside world.) There's 
something not quite clear, not well documented about this, which 
leads to an incoherant cast(type hint for the compilo).



 Dec 02 2013



prev sibling next sibling parent reply "nazriel" <spam dzfl.pl>  writes:


On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


I would support LDC project - so maybe more people would work on 
it.

//*me* wishes he could use LDC with Vibe.d



 Dec 02 2013



  parent reply Iain Buclaw <ibuclaw gdcproject.org>  writes:


On 3 December 2013 00:01, nazriel <spam dzfl.pl> wrote:

 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?



 I would support LDC project - so maybe more people would work on it.

 //*me* wishes he could use LDC with Vibe.d


Similarly I won't be around forever, and having a bus factor of 1 is
taking some burdening as time drags on...



 Dec 03 2013



 next sibling parent  "Dejan Lekic" <dejan.lekic gmail.com>  writes:


On Tuesday, 3 December 2013 at 09:51:17 UTC, Iain Buclaw wrote:

 On 3 December 2013 00:01, nazriel <spam dzfl.pl> wrote:

 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?



 I would support LDC project - so maybe more people would work 
 on it.

 //*me* wishes he could use LDC with Vibe.d


 Similarly I won't be around forever, and having a bus factor of 
 1 is
 taking some burdening as time drags on...


+1



 Dec 03 2013



prev sibling  parent  "nazriel" <spam dzfl.pl>  writes:


On Tuesday, 3 December 2013 at 09:51:17 UTC, Iain Buclaw wrote:

 On 3 December 2013 00:01, nazriel <spam dzfl.pl> wrote:

 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?



 I would support LDC project - so maybe more people would work 
 on it.

 //*me* wishes he could use LDC with Vibe.d


 Similarly I won't be around forever, and having a bus factor of 
 1 is
 taking some burdening as time drags on...


Exactly my point.
Other 2 compilers seem to be unnoticed as the ones who need help.

I believe that for some people ldc&gdc are the only reason to 
even consider D as an alternative to C or C++, given how much 
slower are binaries generated by DMD.

I am very worried seeing commits in gdc/ldc being made by 1 man 
for the past weeks.

Just my 2 cents :)



 Dec 04 2013



prev sibling next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally 
 implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


Btw, speaking about paid stuff, if there is one thing I'd 
consider necessary to kickstart funds for is creation of formal 
language specification and keeping it maintained. It is one of 
things that don't go with volunteer efforts very well.



 Dec 03 2013



  parent  Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


03-Dec-2013 21:00, Dicebot пишет:

 On Thursday, 28 November 2013 at 21:01:39 UTC, Fra wrote:

 Personally I would love to see this old issue finally implemented/fixed:
 There can be only one alias this.
 https://d.puremagic.com/issues/show_bug.cgi?id=6083

 What would your choice be?


 Btw, speaking about paid stuff, if there is one thing I'd consider
 necessary to kickstart funds for is creation of formal language
 specification and keeping it maintained. It is one of things that don't
 go with volunteer efforts very well.


+1

-- 
Dmitry Olshansky



 Dec 03 2013



prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net>  writes:


On 28/11/13 22:01, Fra wrote:

 What would your choice be?


A really good overhaul of the website, forums etc. from a UI/UX perspective.  A 
good number of the problems we have with D aren't problems with the language or 
libraries, they're problems with people finding the right information on how to 
work with D.



 Dec 04 2013



  parent reply "Daniel Davidson" <nospam spam.com>  writes:


On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton 
Wakeling wrote:

 On 28/11/13 22:01, Fra wrote:

 What would your choice be?


 A really good overhaul of the website, forums etc. from a UI/UX 
 perspective.  A good number of the problems we have with D 
 aren't problems with the language or libraries, they're 
 problems with people finding the right information on how to 
 work with D.


+1

I'd pay to see vibe.d entered in this: 
http://www.techempower.com/benchmarks/

Notwithstanding the gaming that goes in benchmarking, I think not 
being present is a missed opportunity.



 Dec 04 2013



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/4/13 6:12 AM, Daniel Davidson wrote:

 On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton Wakeling
 wrote:

 On 28/11/13 22:01, Fra wrote:

 What would your choice be?


 A really good overhaul of the website, forums etc. from a UI/UX
 perspective.  A good number of the problems we have with D aren't
 problems with the language or libraries, they're problems with people
 finding the right information on how to work with D.


 +1

 I'd pay to see vibe.d entered in this:
 http://www.techempower.com/benchmarks/

 Notwithstanding the gaming that goes in benchmarking, I think not being
 present is a missed opportunity.


If you're willing you pay you may want to contact them.

Andrei



 Dec 04 2013



  parent  "Daniel Davidson" <nospam spam.com>  writes:


On Wednesday, 4 December 2013 at 16:21:25 UTC, Andrei 
Alexandrescu wrote:

 On 12/4/13 6:12 AM, Daniel Davidson wrote:

 On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton 
 Wakeling
 wrote:

 On 28/11/13 22:01, Fra wrote:

 What would your choice be?


 A really good overhaul of the website, forums etc. from a 
 UI/UX
 perspective.  A good number of the problems we have with D 
 aren't
 problems with the language or libraries, they're problems 
 with people
 finding the right information on how to work with D.


 +1

 I'd pay to see vibe.d entered in this:
 http://www.techempower.com/benchmarks/

 Notwithstanding the gaming that goes in benchmarking, I think 
 not being
 present is a missed opportunity.


 If you're willing you pay you may want to contact them.

 Andrei


No big money, just recent Facebook bounty style numbers. But this 
task is bigger than many of the bugs. I would not want to insult 
the contributors with low numbers. It is more for fun and I think 
done right the publicity is meaningful because the people going 
to that side are looking for edge.

I would kick in something like $80 to  have them get vibe on the 
site and an extra $100 if/when they beat Go in more than half the 
benchmarks :-)



 Dec 04 2013



prev sibling  parent reply "Brad Anderson" <eco gnuk.net>  writes:


On Wednesday, 4 December 2013 at 14:12:11 UTC, Daniel Davidson
wrote:

 On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton 
 Wakeling wrote:

 On 28/11/13 22:01, Fra wrote:

 What would your choice be?


 A really good overhaul of the website, forums etc. from a 
 UI/UX perspective.  A good number of the problems we have with 
 D aren't problems with the language or libraries, they're 
 problems with people finding the right information on how to 
 work with D.


 +1

 I'd pay to see vibe.d entered in this: 
 http://www.techempower.com/benchmarks/

 Notwithstanding the gaming that goes in benchmarking, I think 
 not being present is a missed opportunity.


Sönke has already started work on this:

https://github.com/s-ludwig/FrameworkBenchmarks/tree/master/vibe.d

I'm not sure what remains for it to be integrated.



 Jan 10 2014



 next sibling parent  Paulo Pinto <pjmlp progtools.org>  writes:


Am 11.01.2014 04:19, schrieb Brad Anderson:

 On Wednesday, 4 December 2013 at 14:12:11 UTC, Daniel Davidson
 wrote:

 On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton Wakeling
 wrote:

 On 28/11/13 22:01, Fra wrote:

 What would your choice be?


 A really good overhaul of the website, forums etc. from a UI/UX
 perspective.  A good number of the problems we have with D aren't
 problems with the language or libraries, they're problems with people
 finding the right information on how to work with D.


 +1

 I'd pay to see vibe.d entered in this:
 http://www.techempower.com/benchmarks/

 Notwithstanding the gaming that goes in benchmarking, I think not
 being present is a missed opportunity.


 Sönke has already started work on this:

 https://github.com/s-ludwig/FrameworkBenchmarks/tree/master/vibe.d

 I'm not sure what remains for it to be integrated.


Once I discussed with the responsible guy over at HN.

I would say he is pretty open to have D as well, he just had some issues 
getting it up.

--
Paulo



 Jan 11 2014



prev sibling  parent  "Daniel Davidson" <nospam spam.com>  writes:


On Saturday, 11 January 2014 at 03:19:14 UTC, Brad Anderson wrote:

 On Wednesday, 4 December 2013 at 14:12:11 UTC, Daniel Davidson
 wrote:

 On Wednesday, 4 December 2013 at 09:34:27 UTC, Joseph Rushton 
 Wakeling wrote:

 On 28/11/13 22:01, Fra wrote:

 What would your choice be?


 A really good overhaul of the website, forums etc. from a 
 UI/UX perspective.  A good number of the problems we have 
 with D aren't problems with the language or libraries, 
 they're problems with people finding the right information on 
 how to work with D.


 +1

 I'd pay to see vibe.d entered in this: 
 http://www.techempower.com/benchmarks/

 Notwithstanding the gaming that goes in benchmarking, I think 
 not being present is a missed opportunity.


 Sönke has already started work on this:

 https://github.com/s-ludwig/FrameworkBenchmarks/tree/master/vibe.d

 I'm not sure what remains for it to be integrated.


Just saw this. Great. Hopefully some encouraging numbers coming 
soon!



 Jan 26 2014



prev sibling  parent  "Fra" <Fra b.it>  writes:


Wow, this topic went far more ahead of what I originally 
expected. Nice!

A nice idea that came out is that we should create some form of 
kickstarter for bigger projects (AA, GDC & LGD, formal 
specification of the language, may I add in ddmd?). Anyone here 
willing to take this responsibility?

I would step in but I'm a D newbie, I would have no idea about 
the work required to fix stuff or to get better support for the 
gcc and llvm backends. I'm just an entusiast but I've been 
playing with D and following the language for 2 years, give or 
take. I have now a chance to try it in for a bigger project so 
I'm "more concerned" about development and support of the 
language.



 Dec 04 2013