www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - If I had my way

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I think we have a great release in the making: 64-bit code generation on 
OSX, improved floating point arithmetic, and a bunch of bugfixes.

Yet, if I had my way, I'd stop the release until every single complaint 
of Mehrdad's recent rampage has been looked at and addressed. Sure, we 
can label Mehrdad as a whiny baby, but I suspect his experience is 
representative for the out-of-the-box experience of many others: they 
see D's cool features, they download the compiler to try it out on their 
own terms, and as soon as they deviate from what is tried and works, or 
they combine features in an unusual yet meaningful manner, it all comes 
unglued.

It's about time to make a statement of reconnecting with our community, 
and in particular to the whiny babies out there. Sure, the kind of stuff 
we have in this beta is useful. Floating point arithmetic benchmarks 
have long hurt us, and 64-bit generation on OSX is a gating issue. But 
simple, long-standing issues that make babies whine are very important, 
too, and require our immediate attention.

I vote for making a strong point of fixing these out-of-the-box 
experience issues raised before we move forward with this release.


Andrei
Dec 10 2011
next sibling parent Mehrdad <wfunction hotmail.com> writes:
On 12/10/2011 11:23 AM, Andrei Alexandrescu wrote:

 I think we have a great release in the making: 64-bit code generation 
 on OSX, improved floating point arithmetic, and a bunch of bugfixes.

 Yet, if I had my way, I'd stop the release until every single 
 complaint of Mehrdad's recent rampage has been looked at and 
 addressed. Sure, we can label Mehrdad as a whiny baby, but I suspect 
 his experience is representative for the out-of-the-box experience of 
 many others: they see D's cool features, they download the compiler to 
 try it out on their own terms, and as soon as they deviate from what 
 is tried and works, or they combine features in an unusual yet 
 meaningful manner, it all comes unglued.

 It's about time to make a statement of reconnecting with our 
 community, and in particular to the whiny babies out there. Sure, the 
 kind of stuff we have in this beta is useful. Floating point 
 arithmetic benchmarks have long hurt us, and 64-bit generation on OSX 
 is a gating issue. But simple, long-standing issues that make babies 
 whine are very important, too, and require our immediate attention.

 I vote for making a strong point of fixing these out-of-the-box 
 experience issues raised before we move forward with this release.


 Andrei


+1 (obviously) :)
Dec 10 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 I vote for making a strong point of fixing these out-of-the-box 
 experience issues raised before we move forward with this release.


I suggest to release the nearly done 2.057 and leave those issues to 2.058 and
successive versions.

Bye,
bearophile
Dec 10 2011
parent reply Gour <gour atmarama.net> writes:
On Sat, 10 Dec 2011 14:35:13 -0500
bearophile <bearophileHUGS lycos.com> wrote:


 I suggest to release the nearly done 2.057 and leave those issues to
 2.058 and successive versions.


I suggest releasing 2.057 soon, but then, for subsequent releases, if
there are major improvements to change current numbering scheme.

2.056 --> 2.057 --> 2.058 somehow does not seem right. Of course, maybe
we  should be at 1.99.x instead.


Sincerely,
Gour


--=20
As fire is covered by smoke, as a mirror is covered by dust,=20
or as the embryo is covered by the womb, the living entity is=20
similarly covered by different degrees of this lust.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Dec 10 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/11 2:28 PM, Gour wrote:

 On Sat, 10 Dec 2011 14:35:13 -0500
 bearophile<bearophileHUGS lycos.com>  wrote:


 I suggest to release the nearly done 2.057 and leave those issues to
 2.058 and successive versions.


 I suggest releasing 2.057 soon


We should, after fixing ALL issues raised by Mehrdad.

Andrei
Dec 10 2011
next sibling parent reply Mehrdad <wfunction hotmail.com> writes:
On 12/10/2011 12:37 PM, Andrei Alexandrescu wrote:

 On 12/10/11 2:28 PM, Gour wrote:

 On Sat, 10 Dec 2011 14:35:13 -0500
 bearophile<bearophileHUGS lycos.com>  wrote:


 I suggest to release the nearly done 2.057 and leave those issues to
 2.058 and successive versions.


 I suggest releasing 2.057 soon


 We should, after fixing ALL issues raised by Mehrdad.

 Andrei


I couldn't resist:
http://memegenerator.net/cache/instances/400x/11/11863/12148408.jpg
Dec 10 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/11 2:45 PM, Mehrdad wrote:

 On 12/10/2011 12:37 PM, Andrei Alexandrescu wrote:

 On 12/10/11 2:28 PM, Gour wrote:

 On Sat, 10 Dec 2011 14:35:13 -0500
 bearophile<bearophileHUGS lycos.com> wrote:


 I suggest to release the nearly done 2.057 and leave those issues to
 2.058 and successive versions.


 I suggest releasing 2.057 soon


 We should, after fixing ALL issues raised by Mehrdad.

 Andrei


 I couldn't resist:
 http://memegenerator.net/cache/instances/400x/11/11863/12148408.jpg


http://memegenerator.net/instance/12149588


Andrei
Dec 10 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 We should, after fixing ALL issues raised by Mehrdad.


This is not a wise thing to do. In Bugzilla there are several issues more
urgent/bigger/worse than those raised Mehrdad. In Bugzilla there is a way to
tag bugs with a priority/importance.

Bye,
bearophile
Dec 10 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/11 2:56 PM, bearophile wrote:

 Andrei Alexandrescu:


 We should, after fixing ALL issues raised by Mehrdad.


 This is not a wise thing to do. In Bugzilla there are several issues
 more urgent/bigger/worse than those raised Mehrdad. In Bugzilla there
 is a way to tag bugs with a priority/importance.


There is the important, there's the urgent, there's the important AND 
urgent, and there's also the long overdue. I want us to make a statement 
here, and being predictable/reasonable/rational does not make a statement.

Andrei
Dec 10 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 Floating point arithmetic benchmarks have long hurt us,
 and 64-bit generation on OSX is a gating issue.


The disastrous Windoze toolchain as well.
F*** OMF.
Dec 10 2011
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Sat, 10 Dec 2011 11:36:19 -0800, Trass3r <un known.com> wrote:


 Floating point arithmetic benchmarks have long hurt us,
 and 64-bit generation on OSX is a gating issue.


 The disastrous Windoze toolchain as well.
 F*** OMF.


+1! x64 on Windows will never happen until Optlink is overhauled or COFF  
is added to the Backend.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Dec 10 2011
parent Hans Uhlig <hans.uhlig teamaol.com> writes:
On 12/10/2011 5:33 PM, Adam Wilson wrote:

 On Sat, 10 Dec 2011 11:36:19 -0800, Trass3r <un known.com> wrote:


 Floating point arithmetic benchmarks have long hurt us,
 and 64-bit generation on OSX is a gating issue.


 The disastrous Windoze toolchain as well.
 F*** OMF.


 +1! x64 on Windows will never happen until Optlink is overhauled or COFF
 is added to the Backend.


Yes. Please for the love of god be compatible with the rest of everything.
Dec 13 2011
prev sibling next sibling parent reply David Nadlinger <see klickverbot.at> writes:
I certainly appreciate the general statement, as keeping ones users 
happy is one of the most important, if not the single most important 
thing, to a positive image.

However, please don't forget that there has already been put quite a lot 
of effort into making the current version ready for release (I don't 
think there are any blockers left, are there?). Addressing all the 
points raised would require several potentially high impact changes, 
which could easily set us back for two or three weeks.

Also, the soon-to-be 2.057 fixes quite a few codegen bugs, which are 
notoriously troublesome since tracing them down takes a lot of effort.

And personally, I'd like to see a new version being released soon 
because I'd otherwise have to tell Thrift people to use a Git version of 
DMD when I post my GSoC project for upstream inclusion, which I can't 
postpone infinitely. ;)

As 2.057 will contain a few additions which could potentially require 
some fixes before they can be considered stable, my proposal would be to 
release 2.057 now, and aim for a quick 2.058 to address both the issues 
you mentioned, and any problems turned up by FReD/OS X x86_64 being used 
in the real world.

David



On 12/10/11 8:23 PM, Andrei Alexandrescu wrote:

 I think we have a great release in the making: 64-bit code generation on
 OSX, improved floating point arithmetic, and a bunch of bugfixes.

 Yet, if I had my way, I'd stop the release until every single complaint
 of Mehrdad's recent rampage has been looked at and addressed. Sure, we
 can label Mehrdad as a whiny baby, but I suspect his experience is
 representative for the out-of-the-box experience of many others: they
 see D's cool features, they download the compiler to try it out on their
 own terms, and as soon as they deviate from what is tried and works, or
 they combine features in an unusual yet meaningful manner, it all comes
 unglued.

 It's about time to make a statement of reconnecting with our community,
 and in particular to the whiny babies out there. Sure, the kind of stuff
 we have in this beta is useful. Floating point arithmetic benchmarks
 have long hurt us, and 64-bit generation on OSX is a gating issue. But
 simple, long-standing issues that make babies whine are very important,
 too, and require our immediate attention.

 I vote for making a strong point of fixing these out-of-the-box
 experience issues raised before we move forward with this release.


 Andrei
Dec 10 2011
next sibling parent reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Sat, Dec 10, 2011 at 2:00 PM, David Nadlinger <see klickverbot.at> wrote:

 I certainly appreciate the general statement, as keeping ones users happy is
 one of the most important, if not the single most important thing, to a
 positive image.

 However, please don't forget that there has already been put quite a lot of
 effort into making the current version ready for release (I don't think
 there are any blockers left, are there?). Addressing all the points raised
 would require several potentially high impact changes, which could easily
 set us back for two or three weeks.

 Also, the soon-to-be 2.057 fixes quite a few codegen bugs, which are
 notoriously troublesome since tracing them down takes a lot of effort.

 And personally, I'd like to see a new version being released soon because
 I'd otherwise have to tell Thrift people to use a Git version of DMD when I
 post my GSoC project for upstream inclusion, which I can't postpone
 infinitely. ;)

 As 2.057 will contain a few additions which could potentially require some
 fixes before they can be considered stable, my proposal would be to release
 2.057 now, and aim for a quick 2.058 to address both the issues you
 mentioned, and any problems turned up by FReD/OS X x86_64 being used in the
 real world.


^^
I agree. Postponing the current release doesn't really do anything but
frustrate the people that depend on recent changes. Setting a goal for
the next release accomplishes the same goals without the added
frustration.
We might try making a list of current bugs that *must* be resolved in
the next release. The size of the list would have to be carefully
controlled, but it would bridge the gap between the compiler
developers and the community.
Dec 10 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/11 2:14 PM, Andrew Wiley wrote:

 On Sat, Dec 10, 2011 at 2:00 PM, David Nadlinger<see klickverbot.at>  wrote:

 I certainly appreciate the general statement, as keeping ones users happy is
 one of the most important, if not the single most important thing, to a
 positive image.

 However, please don't forget that there has already been put quite a lot of
 effort into making the current version ready for release (I don't think
 there are any blockers left, are there?). Addressing all the points raised
 would require several potentially high impact changes, which could easily
 set us back for two or three weeks.

 Also, the soon-to-be 2.057 fixes quite a few codegen bugs, which are
 notoriously troublesome since tracing them down takes a lot of effort.

 And personally, I'd like to see a new version being released soon because
 I'd otherwise have to tell Thrift people to use a Git version of DMD when I
 post my GSoC project for upstream inclusion, which I can't postpone
 infinitely. ;)

 As 2.057 will contain a few additions which could potentially require some
 fixes before they can be considered stable, my proposal would be to release
 2.057 now, and aim for a quick 2.058 to address both the issues you
 mentioned, and any problems turned up by FReD/OS X x86_64 being used in the
 real world.


 ^^
 I agree. Postponing the current release doesn't really do anything but
 frustrate the people that depend on recent changes. Setting a goal for
 the next release accomplishes the same goals without the added
 frustration.


There are good ways of addressing that. We can delay the release by only 
a few days and fix long-standing and extremely important issues. This is 
not only about doing the expected/reasonable thing here, but breaking a 
pattern and making a statement.


 We might try making a list of current bugs that *must* be resolved in
 the next release. The size of the list would have to be carefully
 controlled, but it would bridge the gap between the compiler
 developers and the community.


That's a great idea going forward.


Andrei
Dec 10 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jc0fnt$13pu$1 digitalmars.com...

 On 12/10/11 2:14 PM, Andrew Wiley wrote:

 ^^
 I agree. Postponing the current release doesn't really do anything but
 frustrate the people that depend on recent changes. Setting a goal for
 the next release accomplishes the same goals without the added
 frustration.




+1

I do strongly support the new prioritization...but *after* we release 2.057. 
The thing's already in the middle of the doorway, there's no point in not 
getting it the rest of the way out the door..


 There are good ways of addressing that. We can delay the release by only a 
 few days and fix long-standing and extremely important issues. This is not 
 only about doing the expected/reasonable thing here, but breaking a 
 pattern and making a statement.


If, as you suggest, there's some big things that can be fixed in a short 
amount of time, then we can just finish 2.057, and have a short and sweet 
dev cycle for 2.058. The only thing "breaking a pattern and making a 
statement" does for anyone is make it look like we've been possessed by 
Steve Jobs's ghost.
Dec 10 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/11/11 12:55 AM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jc0fnt$13pu$1 digitalmars.com...

 On 12/10/11 2:14 PM, Andrew Wiley wrote:

 ^^
 I agree. Postponing the current release doesn't really do anything but
 frustrate the people that depend on recent changes. Setting a goal for
 the next release accomplishes the same goals without the added
 frustration.




 +1

 I do strongly support the new prioritization...but *after* we release 2.057.
 The thing's already in the middle of the doorway, there's no point in not
 getting it the rest of the way out the door..


This is a done deal now. I would like to thank Kenji and Walter for so 
quickly and resolutely acting on my suggestions.


 There are good ways of addressing that. We can delay the release by only a
 few days and fix long-standing and extremely important issues. This is not
 only about doing the expected/reasonable thing here, but breaking a
 pattern and making a statement.


 If, as you suggest, there's some big things that can be fixed in a short
 amount of time, then we can just finish 2.057, and have a short and sweet
 dev cycle for 2.058. The only thing "breaking a pattern and making a
 statement" does for anyone is make it look like we've been possessed by
 Steve Jobs's ghost.


More rigor and perfectionism ethic wouldn't hurt us one bit. Bugs, 
underdefined and underimplemented features, and an attitude "if it has a 
workaround it's less of a bug" are our main liabilities right now.


Andrei
Dec 11 2011
parent Manu <turkeyman gmail.com> writes:
On 11 December 2011 10:13, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 12/11/11 12:55 AM, Nick Sabalausky wrote:


 "Andrei Alexandrescu"<SeeWebsiteForEma**il erdani.org<SeeWebsiteForEmail erdani.org>>
  wrote in message
 news:jc0fnt$13pu$1 **digitalmars.com...


 On 12/10/11 2:14 PM, Andrew Wiley wrote:


 ^^
 I agree. Postponing the current release doesn't really do anything but
 frustrate the people that depend on recent changes. Setting a goal for
 the next release accomplishes the same goals without the added
 frustration.




 +1

 I do strongly support the new prioritization...but *after* we release
 2.057.
 The thing's already in the middle of the doorway, there's no point in not
 getting it the rest of the way out the door..


 This is a done deal now. I would like to thank Kenji and Walter for so
 quickly and resolutely acting on my suggestions.


  There are good ways of addressing that. We can delay the release by only a

 few days and fix long-standing and extremely important issues. This is
 not
 only about doing the expected/reasonable thing here, but breaking a
 pattern and making a statement.


 If, as you suggest, there's some big things that can be fixed in a short
 amount of time, then we can just finish 2.057, and have a short and sweet
 dev cycle for 2.058. The only thing "breaking a pattern and making a
 statement" does for anyone is make it look like we've been possessed by
 Steve Jobs's ghost.


 More rigor and perfectionism ethic wouldn't hurt us one bit. Bugs,
 underdefined and underimplemented features, and an attitude "if it has a
 workaround it's less of a bug" are our main liabilities right now.



Don't forget incomplete documentation! ;)
Dec 11 2011
prev sibling next sibling parent reply maarten van damme <maartenvd1994 gmail.com> writes:
yes please.
I've read the book "the d programming language" and got all excited until I
actually tried using std.algorithm. (d made up for it pretty soon).
It are the huge problems that prevent people for trying a language but it
are those little things that scare them back away.

And I've also been a bit disappointed in the d way of doing things (it's
easy to write good code but hard is always possible). Just for fun I wanted
to create a program as little as possible, compiled without garbage
collector/phobos/... and it turned out that compiling without garbage
collector is pretty much impossible (memory leaks all around the place in
druntime). dynamic linking for the d standard library would be a great new
option for a dmd release in the future :).
Dec 10 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/10/11 2:22 PM, maarten van damme wrote:

 yes please.
 I've read the book "the d programming language" and got all excited
 until I actually tried using std.algorithm. (d made up for it pretty soon).
 It are the huge problems that prevent people for trying a language but
 it are those little things that scare them back away.


Thanks for confirming my long held suspicion.


 And I've also been a bit disappointed in the d way of doing things (it's
 easy to write good code but hard is always possible).


Could you rephrase that? I don't understand.


 Just for fun I
 wanted to create a program as little as possible, compiled without
 garbage collector/phobos/... and it turned out that compiling without
 garbage collector is pretty much impossible (memory leaks all around the
 place in druntime). dynamic linking for the d standard library would be
 a great new option for a dmd release in the future :).


Using D without GC is an interesting direction, and dynamic linking 
should be available relatively soon.


Andrei
Dec 10 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2011 12:35 PM, Andrei Alexandrescu wrote:

 dynamic linking should be
 available relatively soon.


2.057 makes some progress in that direction.
Dec 10 2011
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:

 On 12/10/11 2:22 PM, maarten van damme wrote:

 Just for fun I
 wanted to create a program as little as possible, compiled without
 garbage collector/phobos/... and it turned out that compiling without
 garbage collector is pretty much impossible (memory leaks all around the
 place in druntime). dynamic linking for the d standard library would be
 a great new option for a dmd release in the future :).


 Using D without GC is an interesting direction, and dynamic linking
 should be available relatively soon.


 Andrei


As a long time beliver in systems programming languages with GC support

direction.

Sure provinding APIs to control GC behavior makes sense, but not turn it
off, we already have enough languages to do systems programming without GC.
Dec 11 2011
next sibling parent reply maarten van damme <maartenvd1994 gmail.com> writes:
2011/12/11 Paulo Pinto <pjmlp progtools.org>


 Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:


 On 12/10/11 2:22 PM, maarten van damme wrote:


 Just for fun I
 wanted to create a program as little as possible, compiled without
 garbage collector/phobos/... and it turned out that compiling without
 garbage collector is pretty much impossible (memory leaks all around the
 place in druntime). dynamic linking for the d standard library would be
 a great new option for a dmd release in the future :).


 Using D without GC is an interesting direction, and dynamic linking
 should be available relatively soon.


 Andrei


 As a long time beliver in systems programming languages with GC support

 direction.

 Sure provinding APIs to control GC behavior makes sense, but not turn it
 off, we already have enough languages to do systems programming without GC.


I was only trying it "for the fun of it", not to be used seriously. D
should always have it's GC support built-in and have some functions to
control it's behaviour (core.memory). But I think that D, beeing a systems
programming language, should also be able to be used without GC. I don't
mean phobos to be writtin without a GC in mind but druntime should be
compilable with something like a -nogc flag that make it usable without GC.

There are a lot of users out there who think that a GC produces terribly
slow programs, big hangs while collecting,... (thank java for that. Right
now the java GC has been improved and it's extremely good but the memory
stays :p)
Letting them know that D can be run without GC can be a good point. If they
don't like it, they can turn it off.
Dec 11 2011
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Hi,

please spend some time reading the research papers from
Native Oberon(Oberon), Topaz(Modula-2+), Spin(Modula-3),


People can argument against that this type of environment
is only possible in research, personally I
am convinced that there are many other reasons like legacy
support, to prevent an widespread support of such systems.

It is just that it takes time to adapt new technologies and
change people's mentalities. Just look how long it took for
funcional programming concepts to become part of mainstream
languages. It takes generations.

--
Paulo




Am 11.12.2011 14:15, schrieb maarten van damme:

 2011/12/11 Paulo Pinto <pjmlp progtools.org <mailto:pjmlp progtools.org>>

     Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:

         On 12/10/11 2:22 PM, maarten van damme wrote:

             Just for fun I
             wanted to create a program as little as possible, compiled
             without
             garbage collector/phobos/... and it turned out that
             compiling without
             garbage collector is pretty much impossible (memory leaks
             all around the
             place in druntime). dynamic linking for the d standard
             library would be
             a great new option for a dmd release in the future :).


         Using D without GC is an interesting direction, and dynamic linking
         should be available relatively soon.


         Andrei


     As a long time beliver in systems programming languages with GC support

     wrong direction.

     Sure provinding APIs to control GC behavior makes sense, but not turn it
     off, we already have enough languages to do systems programming
     without GC.


 I was only trying it "for the fun of it", not to be used seriously. D
 should always have it's GC support built-in and have some functions to
 control it's behaviour (core.memory). But I think that D, beeing a
 systems programming language, should also be able to be used without GC.
 I don't mean phobos to be writtin without a GC in mind but druntime
 should be compilable with something like a -nogc flag that make it
 usable without GC.

 There are a lot of users out there who think that a GC produces terribly
 slow programs, big hangs while collecting,... (thank java for that.
 Right now the java GC has been improved and it's extremely good but the
 memory stays :p)
 Letting them know that D can be run without GC can be a good point. If
 they don't like it, they can turn it off.
Dec 11 2011
prev sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 12/11/2011 08:15 AM, maarten van damme wrote:

 ...
 
 I was only trying it "for the fun of it", not to be used seriously. D
 should always have it's GC support built-in and have some functions to
 control it's behaviour (core.memory). But I think that D, beeing a
 systems programming language, should also be able to be used without GC.
 I don't mean phobos to be writtin without a GC in mind but druntime
 should be compilable with something like a -nogc flag that make it
 usable without GC.
 
 There are a lot of users out there who think that a GC produces terribly
 slow programs, big hangs while collecting,... (thank java for that.
 Right now the java GC has been improved and it's extremely good but the
 memory stays :p)
 Letting them know that D can be run without GC can be a good point. If
 they don't like it, they can turn it off.


I think one thing that could would be (optional) reference counting for
transitively atomic types.  Of course, this is just another kind of
garbage collection, but it is /deterministic/ and parallelizes well, and
I bet this would open up a large amount of Phobos while the
stop-the-world collector is offline, and with little or no code change.

The big example in my mind is strings.  Strings are straight-up atomic.
 They can't have the reference cycles that would confuse a reference
counter.  And if we allowed them to be reference-counted, then all of
the string functions using copy-on-write would now work with the
stop-the-world collector disabled.

It's something I've been thinking of mentioning for a while, but I
suspect there are higher priority things at the moment.
Dec 11 2011
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Actually this could be good idea, it is after all where
Objective-C (with ARC) and C++ on Windows (C++/CX) are
moving to.

But there can be some performance issues nonetheless. I
am no GC expert, but I think in most cases the overhead
imposed by increment/decrement operations looses against
most advanced GC in use today.

--
Paulo

Am 11.12.2011 16:14, schrieb Chad J:

 On 12/11/2011 08:15 AM, maarten van damme wrote:

 ...

 I was only trying it "for the fun of it", not to be used seriously. D
 should always have it's GC support built-in and have some functions to
 control it's behaviour (core.memory). But I think that D, beeing a
 systems programming language, should also be able to be used without GC.
 I don't mean phobos to be writtin without a GC in mind but druntime
 should be compilable with something like a -nogc flag that make it
 usable without GC.

 There are a lot of users out there who think that a GC produces terribly
 slow programs, big hangs while collecting,... (thank java for that.
 Right now the java GC has been improved and it's extremely good but the
 memory stays :p)
 Letting them know that D can be run without GC can be a good point. If
 they don't like it, they can turn it off.


 I think one thing that could would be (optional) reference counting for
 transitively atomic types.  Of course, this is just another kind of
 garbage collection, but it is /deterministic/ and parallelizes well, and
 I bet this would open up a large amount of Phobos while the
 stop-the-world collector is offline, and with little or no code change.

 The big example in my mind is strings.  Strings are straight-up atomic.
   They can't have the reference cycles that would confuse a reference
 counter.  And if we allowed them to be reference-counted, then all of
 the string functions using copy-on-write would now work with the
 stop-the-world collector disabled.

 It's something I've been thinking of mentioning for a while, but I
 suspect there are higher priority things at the moment.
Dec 11 2011
parent reply Bane <branimir.milosavljevic gmail.com> writes:
Paulo Pinto Wrote:


 Actually this could be good idea, it is after all where
 Objective-C (with ARC) and C++ on Windows (C++/CX) are
 moving to.
 
 But there can be some performance issues nonetheless. I
 am no GC expert, but I think in most cases the overhead
 imposed by increment/decrement operations looses against
 most advanced GC in use today.


There is only one way to really settle pro/anti GC discussions, and that is
optional compilation with  or without gc, refcounting etc. That is only way to
get the facts how much does GC slows program down (or not :)

I am pro GC definitely for simple reason it increases productivity
significantly.

But in systems world there will always be significant number of people with
doubt in any GC implementation, or just with a desire to do their own memory
management. I think that group of people is important and we should do what we
can to attract them to D.
Dec 11 2011
next sibling parent reply so <so so.so> writes:
On Sun, 11 Dec 2011 18:12:29 +0200, Bane  
<branimir.milosavljevic gmail.com> wrote:


 There is only one way to really settle pro/anti GC discussions, and that  
 is optional compilation with  or without gc, refcounting etc. That is  
 only way to get the facts how much does GC slows program down (or not :)

 I am pro GC definitely for simple reason it increases productivity  
 significantly.

 But in systems world there will always be significant number of people  
 with doubt in any GC implementation, or just with a desire to do their  
 own memory management. I think that group of people is important and we  
 should do what we can to attract them to D.


Yep, all the GC discussion i have seen people trying to divert it to a MM  
war.
In reality, that is if you ignore PL bigots, problem is so simple. GCs  
fail big time on some specific
tasks. (games are one of the best examples). Now if someone comes up with  
a GC that fulfills this need,
NO sane programmer would use MMM. There is no pro or anti on this issue.  
It is just the practical failure of GC implementations.
Dec 11 2011
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Really?



Do you know that many games in iPhone are done in Unity, which



Am 11.12.2011 17:29, schrieb so:

 On Sun, 11 Dec 2011 18:12:29 +0200, Bane
 <branimir.milosavljevic gmail.com> wrote:



 Yep, all the GC discussion i have seen people trying to divert it to a
 MM war.
 In reality, that is if you ignore PL bigots, problem is so simple. GCs
 fail big time on some specific
 tasks. (games are one of the best examples). Now if someone comes up
 with a GC that fulfills this need,
 NO sane programmer would use MMM. There is no pro or anti on this issue.
 It is just the practical failure of GC implementations.
Dec 11 2011
parent reply so <so so.so> writes:
On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp progtools.org>  
wrote:


 Really?



 Do you know that many games in iPhone are done in Unity, which



I don't understand sorry, are you arguing against the argument i made on  
GCs failure on some specific areas?
Dec 11 2011
next sibling parent reply Bane <branimir.milosavljevic gmail.com> writes:
so Wrote:


 On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp progtools.org>  
 wrote:
 

 Really?



 Do you know that many games in iPhone are done in Unity, which



 
 I don't understand sorry, are you arguing against the argument i made on  
 GCs failure on some specific areas?


Come on kidz, GC does good on some tasks that are not performance critical, it
fails on other tasks that are. That is why D has assembler option - for parts
you need to be done ultra fast. Same should apply for optional  GC. And
everyone gets candy :)
Dec 11 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/11/2011 05:50 PM, Bane wrote:

 so Wrote:


 On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto<pjmlp progtools.org>
 wrote:


 Really?



 Do you know that many games in iPhone are done in Unity, which



 I don't understand sorry, are you arguing against the argument i made on
 GCs failure on some specific areas?


 Come on kidz, GC does good on some tasks that are not performance critical, it
fails on other tasks that are. That is why D has assembler option - for parts
you need to be done ultra fast. Same should apply for optional  GC. And
everyone gets candy :)


GC does not impair performance if done right. The problem is responsiveness.
Dec 11 2011
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 11.12.2011 17:40, schrieb so:

 On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp progtools.org>
 wrote:


 Really?



 Do you know that many games in iPhone are done in Unity, which



 I don't understand sorry, are you arguing against the argument i made on
 GCs failure on some specific areas?


Yes I am, since I know many areas where GC enabled languages have been 
replacing non-GC languages for better or worse.

But then again, I am only a lurker here, so take my arguments with a 
grain of salt.

As a non user of D, I cannot really say much.
Dec 11 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/11/2011 06:49 PM, Paulo Pinto wrote:

 Am 11.12.2011 17:40, schrieb so:

 On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp progtools.org>
 wrote:


 Really?



 Do you know that many games in iPhone are done in Unity, which



 I don't understand sorry, are you arguing against the argument i made on
 GCs failure on some specific areas?


 Yes I am, since I know many areas where GC enabled languages have been
 replacing non-GC languages for better or worse.

 But then again, I am only a lurker here, so take my arguments with a
 grain of salt.

 As a non user of D, I cannot really say much.


GC does not scale if an application has to be responsive. In all other 
cases it is a valid choice.
Dec 11 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/11/2011 10:12 PM, Timon Gehr wrote:

 On 12/11/2011 06:49 PM, Paulo Pinto wrote:

 Am 11.12.2011 17:40, schrieb so:

 On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp progtools.org>
 wrote:


 Really?



 Do you know that many games in iPhone are done in Unity, which



 I don't understand sorry, are you arguing against the argument i made on
 GCs failure on some specific areas?


 Yes I am, since I know many areas where GC enabled languages have been
 replacing non-GC languages for better or worse.

 But then again, I am only a lurker here, so take my arguments with a
 grain of salt.

 As a non user of D, I cannot really say much.


 GC does not scale if an application has to be responsive. In all other
 cases it is a valid choice.


(if you have enough spare memory)
Dec 11 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 11 Dec 2011 16:17:20 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 12/11/2011 10:12 PM, Timon Gehr wrote:

 On 12/11/2011 06:49 PM, Paulo Pinto wrote:

 Am 11.12.2011 17:40, schrieb so:

 On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp progtools.org>
 wrote:


 Really?



 Do you know that many games in iPhone are done in Unity, which



 I don't understand sorry, are you arguing against the argument i made  
 on
 GCs failure on some specific areas?


 Yes I am, since I know many areas where GC enabled languages have been
 replacing non-GC languages for better or worse.

 But then again, I am only a lurker here, so take my arguments with a
 grain of salt.

 As a non user of D, I cannot really say much.


 GC does not scale if an application has to be responsive. In all other
 cases it is a valid choice.


 (if you have enough spare memory)


Don't confuse druntime's GC with the concept of a GC.  Better implemented  
GCs work quite well in practice, even for making responsive apps.

In general, however, GC's need more memory than manually managed code.  So  
for environments where memory is very limited, non-GC is pretty much the  
only option.

-Steve
Dec 12 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 12/12/2011 03:00 PM, Steven Schveighoffer wrote:

 On Sun, 11 Dec 2011 16:17:20 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 12/11/2011 10:12 PM, Timon Gehr wrote:

 On 12/11/2011 06:49 PM, Paulo Pinto wrote:

 Am 11.12.2011 17:40, schrieb so:

 On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp progtools.org>
 wrote:


 Really?



 Do you know that many games in iPhone are done in Unity, which



 I don't understand sorry, are you arguing against the argument i
 made on
 GCs failure on some specific areas?


 Yes I am, since I know many areas where GC enabled languages have been
 replacing non-GC languages for better or worse.

 But then again, I am only a lurker here, so take my arguments with a
 grain of salt.

 As a non user of D, I cannot really say much.


 GC does not scale if an application has to be responsive. In all other
 cases it is a valid choice.


 (if you have enough spare memory)


 Don't confuse druntime's GC with the concept of a GC. Better implemented
 GCs work quite well in practice, even for making responsive apps.


I certainly don't confuse them (GC wouldn't be very interesting if the 
two were the same), and as I understand it there exist very few GC 
implementations that _guarantee_ responsiveness over a long time period. 
This effect gets a lot bigger as memory usage and reference mutation 
rate grow. It is very easy for a sufficiently big Java application, for 
instance, to get responsiveness problems.
Dec 12 2011
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 12 Dec 2011 10:00:28 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:


 On 12/12/2011 03:00 PM, Steven Schveighoffer wrote:

 On Sun, 11 Dec 2011 16:17:20 -0500, Timon Gehr <timon.gehr gmx.ch>  
 wrote:


 On 12/11/2011 10:12 PM, Timon Gehr wrote:

 On 12/11/2011 06:49 PM, Paulo Pinto wrote:

 Am 11.12.2011 17:40, schrieb so:

 On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto  
 <pjmlp progtools.org>
 wrote:


 Really?



 Do you know that many games in iPhone are done in Unity, which



 I don't understand sorry, are you arguing against the argument i
 made on
 GCs failure on some specific areas?


 Yes I am, since I know many areas where GC enabled languages have  
 been
 replacing non-GC languages for better or worse.

 But then again, I am only a lurker here, so take my arguments with a
 grain of salt.

 As a non user of D, I cannot really say much.


 GC does not scale if an application has to be responsive. In all other
 cases it is a valid choice.


 (if you have enough spare memory)


 Don't confuse druntime's GC with the concept of a GC. Better implemented
 GCs work quite well in practice, even for making responsive apps.


 I certainly don't confuse them (GC wouldn't be very interesting if the  
 two were the same), and as I understand it there exist very few GC  
 implementations that _guarantee_ responsiveness over a long time period.  
 This effect gets a lot bigger as memory usage and reference mutation  
 rate grow. It is very easy for a sufficiently big Java application, for  
 instance, to get responsiveness problems.


Oh, I've seen it first hand, I use netbeans.

But I'm not sure it's due to the GC, and not due to it requiring 2x or  
more memory than an equivalent manually managed application requires.  I  
honestly don't konw.

Generally bad things happen when memory gets low, no matter what the  
memory management system or language.

-Steve
Dec 12 2011
prev sibling parent Somedude <lovelydear mailmetrash.com> writes:
Le 12/12/2011 16:00, Timon Gehr a écrit :

 
 I certainly don't confuse them (GC wouldn't be very interesting if the
 two were the same), and as I understand it there exist very few GC
 implementations that _guarantee_ responsiveness over a long time period.
 This effect gets a lot bigger as memory usage and reference mutation
 rate grow. It is very easy for a sufficiently big Java application, for
 instance, to get responsiveness problems.


Is the GC responsiveness increased when there are less objects to
collect ? Wouldn't it be much increased if most small objects (strings,
numbers, date/time objects that account) were managed by a ref counter
and the other, user-defined objects left to the GC ?
Dec 13 2011
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 11.12.2011 17:12, schrieb Bane:

 Paulo Pinto Wrote:
 But in systems world there will always be significant number of people with
doubt in any GC implementation, or just with a desire to do their own memory
management. I think that group of people is important and we should do what we
can to attract them to D.


Those people will eventually become irrelevant.

As I mentioned in a previous email, if I want to use a language without 
GC for systems programming I already have C, C++, Delphi, you name it. 
Why pick D then?
Dec 11 2011
next sibling parent Bane <branimir.milosavljevic gmail.com> writes:
Paulo Pinto Wrote:


 Am 11.12.2011 17:12, schrieb Bane:

 Paulo Pinto Wrote:
 But in systems world there will always be significant number of people with
doubt in any GC implementation, or just with a desire to do their own memory
management. I think that group of people is important and we should do what we
can to attract them to D.


 
 Those people will eventually become irrelevant.
 
 As I mentioned in a previous email, if I want to use a language without 
 GC for systems programming I already have C, C++, Delphi, you name it. 
 Why pick D then?
 


Because people are lazy and hate to learn new language, they will try to do
that in one they already know or already like. If D offers them tools to do MMM
then they have no need to resort  to C,C++ for anything anymore thus it really
replaces them....
Dec 11 2011
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/11/2011 05:35 PM, Paulo Pinto wrote:

 Am 11.12.2011 17:12, schrieb Bane:

 Paulo Pinto Wrote:
 But in systems world there will always be significant number of people
 with doubt in any GC implementation, or just with a desire to do their
 own memory management. I think that group of people is important and
 we should do what we can to attract them to D.


 Those people will eventually become irrelevant.

 As I mentioned in a previous email, if I want to use a language without
 GC for systems programming I already have C, C++, Delphi, you name it.
 Why pick D then?


Because GC is by far not the only thing that matters.
Dec 11 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/11/11 9:14 AM, Chad J wrote:

 On 12/11/2011 08:15 AM, maarten van damme wrote:

 ...

 I was only trying it "for the fun of it", not to be used seriously. D
 should always have it's GC support built-in and have some functions to
 control it's behaviour (core.memory). But I think that D, beeing a
 systems programming language, should also be able to be used without GC.
 I don't mean phobos to be writtin without a GC in mind but druntime
 should be compilable with something like a -nogc flag that make it
 usable without GC.

 There are a lot of users out there who think that a GC produces terribly
 slow programs, big hangs while collecting,... (thank java for that.
 Right now the java GC has been improved and it's extremely good but the
 memory stays :p)
 Letting them know that D can be run without GC can be a good point. If
 they don't like it, they can turn it off.


 I think one thing that could would be (optional) reference counting for
 transitively atomic types.  Of course, this is just another kind of
 garbage collection, but it is /deterministic/ and parallelizes well, and
 I bet this would open up a large amount of Phobos while the
 stop-the-world collector is offline, and with little or no code change.


I think the language has enough (in theory) and nearly enough (in 
practice) expressiveness to implement reference counted classes in a 
library, virtually transparently. I mean one could define a template 
RefCounted (an extended version of what's now in std) such that this 
pattern is possible:

// client code
class WidgetImpl {
   ...
}

alias RefCounted!WidgetImpl Widget;

Aside from using WidgetImpl in type relationships, using Widget would 
transparently insert the appropriate reference counting without 
otherwise interfering with normal WidgetImpl semantics.


Andrei
Dec 11 2011
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Would this then be the shared_ptr<>/weak_ptr<> in D?

Am 11.12.2011 17:21, schrieb Andrei Alexandrescu:

 On 12/11/11 9:14 AM, Chad J wrote:

 On 12/11/2011 08:15 AM, maarten van damme wrote:

 ...

 I was only trying it "for the fun of it", not to be used seriously. D
 should always have it's GC support built-in and have some functions to
 control it's behaviour (core.memory). But I think that D, beeing a
 systems programming language, should also be able to be used without GC.
 I don't mean phobos to be writtin without a GC in mind but druntime
 should be compilable with something like a -nogc flag that make it
 usable without GC.

 There are a lot of users out there who think that a GC produces terribly
 slow programs, big hangs while collecting,... (thank java for that.
 Right now the java GC has been improved and it's extremely good but the
 memory stays :p)
 Letting them know that D can be run without GC can be a good point. If
 they don't like it, they can turn it off.


 I think one thing that could would be (optional) reference counting for
 transitively atomic types. Of course, this is just another kind of
 garbage collection, but it is /deterministic/ and parallelizes well, and
 I bet this would open up a large amount of Phobos while the
 stop-the-world collector is offline, and with little or no code change.


 I think the language has enough (in theory) and nearly enough (in
 practice) expressiveness to implement reference counted classes in a
 library, virtually transparently. I mean one could define a template
 RefCounted (an extended version of what's now in std) such that this
 pattern is possible:

 // client code
 class WidgetImpl {
 ...
 }

 alias RefCounted!WidgetImpl Widget;

 Aside from using WidgetImpl in type relationships, using Widget would
 transparently insert the appropriate reference counting without
 otherwise interfering with normal WidgetImpl semantics.


 Andrei
Dec 11 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/11/11 10:36 AM, Paulo Pinto wrote:

 Would this then be the shared_ptr<>/weak_ptr<> in D?


Better than those actually, because things can be arranged such that the 
user has no access to the native reference.

Andrei
Dec 11 2011
prev sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 12/11/2011 11:21 AM, Andrei Alexandrescu wrote:

 On 12/11/11 9:14 AM, Chad J wrote:

 I think one thing that could would be (optional) reference counting for
 transitively atomic types.  Of course, this is just another kind of
 garbage collection, but it is /deterministic/ and parallelizes well, and
 I bet this would open up a large amount of Phobos while the
 stop-the-world collector is offline, and with little or no code change.


 
 I think the language has enough (in theory) and nearly enough (in
 practice) expressiveness to implement reference counted classes in a
 library, virtually transparently. I mean one could define a template
 RefCounted (an extended version of what's now in std) such that this
 pattern is possible:
 
 // client code
 class WidgetImpl {
   ...
 }
 
 alias RefCounted!WidgetImpl Widget;
 
 Aside from using WidgetImpl in type relationships, using Widget would
 transparently insert the appropriate reference counting without
 otherwise interfering with normal WidgetImpl semantics.
 
 
 Andrei


This is good.  So stick it in the runtime and make the compiler emit
RefCounted!___ templates whenever it finds a transitively atomic type.

This can be done alongside the existing garbage collector.

Then we can benchmark different combinations of memory management
strategies.

Two compiler flags can work in tandem:
-nogc
-norefcount

(Turn them both off if you really want to break Phobos.)
Dec 11 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/11/11 12:17 PM, Chad J wrote:

 On 12/11/2011 11:21 AM, Andrei Alexandrescu wrote:

 On 12/11/11 9:14 AM, Chad J wrote:

 I think one thing that could would be (optional) reference counting for
 transitively atomic types.  Of course, this is just another kind of
 garbage collection, but it is /deterministic/ and parallelizes well, and
 I bet this would open up a large amount of Phobos while the
 stop-the-world collector is offline, and with little or no code change.


 I think the language has enough (in theory) and nearly enough (in
 practice) expressiveness to implement reference counted classes in a
 library, virtually transparently. I mean one could define a template
 RefCounted (an extended version of what's now in std) such that this
 pattern is possible:

 // client code
 class WidgetImpl {
    ...
 }

 alias RefCounted!WidgetImpl Widget;

 Aside from using WidgetImpl in type relationships, using Widget would
 transparently insert the appropriate reference counting without
 otherwise interfering with normal WidgetImpl semantics.


 Andrei


 This is good.  So stick it in the runtime and make the compiler emit
 RefCounted!___ templates whenever it finds a transitively atomic type.

 This can be done alongside the existing garbage collector.

 Then we can benchmark different combinations of memory management
 strategies.

 Two compiler flags can work in tandem:
 -nogc
 -norefcount

 (Turn them both off if you really want to break Phobos.)


We considered that route, and concluded it's marred by too many issues.

Andrei
Dec 11 2011
parent reply Hans Uhlig <hans.uhlig teamaol.com> writes:
On 12/11/2011 11:32 AM, Andrei Alexandrescu wrote:

 On 12/11/11 12:17 PM, Chad J wrote:

 On 12/11/2011 11:21 AM, Andrei Alexandrescu wrote:

 On 12/11/11 9:14 AM, Chad J wrote:

 I think one thing that could would be (optional) reference counting for
 transitively atomic types. Of course, this is just another kind of
 garbage collection, but it is /deterministic/ and parallelizes well,
 and
 I bet this would open up a large amount of Phobos while the
 stop-the-world collector is offline, and with little or no code change.


 I think the language has enough (in theory) and nearly enough (in
 practice) expressiveness to implement reference counted classes in a
 library, virtually transparently. I mean one could define a template
 RefCounted (an extended version of what's now in std) such that this
 pattern is possible:

 // client code
 class WidgetImpl {
 ...
 }

 alias RefCounted!WidgetImpl Widget;

 Aside from using WidgetImpl in type relationships, using Widget would
 transparently insert the appropriate reference counting without
 otherwise interfering with normal WidgetImpl semantics.


 Andrei


 This is good. So stick it in the runtime and make the compiler emit
 RefCounted!___ templates whenever it finds a transitively atomic type.

 This can be done alongside the existing garbage collector.

 Then we can benchmark different combinations of memory management
 strategies.

 Two compiler flags can work in tandem:
 -nogc
 -norefcount

 (Turn them both off if you really want to break Phobos.)


 We considered that route, and concluded it's marred by too many issues.

 Andrei


What issues did it cause?
Dec 13 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/13/11 10:45 AM, Hans Uhlig wrote:

 On 12/11/2011 11:32 AM, Andrei Alexandrescu wrote:

 On 12/11/11 12:17 PM, Chad J wrote:

 On 12/11/2011 11:21 AM, Andrei Alexandrescu wrote:

 On 12/11/11 9:14 AM, Chad J wrote:

 I think one thing that could would be (optional) reference counting
 for
 transitively atomic types. Of course, this is just another kind of
 garbage collection, but it is /deterministic/ and parallelizes well,
 and
 I bet this would open up a large amount of Phobos while the
 stop-the-world collector is offline, and with little or no code
 change.


 I think the language has enough (in theory) and nearly enough (in
 practice) expressiveness to implement reference counted classes in a
 library, virtually transparently. I mean one could define a template
 RefCounted (an extended version of what's now in std) such that this
 pattern is possible:

 // client code
 class WidgetImpl {
 ...
 }

 alias RefCounted!WidgetImpl Widget;

 Aside from using WidgetImpl in type relationships, using Widget would
 transparently insert the appropriate reference counting without
 otherwise interfering with normal WidgetImpl semantics.


 Andrei


 This is good. So stick it in the runtime and make the compiler emit
 RefCounted!___ templates whenever it finds a transitively atomic type.

 This can be done alongside the existing garbage collector.

 Then we can benchmark different combinations of memory management
 strategies.

 Two compiler flags can work in tandem:
 -nogc
 -norefcount

 (Turn them both off if you really want to break Phobos.)


 We considered that route, and concluded it's marred by too many issues.

 Andrei


 What issues did it cause?


Inheritance, conversions, type checks, circular references, ...

Andrei
Dec 13 2011
prev sibling parent reply Alvaro <alvaroDotSegura gmail.com> writes:
El 11/12/2011 16:14, Chad J escribió:

 On 12/11/2011 08:15 AM, maarten van damme wrote:

 ...


 I think one thing that could would be (optional) reference counting for
 transitively atomic types.  Of course, this is just another kind of
 garbage collection, but it is /deterministic/ and parallelizes well, and
 I bet this would open up a large amount of Phobos while the
 stop-the-world collector is offline, and with little or no code change.

 The big example in my mind is strings.  Strings are straight-up atomic.
   They can't have the reference cycles that would confuse a reference
 counter.  And if we allowed them to be reference-counted, then all of
 the string functions using copy-on-write would now work with the
 stop-the-world collector disabled.


Yes, an alternative to GC is reference counting with immediate 
destruction. It is used for instance in Vala (a language on top of the 
GObject system, a bit reminiscent of D):

http://live.gnome.org/Vala/ReferenceHandling

But I think it would be too complicated to turn all D's arrays, objects, 
etc. into a system like this.
Dec 11 2011
parent Somedude <lovelydear mailmetrash.com> writes:
Le 11/12/2011 19:50, Alvaro a écrit :

 But I think it would be too complicated to turn all D's arrays, objects,
 etc. into a system like this.


Nor would it be a good idea imho. I would limit the (templated) ref
counting in the std lib to "basic" objects such as numbers (BigInt,
complex, etc), date/time objects dchars and strings and that's it.
Dec 11 2011
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 11 December 2011 15:15, maarten van damme <maartenvd1994 gmail.com>wrote:


 2011/12/11 Paulo Pinto <pjmlp progtools.org>


 Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:


 On 12/10/11 2:22 PM, maarten van damme wrote:


 Just for fun I
 wanted to create a program as little as possible, compiled without
 garbage collector/phobos/... and it turned out that compiling without
 garbage collector is pretty much impossible (memory leaks all around the
 place in druntime). dynamic linking for the d standard library would be
 a great new option for a dmd release in the future :).


 Using D without GC is an interesting direction, and dynamic linking
 should be available relatively soon.


 Andrei


 As a long time beliver in systems programming languages with GC support

 direction.

 Sure provinding APIs to control GC behavior makes sense, but not turn it
 off, we already have enough languages to do systems programming without
 GC.


 I was only trying it "for the fun of it", not to be used seriously. D
 should always have it's GC support built-in and have some functions to
 control it's behaviour (core.memory). But I think that D, beeing a systems
 programming language, should also be able to be used without GC. I don't
 mean phobos to be writtin without a GC in mind but druntime should be
 compilable with something like a -nogc flag that make it usable without GC.

 There are a lot of users out there who think that a GC produces terribly
 slow programs, big hangs while collecting,... (thank java for that. Right
 now the java GC has been improved and it's extremely good but the memory
 stays :p)
 Letting them know that D can be run without GC can be a good point. If
 they don't like it, they can turn it off.


That's got nothing to do with it. People who seriously NEED to be able to
use the language without the GC enabled are probably working on small
embedded systems with extremely limited resources. It's also possible that
various different resource types need to be allocated/located in different
places.
Also, In many cases, you need to able to have confidence in strict
deterministic allocation patterns. You can't do that with a GC enabled.
I'm all about having a GC in D, obviously, but I certainly couldn't
consider the language for universal adoption in many of my projects without
the option to control/disable it at times.
If I can't write some small programs with the GC completely disabled, then
I basically can't work on microprocessors. It's fair to give up the
standard library when working in this environment, but druntine, the
fundamental library, probably still needs to work. Infact, I'd personally
like it if it was designed in such a way that it never used the GC under
any circumstances. No library FORCED on me should restrict my usage of the
language in such a way.
Dec 11 2011
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 11.12.2011 19:18, schrieb Manu:

 On 11 December 2011 15:15, maarten van damme <maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.com>> wrote:


     2011/12/11 Paulo Pinto <pjmlp progtools.org
     <mailto:pjmlp progtools.org>>

         Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:

             On 12/10/11 2:22 PM, maarten van damme wrote:

                 Just for fun I
                 wanted to create a program as little as possible,
                 compiled without
                 garbage collector/phobos/... and it turned out that
                 compiling without
                 garbage collector is pretty much impossible (memory
                 leaks all around the
                 place in druntime). dynamic linking for the d standard
                 library would be
                 a great new option for a dmd release in the future :).


             Using D without GC is an interesting direction, and dynamic
             linking
             should be available relatively soon.


             Andrei


         As a long time beliver in systems programming languages with GC
         support

         the wrong direction.

         Sure provinding APIs to control GC behavior makes sense, but not
         turn it
         off, we already have enough languages to do systems programming
         without GC.


     I was only trying it "for the fun of it", not to be used seriously.
     D should always have it's GC support built-in and have some
     functions to control it's behaviour (core.memory). But I think that
     D, beeing a systems programming language, should also be able to be
     used without GC. I don't mean phobos to be writtin without a GC in
     mind but druntime should be compilable with something like a -nogc
     flag that make it usable without GC.

     There are a lot of users out there who think that a GC produces
     terribly slow programs, big hangs while collecting,... (thank java
     for that. Right now the java GC has been improved and it's extremely
     good but the memory stays :p)
     Letting them know that D can be run without GC can be a good point.
     If they don't like it, they can turn it off.


 That's got nothing to do with it. People who seriously NEED to be able
 to use the language without the GC enabled are probably working on small
 embedded systems with extremely limited resources. It's also possible
 that various different resource types need to be allocated/located in
 different places.
 Also, In many cases, you need to able to have confidence in strict
 deterministic allocation patterns. You can't do that with a GC enabled.
 I'm all about having a GC in D, obviously, but I certainly couldn't
 consider the language for universal adoption in many of my projects
 without the option to control/disable it at times.
 If I can't write some small programs with the GC completely disabled,
 then I basically can't work on microprocessors. It's fair to give up the
 standard library when working in this environment, but druntine, the
 fundamental library, probably still needs to work. Infact, I'd
 personally like it if it was designed in such a way that it never used
 the GC under any circumstances. No library FORCED on me should restrict
 my usage of the language in such a way.


In my experience programming embedded systems in highly constrained 
environments usually means assembly or at most a C compiler using lots
of compiler specific extensions for the target environment.

I fail to see how D without GC could be a better tool in such enviroments.
Dec 11 2011
next sibling parent Manu <turkeyman gmail.com> writes:
On 11 December 2011 20:34, Paulo Pinto <pjmlp progtools.org> wrote:


 Am 11.12.2011 19:18, schrieb Manu:


 On 11 December 2011 15:15, maarten van damme <maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.**com <maartenvd1994 gmail.com>>> wrote:


    2011/12/11 Paulo Pinto <pjmlp progtools.org
    <mailto:pjmlp progtools.org>>


        Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:

            On 12/10/11 2:22 PM, maarten van damme wrote:

                Just for fun I
                wanted to create a program as little as possible,
                compiled without
                garbage collector/phobos/... and it turned out that
                compiling without
                garbage collector is pretty much impossible (memory
                leaks all around the
                place in druntime). dynamic linking for the d standard
                library would be
                a great new option for a dmd release in the future :).


            Using D without GC is an interesting direction, and dynamic
            linking
            should be available relatively soon.


            Andrei


        As a long time beliver in systems programming languages with GC
        support

        the wrong direction.

        Sure provinding APIs to control GC behavior makes sense, but not
        turn it
        off, we already have enough languages to do systems programming
        without GC.


    I was only trying it "for the fun of it", not to be used seriously.
    D should always have it's GC support built-in and have some
    functions to control it's behaviour (core.memory). But I think that
    D, beeing a systems programming language, should also be able to be
    used without GC. I don't mean phobos to be writtin without a GC in
    mind but druntime should be compilable with something like a -nogc
    flag that make it usable without GC.

    There are a lot of users out there who think that a GC produces
    terribly slow programs, big hangs while collecting,... (thank java
    for that. Right now the java GC has been improved and it's extremely
    good but the memory stays :p)
    Letting them know that D can be run without GC can be a good point.
    If they don't like it, they can turn it off.


 That's got nothing to do with it. People who seriously NEED to be able
 to use the language without the GC enabled are probably working on small
 embedded systems with extremely limited resources. It's also possible
 that various different resource types need to be allocated/located in
 different places.
 Also, In many cases, you need to able to have confidence in strict
 deterministic allocation patterns. You can't do that with a GC enabled.
 I'm all about having a GC in D, obviously, but I certainly couldn't
 consider the language for universal adoption in many of my projects
 without the option to control/disable it at times.
 If I can't write some small programs with the GC completely disabled,
 then I basically can't work on microprocessors. It's fair to give up the
 standard library when working in this environment, but druntine, the
 fundamental library, probably still needs to work. Infact, I'd
 personally like it if it was designed in such a way that it never used
 the GC under any circumstances. No library FORCED on me should restrict
 my usage of the language in such a way.


 In my experience programming embedded systems in highly constrained
 environments usually means assembly or at most a C compiler using lots
 of compiler specific extensions for the target environment.

 I fail to see how D without GC could be a better tool in such enviroments.


The best current example I can think of is PS3, there are 2 separate
architectures in use in that machine, PPC, and SPU, the PPC has 2 separate
heaps, and each SPU has its own 256k micro-heap.
The PPC side would probably use GC in the main heap, and manually manage
resources in the secondary video heap. Each SPU however is a self contained
processor with 256k of memory.
Not only is there no room to waste, but the PROGRAM needs to fit in there
too. Interaction between the main program and the SPU micro-programs is FAR
more painless if they share the same language. With the source code being
shared, it's very easy to copy memory between the processors which directly
share the structure definitions.
Obviously, any code running on the SPU may not use the GC... Period. The
program code its self must also be as small as possible, no space to
wastefully link pointless libraries.

It's hard to say a PS3 isn't a fair target platform for a language like D.
It's not going away either.
This is just one example, almost every games console works like this:
 * PS2 had 4 coprocessors, each with their own micro-memory, one of which
would certainly share source code with the main app (even back then, this
approach was the norm).
 * PSP only has 32mb of ram, explicit management is mandatory on systems
with such small memory.
 * Wii has an ARM coprocessor with a tiny memory bank, it also has
bugger-all main memory (24mb), so you probably want to explicitly manage
memory a lot more.
 * Nintendo DS has a secondary small coprocessor.
 * Larrabee architecture, CELL architecture, or anything like these it will
require running code with explicit management of micro-heaps.

Signal processing, DSP's, etc, usually coprocessors, these aren't tiny
slave chips with microprograms written in assembly anymore, they are
powerful sophisticated coprocessors, with full floating point (usually SIMD
arithmetic, PLEASE PLEASE ADD A 128bit SIMD TYPE) support, would benefit
from D and its libraries, but still have bugger all memory and require
strict control over it.

It's nice to write the master program and the coprocessor programs in the
same language. At very least for the ability to directly share data structs.

I hope I have made an indisputable a case for this. It's come up here a lot
of times, and it's pretty annoying when everyone suggests the reasons for
wanting it are nothing more that maximising performance. I'd suggest that
in 95% of cases, performance has *nothing* to do with it.
Dec 11 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/11/2011 10:34 AM, Paulo Pinto wrote:

 In my experience programming embedded systems in highly constrained
environments
 usually means assembly or at most a C compiler using lots
 of compiler specific extensions for the target environment.

 I fail to see how D without GC could be a better tool in such enviroments.


For a system with a tiny amount of memory, D probably is the wrong tool. My 
suggestion would be:

0..64K assembler
64K..1M C
1M+ D

The larger your program is, the more D starts to pull ahead.
Dec 11 2011
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Walter Bright Wrote:


 On 12/11/2011 10:34 AM, Paulo Pinto wrote:

 In my experience programming embedded systems in highly constrained
environments
 usually means assembly or at most a C compiler using lots
 of compiler specific extensions for the target environment.

 I fail to see how D without GC could be a better tool in such enviroments.


 
 For a system with a tiny amount of memory, D probably is the wrong tool. My 
 suggestion would be:
 
 0..64K assembler
 64K..1M C
 1M+ D
 
 The larger your program is, the more D starts to pull ahead.


Exactly, and with 1M+ we are already getting into the processor's realm which

extensions available. So why have D without GC for such environments?
Dec 11 2011
parent Manu <turkeyman gmail.com> writes:
On 12 December 2011 09:33, Paulo Pinto <pjmlp progtools.org> wrote:


 Walter Bright Wrote:


 On 12/11/2011 10:34 AM, Paulo Pinto wrote:

 In my experience programming embedded systems in highly constrained




 environments

 usually means assembly or at most a C compiler using lots
 of compiler specific extensions for the target environment.

 I fail to see how D without GC could be a better tool in such




 enviroments.

 For a system with a tiny amount of memory, D probably is the wrong tool.


 My

 suggestion would be:

 0..64K assembler
 64K..1M C
 1M+ D

 The larger your program is, the more D starts to pull ahead.


 Exactly, and with 1M+ we are already getting into the processor's realm

 extensions available. So why have D without GC for such environments?


I wrote a massive email, respond to that...
Dec 11 2011
prev sibling next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 12/12/2011 03:58, Walter Bright wrote:

 On 12/11/2011 10:34 AM, Paulo Pinto wrote:

 In my experience programming embedded systems in highly constrained
 environments
 usually means assembly or at most a C compiler using lots
 of compiler specific extensions for the target environment.

 I fail to see how D without GC could be a better tool in such
 enviroments.


 For a system with a tiny amount of memory, D probably is the wrong tool.
 My suggestion would be:

 0..64K assembler
 64K..1M C


enum there = areALotOfCoolThingsInDThatDontNeedGC();

It'd be nice if D was an option here too.


 1M+ D

 The larger your program is, the more D starts to pull ahead.



-- 
Robert
http://octarineparrot.com/
Dec 12 2011
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 12 December 2011 05:58, Walter Bright <newshound2 digitalmars.com> wrote:


 On 12/11/2011 10:34 AM, Paulo Pinto wrote:


 In my experience programming embedded systems in highly constrained
 environments
 usually means assembly or at most a C compiler using lots
 of compiler specific extensions for the target environment.

 I fail to see how D without GC could be a better tool in such enviroments.


 For a system with a tiny amount of memory, D probably is the wrong tool.
 My suggestion would be:

 0..64K assembler
 64K..1M C
 1M+ D

 The larger your program is, the more D starts to pull ahead.


I'd like to hear your comment on my last big email in this thread.
Dec 12 2011
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Sure, I just am not connected to the Internet all the time.

Regarding the Cell processor, many game studios in Germany actually do code the
SPE directly in assembly instead of C with intrinsics, as they even do code
rewriting tricks.

But there is a research JVM for it, hence a GC enabled language
http://people.inf.ethz.ch/anoll/publications/cellvm.pdf

Larrabee is dead, however its sucessor "Manycore", has Haskell support, which
again means a GC enabled language,

http://software.intel.com/en-us/blogs/2010/10/14/prerelease-ghc-and-haskell-cnc-installed-on-intels-manycore-testing-lab-for-academic-use-2/

There are DSP boards that make use of .NET Micro Framework
http://www.analog.com/en/processors-dsp/blackfin/processors/bf518_fmc_dev-kit_ref-design/fca.html
http://www.ghielectronics.com/catalog/product/256/

The Propeller chip for embbeded solutions has the high level Spin
language as main development tool, besides Assembly.

And there is also a JVM available for it.
http://www.parallax.com/tabid/255/Default.aspx

French Radar systems are controlled with the Aonix Perc Ultra JVM. For sure you
are aware of what a GC pause might cause on a missile guidance system if it
wasn't properly implemented.
http://www.mtemag.com/ArticleItem.aspx?Cont_Title=Aonix+lands+Normandie+deal+with+Thales+

Regarding game engines targeting mobile devices and consoles we have Unity
Engine and the upcoming Delta Engine. Both have GC enabled languages.

http://deltaengine.net/
http://unity3d.com/

--
Paulo


Manu Wrote:


 On 12 December 2011 05:58, Walter Bright <newshound2 digitalmars.com> wrote:
 

 On 12/11/2011 10:34 AM, Paulo Pinto wrote:


 In my experience programming embedded systems in highly constrained
 environments
 usually means assembly or at most a C compiler using lots
 of compiler specific extensions for the target environment.

 I fail to see how D without GC could be a better tool in such enviroments.


 For a system with a tiny amount of memory, D probably is the wrong tool.
 My suggestion would be:

 0..64K assembler
 64K..1M C
 1M+ D

 The larger your program is, the more D starts to pull ahead.


 
 I'd like to hear your comment on my last big email in this thread.
 
 <div class="gmail_quote">On 12 December 2011 05:58, Walter Bright <span
dir="ltr">&lt;<a href="mailto:newshound2 digitalmars.com">newshound2 digitalmar
.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
 <div class="im">On 12/11/2011 10:34 AM, Paulo Pinto wrote:<br>
 <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
 In my experience programming embedded systems in highly constrained
environments<br>
 usually means assembly or at most a C compiler using lots<br>
 of compiler specific extensions for the target environment.<br>
 <br>
 I fail to see how D without GC could be a better tool in such enviroments.<br>
 </blockquote>
 <br></div>
 For a system with a tiny amount of memory, D probably is the wrong tool. My
suggestion would be:<br>
 <br>
 0..64K assembler<br>
 64K..1M C<br>
 1M+ D<br>
 <br>
 The larger your program is, the more D starts to pull ahead.<br>
 </blockquote></div><br><div>I'd like to hear your comment on my last big email
in this thread.</div>
Dec 12 2011
parent reply Manu <turkeyman gmail.com> writes:
On 12 December 2011 14:52, Paulo Pinto <pjmlp progtools.org> wrote:


 Sure, I just am not connected to the Internet all the time.

 Regarding the Cell processor, many game studios in Germany actually do
 code the SPE directly in assembly instead of C with intrinsics, as they
 even do code rewriting tricks.

 But there is a research JVM for it, hence a GC enabled language
 http://people.inf.ethz.ch/anoll/publications/cellvm.pdf

 Larrabee is dead, however its sucessor "Manycore", has Haskell support,
 which
 again means a GC enabled language,


 http://software.intel.com/en-us/blogs/2010/10/14/prerelease-ghc-and-haskell-cnc-installed-on-intels-manycore-testing-lab-for-academic-use-2/

 There are DSP boards that make use of .NET Micro Framework

 http://www.analog.com/en/processors-dsp/blackfin/processors/bf518_fmc_dev-kit_ref-design/fca.html
 http://www.ghielectronics.com/catalog/product/256/

 The Propeller chip for embbeded solutions has the high level Spin
 language as main development tool, besides Assembly.

 And there is also a JVM available for it.
 http://www.parallax.com/tabid/255/Default.aspx

 French Radar systems are controlled with the Aonix Perc Ultra JVM. For
 sure you are aware of what a GC pause might cause on a missile guidance
 system if it wasn't properly implemented.

 http://www.mtemag.com/ArticleItem.aspx?Cont_Title=Aonix+lands+Normandie+deal+with+Thales+

 Regarding game engines targeting mobile devices and consoles we have Unity
 Engine and the upcoming Delta Engine. Both have GC enabled languages.

 http://deltaengine.net/
 http://unity3d.com/

 --
 Paulo



Side note; I was addressing that comment mainly to Walter...

I am aware of all these use cases, and I don't believe any of those are
actually counter arguments. You've just showed some different usages, which
I never suggested don't exist.

Half of that is research (jvm on some platform 'x' is just the same as
saying "linux is inevitable").
Noting that some PS3 devs may use assembly directly doesn't change the fact
that most devs use C, or asm via C intrinsics, and will continue to use
assembly/intrinsics via D aswell given the opportunity.
Yes, there are engines which implement *game logic* using GC based
scripts/JIT-ers, but both the ENGINES you mention are still written in
C/C++, and have very tight control of the hardware. Given this example, are
you suggesting D is a scripting language to sit above some C/C++ app? For
me, that's the opposite of what D is.

I'm arguing what is common, expected by many, and shouldn't be taken away
for no reason.
Dec 12 2011
next sibling parent "F i L" <witte2008 gmail.com> writes:
On Monday, 12 December 2011 at 13:56:22 UTC, Manu wrote:

 Yes, there are engines which implement *game logic* using GC 
 based
 scripts/JIT-ers, but both the ENGINES you mention are still 
 written in
 C/C++, and have very tight control of the hardware. Given this 
 example, are
 you suggesting D is a scripting language to sit above some 
 C/C++ app? For
 me, that's the opposite of what D is.


I've thought before how well suited D is for a Unity-style game 
engine. D's an obvious choice for the engine internals, but why 
not use it in replacement of game logic "scripts" as well? SafeD 

(relatively). Only you'd get the added benefit of native 
performance on game logic blocks, which could easily be packaged 
with the engine for release. For an editor, it should be easy 
enough to utilize DMD to compile game-logic files into their own 
temporary executable dynamically (or dynamic library?) which 
would pass messages to the engine running in-editor.
Dec 12 2011
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 12.12.2011 14:56, schrieb Manu:

 Yes, there are engines which implement /game logic/ using GC based
 scripts/JIT-ers, but both the ENGINES you mention are still written in
 C/C++, and have very tight control of the hardware. Given this example,
 are you suggesting D is a scripting language to sit above some C/C++
 app? For me, that's the opposite of what D is.


No, because those scripts as you call it, are compiled to native code
as well. I see no difference from C/C++ code.
Dec 12 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/12/2011 3:31 AM, Manu wrote:

 I'd like to hear your comment on my last big email in this thread.


Eh, I need more help with which one you're talking about.
Dec 12 2011
prev sibling parent Danni Coy <danni.coy gmail.com> writes:
Some of us essentially want "C++ done right".... D does is currently the
closest thing to this that I am aware of.

On Mon, Dec 12, 2011 at 4:34 AM, Paulo Pinto <pjmlp progtools.org> wrote:


 Am 11.12.2011 19:18, schrieb Manu:


 On 11 December 2011 15:15, maarten van damme <maartenvd1994 gmail.com
 <mailto:maartenvd1994 gmail.**com <maartenvd1994 gmail.com>>> wrote:


    2011/12/11 Paulo Pinto <pjmlp progtools.org
    <mailto:pjmlp progtools.org>>


        Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:

            On 12/10/11 2:22 PM, maarten van damme wrote:

                Just for fun I
                wanted to create a program as little as possible,
                compiled without
                garbage collector/phobos/... and it turned out that
                compiling without
                garbage collector is pretty much impossible (memory
                leaks all around the
                place in druntime). dynamic linking for the d standard
                library would be
                a great new option for a dmd release in the future :).


            Using D without GC is an interesting direction, and dynamic
            linking
            should be available relatively soon.


            Andrei


        As a long time beliver in systems programming languages with GC
        support

        the wrong direction.

        Sure provinding APIs to control GC behavior makes sense, but not
        turn it
        off, we already have enough languages to do systems programming
        without GC.


    I was only trying it "for the fun of it", not to be used seriously.
    D should always have it's GC support built-in and have some
    functions to control it's behaviour (core.memory). But I think that
    D, beeing a systems programming language, should also be able to be
    used without GC. I don't mean phobos to be writtin without a GC in
    mind but druntime should be compilable with something like a -nogc
    flag that make it usable without GC.

    There are a lot of users out there who think that a GC produces
    terribly slow programs, big hangs while collecting,... (thank java
    for that. Right now the java GC has been improved and it's extremely
    good but the memory stays :p)
    Letting them know that D can be run without GC can be a good point.
    If they don't like it, they can turn it off.


 That's got nothing to do with it. People who seriously NEED to be able
 to use the language without the GC enabled are probably working on small
 embedded systems with extremely limited resources. It's also possible
 that various different resource types need to be allocated/located in
 different places.
 Also, In many cases, you need to able to have confidence in strict
 deterministic allocation patterns. You can't do that with a GC enabled.
 I'm all about having a GC in D, obviously, but I certainly couldn't
 consider the language for universal adoption in many of my projects
 without the option to control/disable it at times.
 If I can't write some small programs with the GC completely disabled,
 then I basically can't work on microprocessors. It's fair to give up the
 standard library when working in this environment, but druntine, the
 fundamental library, probably still needs to work. Infact, I'd
 personally like it if it was designed in such a way that it never used
 the GC under any circumstances. No library FORCED on me should restrict
 my usage of the language in such a way.


 In my experience programming embedded systems in highly constrained
 environments usually means assembly or at most a C compiler using lots
 of compiler specific extensions for the target environment.

 I fail to see how D without GC could be a better tool in such enviroments.
Dec 12 2011
prev sibling parent Hans Uhlig <hans.uhlig teamaol.com> writes:
On 12/11/2011 4:13 AM, Paulo Pinto wrote:

 Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:

 On 12/10/11 2:22 PM, maarten van damme wrote:

 Just for fun I
 wanted to create a program as little as possible, compiled without
 garbage collector/phobos/... and it turned out that compiling without
 garbage collector is pretty much impossible (memory leaks all around the
 place in druntime). dynamic linking for the d standard library would be
 a great new option for a dmd release in the future :).


 Using D without GC is an interesting direction, and dynamic linking
 should be available relatively soon.


 Andrei


 As a long time beliver in systems programming languages with GC support

 direction.

 Sure provinding APIs to control GC behavior makes sense, but not turn it
 off, we already have enough languages to do systems programming without GC.


If you are doing Embedded Systems programming Dynamic memory and GC are 
pretty much a no no. Perhaps the compiler needs a No GC check to make 
sure when flaged that no GC/GC Managed memory is used. This would 
disable soem features but allow for this need.
Dec 13 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2011 12:00 PM, David Nadlinger wrote:

 I certainly appreciate the general statement, as keeping ones users happy is
one
 of the most important, if not the single most important thing, to a positive
image.

 However, please don't forget that there has already been put quite a lot of
 effort into making the current version ready for release (I don't think there
 are any blockers left, are there?). Addressing all the points raised would
 require several potentially high impact changes, which could easily set us back
 for two or three weeks.

 Also, the soon-to-be 2.057 fixes quite a few codegen bugs, which are
notoriously
 troublesome since tracing them down takes a lot of effort.

 And personally, I'd like to see a new version being released soon because I'd
 otherwise have to tell Thrift people to use a Git version of DMD when I post my
 GSoC project for upstream inclusion, which I can't postpone infinitely. ;)

 As 2.057 will contain a few additions which could potentially require some
fixes
 before they can be considered stable, my proposal would be to release 2.057
now,
 and aim for a quick 2.058 to address both the issues you mentioned, and any
 problems turned up by FReD/OS X x86_64 being used in the real world.


Andrei makes a compelling case, but I am also concerned about messing things up 
for you. What is your schedule like?
Dec 10 2011
parent David Nadlinger <see klickverbot.at> writes:
On 12/10/11 9:34 PM, Walter Bright wrote:

 Andrei makes a compelling case, but I am also concerned about messing
 things up for you. What is your schedule like?


First of all, I don't want it to appear like I would be demanding 
special treatment, which is certainly not what I intend. That being 
said, I originally hoped that I would be able to kick off the review 
process for the upstream merge before Christmas, since it looks like I 
am going to have barely any time to work on Thrift from the beginning of 
January to the mid of February due to university lab courses/exams.

Then again, I personally wouldn't be upset at all if I had to postpone 
the Thrift merge for another month or two – it's just that I know I'll 
have to prioritize university studies over my D-related projects, and 
thus D support in Thrift would be delayed if nobody else stepped up to 
do the merge (the project should be reasonably well documented, but I 
still doubt somebody would).

But maybe I'm grossly overestimating the implications of the issues 
discussed, and fixing them is just a matter of hours or a few days anyway…

Thanks for your thoughtfulness,
David
Dec 10 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, December 10, 2011 13:23:02 Andrei Alexandrescu wrote:

 I think we have a great release in the making: 64-bit code generation on
 OSX, improved floating point arithmetic, and a bunch of bugfixes.
 
 Yet, if I had my way, I'd stop the release until every single complaint
 of Mehrdad's recent rampage has been looked at and addressed. Sure, we
 can label Mehrdad as a whiny baby, but I suspect his experience is
 representative for the out-of-the-box experience of many others: they
 see D's cool features, they download the compiler to try it out on their
 own terms, and as soon as they deviate from what is tried and works, or
 they combine features in an unusual yet meaningful manner, it all comes
 unglued.
 
 It's about time to make a statement of reconnecting with our community,
 and in particular to the whiny babies out there. Sure, the kind of stuff
 we have in this beta is useful. Floating point arithmetic benchmarks
 have long hurt us, and 64-bit generation on OSX is a gating issue. But
 simple, long-standing issues that make babies whine are very important,
 too, and require our immediate attention.
 
 I vote for making a strong point of fixing these out-of-the-box
 experience issues raised before we move forward with this release.


I confess that I don't see the point in delaying the current release for this. 
It's nearly ready. It seems to me that it doesn't cost us anything to just get 
it out the door and move on. _Then_ we focus on these issues - and possibly 
release 2.058 sooner than we might otherwise.

Personally, it doesn't really affect me much either way, since I always use the 
latest from github, but I don't quite understand what delaying a release 
that's about to go out the door will buy us. Focusing on const-related bugs 
would buy us a _lot_. The situation _has_ been improving (e.g. inout actually 
started working with the last release), but there's no question that issues 
with const still remain.

- Jonathan M Davis
Dec 10 2011
next sibling parent Somedude <lovelydear mailmetrash.com> writes:
Le 10/12/2011 21:40, Jonathan M Davis a écrit :

 On Saturday, December 10, 2011 13:23:02 Andrei Alexandrescu wrote:

 I think we have a great release in the making: 64-bit code generation on
 OSX, improved floating point arithmetic, and a bunch of bugfixes.

 Yet, if I had my way, I'd stop the release until every single complaint
 of Mehrdad's recent rampage has been looked at and addressed. Sure, we
 can label Mehrdad as a whiny baby, but I suspect his experience is
 representative for the out-of-the-box experience of many others: they
 see D's cool features, they download the compiler to try it out on their
 own terms, and as soon as they deviate from what is tried and works, or
 they combine features in an unusual yet meaningful manner, it all comes
 unglued.

 It's about time to make a statement of reconnecting with our community,
 and in particular to the whiny babies out there. Sure, the kind of stuff
 we have in this beta is useful. Floating point arithmetic benchmarks
 have long hurt us, and 64-bit generation on OSX is a gating issue. But
 simple, long-standing issues that make babies whine are very important,
 too, and require our immediate attention.

 I vote for making a strong point of fixing these out-of-the-box
 experience issues raised before we move forward with this release.


 
 I confess that I don't see the point in delaying the current release for this. 
 It's nearly ready. It seems to me that it doesn't cost us anything to just get 
 it out the door and move on. _Then_ we focus on these issues - and possibly 
 release 2.058 sooner than we might otherwise.
 
 Personally, it doesn't really affect me much either way, since I always use
the 
 latest from github, but I don't quite understand what delaying a release 
 that's about to go out the door will buy us. Focusing on const-related bugs 
 would buy us a _lot_. The situation _has_ been improving (e.g. inout actually 
 started working with the last release), but there's no question that issues 
 with const still remain.
 
 - Jonathan M Davis


I can understand Andrei's point. He knows the community is the most
important asset of the D project, and we've witnessed what kind of
damage a honest but disappointed user can do to it with the Scala
project or the MongoDB project. It's about keeping an open ear to what
the user has to say.
Dec 11 2011
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
 I confess that I don't see the point in delaying the current 
 release for this. It's nearly ready. It seems to me that it


Compiler and runtime-library projects should never release 
"nearly ready" versions. Some higher level library projects may 
have that luxury, but compiler/run-time library, never! It should 
be released when it IS ready. Not earlier.

Problem with D and Phobos is that there is no clear roadmap (or 
at least I am not aware of its existence). So please tell me how 
you guys know if dmd+phobos is ready to be released or not when 
there was no plan on what this release is all about (apart from 
the list of issues on bugzilla)???
Dec 11 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Dejan Lekic" <dejan.lekic gmail.com> wrote in message 
news:vuwuhxcsxbdpdjxpwhvj dfeed.kimsufi.thecybershadow.net...

 Problem with D and Phobos is that there is no clear roadmap (or at least I 
 am not aware of its existence). So please tell me how you guys know if 
 dmd+phobos is ready to be released or not when there was no plan on what 
 this release is all about (apart from the list of issues on bugzilla)???


When there's enough worthwhile improvements, and the DMD beta mailing list 
determines it doesn't have any big problems, like regressions, etc.  Good 
enough for me. I see no benefit in adding red tape for the sake of having 
more red tape.
Dec 11 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 11, 2011 16:10:47 Dejan Lekic wrote:

 I confess that I don't see the point in delaying the current
 release for this. It's nearly ready. It seems to me that it


 
 Compiler and runtime-library projects should never release
 "nearly ready" versions. Some higher level library projects may
 have that luxury, but compiler/run-time library, never! It should
 be released when it IS ready. Not earlier.
 
 Problem with D and Phobos is that there is no clear roadmap (or
 at least I am not aware of its existence). So please tell me how
 you guys know if dmd+phobos is ready to be released or not when
 there was no plan on what this release is all about (apart from
 the list of issues on bugzilla)???


1. It's "nearly" ready, not ready, so it hasn't been put out the door yet.

2. What does ready mean anyway? In this case, it means that enough time has 
passed since the last release that it makes sense to make another release and 
no major regressions have been introduced (and preferably no regressions at 
all).

If you're looking for the compiler's released to be delayed until it works 
perfectly, it'll never be released. Not only does every compiler on the planet 
have bugs in it, but in order to find most bugs, people need to use the 
compiler in all of the diverse situations that compilers get used in.

dmd has been steadily improving - and at a very high rate as well. Delaying 
this release for a few days to try and fix a few specific bugs doesn't really 
hurt, since there's no hard release schedule, but it's also a bit odd, since 
we've already gone through the necessary beta testing and were about to put it 
out the door. But for better or worse, Andrei and Walter decided to delay the 
release to deal with some of the bugs which Mehrdad was complaining about 
rather than just fixing them for 2.058. Delaying the release means that more 
buigs will be fixed in the next release, but it also means that those using the 
official releases (as opposed to the latest on github) have to wait that much 
longer for all of the fixes that have already been implemented for the next 
release. So, it's not clear which is better.

As for a roadmap, what would you want on it? For the most part, D isn't 
getting new features at this point. A few features aren't fully implemented 
yet, but aside from that it's all bug fixing. And those tend to get fixed when 
they get fixed. Having a roadmap for that sort of thing is difficult. At best, 
Walter could indicate what was being focused on. And with so many of the fixes 
now coming from the community, it becomes that much more difficult to have any 
kind of roadmap about what's going to be fixed next.

The one thing that I can think of which probably should be done would be to 
have a clearer plan about when releases are targeted for rather than Walter 
just deciding at some point that enough time has passed since the previous 
release to have another one (generally 1 - 2 months). But I don't know what he 
could really be putting on a roadmap, since it's all bug fixing now and not new 
feature development.

- Jonathan M Davis
Dec 11 2011
prev sibling next sibling parent reply maarten van damme <maartenvd1994 gmail.com> writes:
And I've also been a bit disappointed in the d way of doing things (it's
easy to write good code but hard is always possible).





Could you rephrase that? I don't understand.


That sentence was referring to the following paragraph. It's a great slogan
but when I actually try to mess around with it it turns out that it's
impossible. Note that this is absolutely not true for most cases. I've
played a bit with memory editing from D, some dll injection and with the
inline assembler.It worked great.

I just wish D had a bit more documentation on some more low-level parts
like raw sockets for example. Or some tutorials/howto's about the less
obvious stuff.
The howto's on d-p-l.org are,while beeing very helpful, also very sparse.

Could also someone shed some light on creating shared library's on linux?
there was some news about -fPIC beeing fixed but no real confirmation.
Dec 10 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2011 12:53 PM, maarten van damme wrote:

 Could also someone shed some light on creating shared library's on linux? there
 was some news about -fPIC beeing fixed but no real confirmation.


Turns out there was a bug where EBX was not set correctly when calling a 
function that existed in a shared library. This bug was fixed. So we're ready
to 
try again at creating a shared library with dmd.
Dec 10 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-10 22:32, Walter Bright wrote:

 On 12/10/2011 12:53 PM, maarten van damme wrote:

 Could also someone shed some light on creating shared library's on
 linux? there
 was some news about -fPIC beeing fixed but no real confirmation.


 Turns out there was a bug where EBX was not set correctly when calling a
 function that existed in a shared library. This bug was fixed. So we're
 ready to try again at creating a shared library with dmd.


That's great to hear. We'll see how far we get this time.

-- 
/Jacob Carlborg
Dec 12 2011
parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Mon, 12 Dec 2011 12:31:44 +0100, Jacob Carlborg <doob me.com> wrote:


 On 2011-12-10 22:32, Walter Bright wrote:

 On 12/10/2011 12:53 PM, maarten van damme wrote:

 Could also someone shed some light on creating shared library's on
 linux? there
 was some news about -fPIC beeing fixed but no real confirmation.


 Turns out there was a bug where EBX was not set correctly when calling a
 function that existed in a shared library. This bug was fixed. So we're
 ready to try again at creating a shared library with dmd.


 That's great to hear. We'll see how far we get this time.


What's the state of the OSX dylib code in dmd and druntime?
Dec 13 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-13 13:42, Martin Nowak wrote:

 On Mon, 12 Dec 2011 12:31:44 +0100, Jacob Carlborg <doob me.com> wrote:


 On 2011-12-10 22:32, Walter Bright wrote:

 On 12/10/2011 12:53 PM, maarten van damme wrote:

 Could also someone shed some light on creating shared library's on
 linux? there
 was some news about -fPIC beeing fixed but no real confirmation.


 Turns out there was a bug where EBX was not set correctly when calling a
 function that existed in a shared library. This bug was fixed. So we're
 ready to try again at creating a shared library with dmd.


 That's great to hear. We'll see how far we get this time.


 What's the state of the OSX dylib code in dmd and druntime?


Most of the needed code is there but it's not "activated". I've been 
trying to get it to work several times but it's always something that I 
can't get to work.

I currently have problems with TLS. Except from that it seems like it 
works, but there are several improvements that could be made. I have

I have a fork of druntime where you can see my progress, I've rewritten 
what's already in druntime: 
https://github.com/jacob-carlborg/druntime/tree/dylib

What's needed or can be improved:

* Cleanup module infos, exception handling tables and TLS when a dynamic 
library is unloaded

* A low level associative array and regular array that can be used 
without having druntime full initialized

I wrote to the DMD internals mailing list about this: 
http://www.mail-archive.com/dmd-internals puremagic.com/msg02701.html

-- 
/Jacob Carlborg
Dec 13 2011
parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Tue, 13 Dec 2011 14:29:09 +0100, Jacob Carlborg <doob me.com> wrote:


 On 2011-12-13 13:42, Martin Nowak wrote:

 On Mon, 12 Dec 2011 12:31:44 +0100, Jacob Carlborg <doob me.com> wrote:


 On 2011-12-10 22:32, Walter Bright wrote:

 On 12/10/2011 12:53 PM, maarten van damme wrote:

 Could also someone shed some light on creating shared library's on
 linux? there
 was some news about -fPIC beeing fixed but no real confirmation.


 Turns out there was a bug where EBX was not set correctly when  
 calling a
 function that existed in a shared library. This bug was fixed. So  
 we're
 ready to try again at creating a shared library with dmd.


 That's great to hear. We'll see how far we get this time.


 What's the state of the OSX dylib code in dmd and druntime?


 Most of the needed code is there but it's not "activated". I've been  
 trying to get it to work several times but it's always something that I  
 can't get to work.

 I currently have problems with TLS. Except from that it seems like it  
 works, but there are several improvements that could be made. I have

 I have a fork of druntime where you can see my progress, I've rewritten  
 what's already in druntime:  
 https://github.com/jacob-carlborg/druntime/tree/dylib

 What's needed or can be improved:

 * Cleanup module infos, exception handling tables and TLS when a dynamic  
 library is unloaded


TLS is not too difficult. We can either use bracketed sections again or
let the compiler emit small thunks that fetch the complete TLS section for
a executable/DSO. The important point is that fetching the TLS addresses  
must
be done for each thread and from a local function within each DSO.
people.redhat.com/drepper/tls.pdf
My current approach is to register callbacks, and let the threads update
their ranges before GC.
Not sure, but it will probably causes eagerly allocation of the TLS blocks.

Some similar issues happen with the other section brackets (.deh, .minfo).
We need local symbols as brackets not global ones as they would collide.

I've tried several approaches.

  o Using a linker script with a recent binutils, add needed d sections
    and use PROVIDE_HIDDEN to bracket them. Then it's only a matter
    of adding constructor/destructor routines that register with druntime.

    It's not too feasible as newer binutils are default on linux only
    and distributing linker scripts is not too nice either.

  o Create a C module similar to crt0.o that creates d sections and  
bracketing
    symbols. Add constructor/destructor to register with druntime.

    The object file needs to be the first when linking, but the linker
    can merge sections, thus there is only one registration per
    executable/shared library.

  o Let the compiler generate a constructor/destructor for executables
    and shared libraries. The object would also need to get linked first.

    This is less transparent than the 2nd option without much benefit.

  o Generate registration routines per object file. No bracketed sections.



So currently I'm in favor of having to install a 'drt0.o' or so somewhere
in the library path and linking it into every executable/DSO.


 * A low level associative array and regular array that can be used  
 without having druntime full initialized

 I wrote to the DMD internals mailing list about this:  
 http://www.mail-archive.com/dmd-internals puremagic.com/msg02701.html
Dec 13 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-13 15:15, Martin Nowak wrote:

 TLS is not too difficult. We can either use bracketed sections again or
 let the compiler emit small thunks that fetch the complete TLS section for
 a executable/DSO. The important point is that fetching the TLS addresses
 must
 be done for each thread and from a local function within each DSO.
 people.redhat.com/drepper/tls.pdf
 My current approach is to register callbacks, and let the threads update
 their ranges before GC.
 Not sure, but it will probably causes eagerly allocation of the TLS blocks.


Mac OS X doesn't support TLS (it does now in 10.7) so Walter rolled his 
own implementation. I don't know how close that is to the EFL 
implementation specified in the above link.


 Some similar issues happen with the other section brackets (.deh, .minfo).
 We need local symbols as brackets not global ones as they would collide.


There is no need for brackets, they just cause problems. The correct way 
to get section data on Mac OS X is to use the "getsectbynamefromheader" 
function. You can have a look at my fork to see how its used.

https://github.com/jacob-carlborg/druntime/blob/dylib/src/rt/memory.d#L318


 I've tried several approaches.


They way I've done it is to register a callback for the 
"_dyld_register_func_for_add_image" function. The documentation 
describes the function as:

"When you call _dyld_register_func_for_add_image, the dynamic linker 
runtime calls the specified callback (func) once for each of the images 
that are currently loaded into the program. When a new image is added to 
the program, your callback is called again with the mach_header for the 
new image, and the virtual memory slide amount of the new image."

In this callback I extract module infos, exception handling tables and 
TLS data from the mach_header. This is now where the problem comes. I 
need an associative array which maps mach_headers to a struct (or 
similar) containing module infos, exception handling tables and TLS 
data. But I don't have an associative array that works this earily in 
the initialization phase of the runtime.

The next problem is with accessing TLS. When a TLS variable is accessed 
the compiler calls the ___tls_get_addr function, implemented in 
druntime. This function receives the address and then converts it to TLS 
using the TLS data bracketed in the object file. In this function I need 
to somehow access the current object file/mach_header, then use this 
mach_header to access the TLS data in the associative array mentioned above.

You can see my current implementation in my fork, everything below this 
line:

https://github.com/jacob-carlborg/druntime/blob/dylib/src/rt/memory.d#L267

As you can see I don't have an associative array so the above currently 
doesn't work.

-- 
/Jacob Carlborg
Dec 13 2011
next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Tue, 13 Dec 2011 15:53:22 +0100, Jacob Carlborg <doob me.com> wrote:


 On 2011-12-13 15:15, Martin Nowak wrote:

 TLS is not too difficult. We can either use bracketed sections again or
 let the compiler emit small thunks that fetch the complete TLS section  
 for
 a executable/DSO. The important point is that fetching the TLS addresses
 must
 be done for each thread and from a local function within each DSO.
 people.redhat.com/drepper/tls.pdf
 My current approach is to register callbacks, and let the threads update
 their ranges before GC.
 Not sure, but it will probably causes eagerly allocation of the TLS  
 blocks.


 Mac OS X doesn't support TLS (it does now in 10.7) so Walter rolled his  
 own implementation. I don't know how close that is to the EFL  
 implementation specified in the above link.


Which would open some room for hooks.


 Some similar issues happen with the other section brackets (.deh,  
 .minfo).
 We need local symbols as brackets not global ones as they would collide.


 There is no need for brackets, they just cause problems. The correct way  
 to get section data on Mac OS X is to use the "getsectbynamefromheader"  
 function. You can have a look at my fork to see how its used.


Correctly used they don't and are a really cheap way to get the ranges.
Having an OS function to do this is nice but as far as I know it doesn't  
port
to ELF (without linking in some elf libs) while the C object ports to OSX.


 https://github.com/jacob-carlborg/druntime/blob/dylib/src/rt/memory.d#L318


 I've tried several approaches.


 They way I've done it is to register a callback for the  
 "_dyld_register_func_for_add_image" function. The documentation  
 describes the function as:

 "When you call _dyld_register_func_for_add_image, the dynamic linker  
 runtime calls the specified callback (func) once for each of the images  
 that are currently loaded into the program. When a new image is added to  
 the program, your callback is called again with the mach_header for the  
 new image, and the virtual memory slide amount of the new image."

 In this callback I extract module infos, exception handling tables and  
 TLS data from the mach_header. This is now where the problem comes. I  
 need an associative array which maps mach_headers to a struct (or  
 similar) containing module infos, exception handling tables and TLS  
 data. But I don't have an associative array that works this earily in  
 the initialization phase of the runtime.


But it will get called from the thread that runs dlopen.
So how do you add/remove an EH table while another thread is
catching exceptions?


 The next problem is with accessing TLS. When a TLS variable is accessed  
 the compiler calls the ___tls_get_addr function, implemented in  
 druntime. This function receives the address and then converts it to TLS  
 using the TLS data bracketed in the object file. In this function I need  
 to somehow access the current object file/mach_header, then use this  
 mach_header to access the TLS data in the associative array mentioned  
 above.


Yeah, __tls_get_addr on OSX will require kind of a DSO specific handle or
call a DSO local function, i.e. C static.

 You can see my current implementation in my fork, everything below this  
 line:

 https://github.com/jacob-carlborg/druntime/blob/dylib/src/rt/memory.d#L267

 As you can see I don't have an associative array so the above currently  
 doesn't work.
Dec 13 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-13 16:29, Martin Nowak wrote:

 Correctly used they don't and are a really cheap way to get the ranges.
 Having an OS function to do this is nice but as far as I know it doesn't
 port
 to ELF (without linking in some elf libs) while the C object ports to OSX.


First, it does cause problems because you will get missing symbols for 
_minfo_beg and _minfo_end when it's compiled as a dynamic library, trust 
me, I've already done this for Tango. Second, It doesn't have to port to 
EFL, it's already platform specific.


 In this callback I extract module infos, exception handling tables and
 TLS data from the mach_header. This is now where the problem comes. I
 need an associative array which maps mach_headers to a struct (or
 similar) containing module infos, exception handling tables and TLS
 data. But I don't have an associative array that works this earily in
 the initialization phase of the runtime.


 But it will get called from the thread that runs dlopen.
 So how do you add/remove an EH table while another thread is
 catching exceptions?


I have no idea from what thread that callback will be called from. I 
haven't thought about what should happen.

-- 
/Jacob Carlborg
Dec 13 2011
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-12-13 14:53:22 +0000, Jacob Carlborg <doob me.com> said:


 In this callback I extract module infos, exception handling tables and 
 TLS data from the mach_header. This is now where the problem comes. I 
 need an associative array which maps mach_headers to a struct (or 
 similar) containing module infos, exception handling tables and TLS 
 data. But I don't have an associative array that works this earily in 
 the initialization phase of the runtime.


Given this code is going to be specific to OS X, maybe you could use a 
CFMutableDictionary instead of rewriting your own hash table.

<http://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFMutableDictionaryRef/Reference/reference.html>

-- 


Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Dec 13 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-13 17:57, Michel Fortin wrote:

 On 2011-12-13 14:53:22 +0000, Jacob Carlborg <doob me.com> said:


 In this callback I extract module infos, exception handling tables and
 TLS data from the mach_header. This is now where the problem comes. I
 need an associative array which maps mach_headers to a struct (or
 similar) containing module infos, exception handling tables and TLS
 data. But I don't have an associative array that works this earily in
 the initialization phase of the runtime.


 Given this code is going to be specific to OS X, maybe you could use a
 CFMutableDictionary instead of rewriting your own hash table.

 <http://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFMutableDictionaryRef/Reference/reference.html>


That's a good idea, I didn't think about that. I often forget about the 
Mac specific API's.

I'm not sure, but we might need an associative array for the other 
platforms as well.

-- 
/Jacob Carlborg
Dec 13 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2011 6:53 AM, Jacob Carlborg wrote:

 As you can see I don't have an associative array so the above currently doesn't
 work.


Just to get things off the ground, you could use a simple linear array.
Dec 13 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-13 20:17, Walter Bright wrote:

 On 12/13/2011 6:53 AM, Jacob Carlborg wrote:

 As you can see I don't have an associative array so the above
 currently doesn't
 work.


 Just to get things off the ground, you could use a simple linear array.


Michel pointed me to the dictionary in the CoreServices framework I 
think I'll use that. But I still don't know how to access the current 
object/mach_header.

-- 
/Jacob Carlborg
Dec 13 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2011 6:15 AM, Martin Nowak wrote:

 TLS is not too difficult. We can either use bracketed sections again or
 let the compiler emit small thunks that fetch the complete TLS section for
 a executable/DSO. The important point is that fetching the TLS addresses must
 be done for each thread and from a local function within each DSO.
 people.redhat.com/drepper/tls.pdf
 My current approach is to register callbacks, and let the threads update
 their ranges before GC.
 Not sure, but it will probably causes eagerly allocation of the TLS blocks.

 Some similar issues happen with the other section brackets (.deh, .minfo).
 We need local symbols as brackets not global ones as they would collide.

 I've tried several approaches.

 o Using a linker script with a recent binutils, add needed d sections
 and use PROVIDE_HIDDEN to bracket them. Then it's only a matter
 of adding constructor/destructor routines that register with druntime.

 It's not too feasible as newer binutils are default on linux only
 and distributing linker scripts is not too nice either.

 o Create a C module similar to crt0.o that creates d sections and bracketing
 symbols. Add constructor/destructor to register with druntime.

 The object file needs to be the first when linking, but the linker
 can merge sections, thus there is only one registration per
 executable/shared library.

 o Let the compiler generate a constructor/destructor for executables
 and shared libraries. The object would also need to get linked first.

 This is less transparent than the 2nd option without much benefit.

 o Generate registration routines per object file. No bracketed sections.


If the compiler generated static constructors and destructors ala C++ that
would 
then be used to register the sections, that could hook into the existing C++ 
support code and not require special linker scripts and special object files.
Dec 13 2011
parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Tue, 13 Dec 2011 20:14:58 +0100, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 12/13/2011 6:15 AM, Martin Nowak wrote:

 TLS is not too difficult. We can either use bracketed sections again or
 let the compiler emit small thunks that fetch the complete TLS section  
 for
 a executable/DSO. The important point is that fetching the TLS  
 addresses must
 be done for each thread and from a local function within each DSO.
 people.redhat.com/drepper/tls.pdf
 My current approach is to register callbacks, and let the threads update
 their ranges before GC.
 Not sure, but it will probably causes eagerly allocation of the TLS  
 blocks.

 Some similar issues happen with the other section brackets (.deh,  
 .minfo).
 We need local symbols as brackets not global ones as they would collide.

 I've tried several approaches.

 o Using a linker script with a recent binutils, add needed d sections
 and use PROVIDE_HIDDEN to bracket them. Then it's only a matter
 of adding constructor/destructor routines that register with druntime.

 It's not too feasible as newer binutils are default on linux only
 and distributing linker scripts is not too nice either.

 o Create a C module similar to crt0.o that creates d sections and  
 bracketing
 symbols. Add constructor/destructor to register with druntime.

 The object file needs to be the first when linking, but the linker
 can merge sections, thus there is only one registration per
 executable/shared library.

 o Let the compiler generate a constructor/destructor for executables
 and shared libraries. The object would also need to get linked first.

 This is less transparent than the 2nd option without much benefit.

 o Generate registration routines per object file. No bracketed sections.


 If the compiler generated static constructors and destructors ala C++  
 that would then be used to register the sections, that could hook into  
 the existing C++ support code and not require special linker scripts and  
 special object files.


I partly agree and will give that approach another try.
The huge drawback is that a shared library is self-contained w.r.t.
module construction, TLS and EH. When doing this on a per object base
the overhead increases with the number of linked objects and guaranteeing
ordered initialization becomes non-trivial.
Dec 14 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-14 11:17, Martin Nowak wrote:

 On Tue, 13 Dec 2011 20:14:58 +0100, Walter Bright
 <newshound2 digitalmars.com> wrote:


 On 12/13/2011 6:15 AM, Martin Nowak wrote:

 TLS is not too difficult. We can either use bracketed sections again or
 let the compiler emit small thunks that fetch the complete TLS
 section for
 a executable/DSO. The important point is that fetching the TLS
 addresses must
 be done for each thread and from a local function within each DSO.
 people.redhat.com/drepper/tls.pdf
 My current approach is to register callbacks, and let the threads update
 their ranges before GC.
 Not sure, but it will probably causes eagerly allocation of the TLS
 blocks.

 Some similar issues happen with the other section brackets (.deh,
 .minfo).
 We need local symbols as brackets not global ones as they would collide.

 I've tried several approaches.

 o Using a linker script with a recent binutils, add needed d sections
 and use PROVIDE_HIDDEN to bracket them. Then it's only a matter
 of adding constructor/destructor routines that register with druntime.

 It's not too feasible as newer binutils are default on linux only
 and distributing linker scripts is not too nice either.

 o Create a C module similar to crt0.o that creates d sections and
 bracketing
 symbols. Add constructor/destructor to register with druntime.

 The object file needs to be the first when linking, but the linker
 can merge sections, thus there is only one registration per
 executable/shared library.

 o Let the compiler generate a constructor/destructor for executables
 and shared libraries. The object would also need to get linked first.

 This is less transparent than the 2nd option without much benefit.

 o Generate registration routines per object file. No bracketed sections.


 If the compiler generated static constructors and destructors ala C++
 that would then be used to register the sections, that could hook into
 the existing C++ support code and not require special linker scripts
 and special object files.


 I partly agree and will give that approach another try.
 The huge drawback is that a shared library is self-contained w.r.t.
 module construction, TLS and EH. When doing this on a per object base
 the overhead increases with the number of linked objects and guaranteeing
 ordered initialization becomes non-trivial.


I don't think this is necessary to support dynamic libraries on Mac OS 
X. I think and hoping _dyld_register_func_for_add_image is sufficient.

-- 
/Jacob Carlborg
Dec 14 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2011 2:17 AM, Martin Nowak wrote:

 If the compiler generated static constructors and destructors ala C++ that
 would then be used to register the sections, that could hook into the existing
 C++ support code and not require special linker scripts and special object
files.


 I partly agree and will give that approach another try.
 The huge drawback is that a shared library is self-contained w.r.t.
 module construction, TLS and EH. When doing this on a per object base
 the overhead increases with the number of linked objects and guaranteeing
 ordered initialization becomes non-trivial.


Yeah, I thought of that after I posted it.
Dec 14 2011
parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Wed, 14 Dec 2011 11:51:13 +0100, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 12/14/2011 2:17 AM, Martin Nowak wrote:

 If the compiler generated static constructors and destructors ala C++  
 that
 would then be used to register the sections, that could hook into the  
 existing
 C++ support code and not require special linker scripts and special  
 object files.


 I partly agree and will give that approach another try.
 The huge drawback is that a shared library is self-contained w.r.t.
 module construction, TLS and EH. When doing this on a per object base
 the overhead increases with the number of linked objects and  
 guaranteeing
 ordered initialization becomes non-trivial.


 Yeah, I thought of that after I posted it.


I think I finally found a feasible solution.
It is possible to create a section group consisting of
a constructor/destructor referencing entries in .ctors/.dtors
and probably related data. The will be treated as one combined
COMDAT and subsequently get merged to a unique instance of each.
Dec 14 2011
prev sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Sat, 10 Dec 2011 22:32:17 +0100, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 12/10/2011 12:53 PM, maarten van damme wrote:

 Could also someone shed some light on creating shared library's on  
 linux? there
 was some news about -fPIC beeing fixed but no real confirmation.


 Turns out there was a bug where EBX was not set correctly when calling a  
 function that existed in a shared library. This bug was fixed. So we're  
 ready to try again at creating a shared library with dmd.


On x86-64 the PIC code is working fine, but there were some relocation  
issues left.
https://github.com/dawgfoto/dmd/commits/SharedElf

I'm looking into wiring things up with the runtime,
but it requires quite some changes.

One thing I don't have a good answer too is how to handle registration
of a shared library loaded during runtime. Apparently we don't want
to synchronize all threads whenever a library gets loaded/unloaded.

martin
Dec 13 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-13 13:12, Martin Nowak wrote:

 On Sat, 10 Dec 2011 22:32:17 +0100, Walter Bright
 <newshound2 digitalmars.com> wrote:


 On 12/10/2011 12:53 PM, maarten van damme wrote:

 Could also someone shed some light on creating shared library's on
 linux? there
 was some news about -fPIC beeing fixed but no real confirmation.


 Turns out there was a bug where EBX was not set correctly when calling
 a function that existed in a shared library. This bug was fixed. So
 we're ready to try again at creating a shared library with dmd.


 On x86-64 the PIC code is working fine, but there were some relocation
 issues left.
 https://github.com/dawgfoto/dmd/commits/SharedElf

 I'm looking into wiring things up with the runtime,
 but it requires quite some changes.

 One thing I don't have a good answer too is how to handle registration
 of a shared library loaded during runtime. Apparently we don't want
 to synchronize all threads whenever a library gets loaded/unloaded.

 martin


On Mac OS X there's a function available for that, 
"_dyld_register_func_for_add_image". I don't know if there's something 
similar available on Linux and FreeBSD.

http://developer.apple.com/library/mac/#documentation/developertools/Reference/MachOReference/Reference/reference.html

-- 
/Jacob Carlborg
Dec 13 2011
parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Tue, 13 Dec 2011 14:12:43 +0100, Jacob Carlborg <doob me.com> wrote:


 On 2011-12-13 13:12, Martin Nowak wrote:

 On Sat, 10 Dec 2011 22:32:17 +0100, Walter Bright
 <newshound2 digitalmars.com> wrote:


 On 12/10/2011 12:53 PM, maarten van damme wrote:

 Could also someone shed some light on creating shared library's on
 linux? there
 was some news about -fPIC beeing fixed but no real confirmation.


 Turns out there was a bug where EBX was not set correctly when calling
 a function that existed in a shared library. This bug was fixed. So
 we're ready to try again at creating a shared library with dmd.


 On x86-64 the PIC code is working fine, but there were some relocation
 issues left.
 https://github.com/dawgfoto/dmd/commits/SharedElf

 I'm looking into wiring things up with the runtime,
 but it requires quite some changes.

 One thing I don't have a good answer too is how to handle registration
 of a shared library loaded during runtime. Apparently we don't want
 to synchronize all threads whenever a library gets loaded/unloaded.

 martin


 On Mac OS X there's a function available for that,  
 "_dyld_register_func_for_add_image". I don't know if there's something  
 similar available on Linux and FreeBSD.

 http://developer.apple.com/library/mac/#documentation/developertools/Reference/MachOReference/Reference/reference.html


This can be done by __attribute__ ((constructor)) or by adding a function
pointer to the .init section.
But the issue is initialization for already running threads.
Dec 13 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-13 15:19, Martin Nowak wrote:

 On Tue, 13 Dec 2011 14:12:43 +0100, Jacob Carlborg <doob me.com> wrote:

 On Mac OS X there's a function available for that,
 "_dyld_register_func_for_add_image". I don't know if there's something
 similar available on Linux and FreeBSD.

 http://developer.apple.com/library/mac/#documentation/developertools/Reference/MachOReference/Reference/reference.html


 This can be done by __attribute__ ((constructor)) or by adding a function
 pointer to the .init section.


If __attribute__ ((constructor)) is used you need a pre-compiled object 
file (written in C) which you can link all your D dynamic libraries with?


 But the issue is initialization for already running threads.


When druntime is first initialized there won't be any D threads and the 
runtime doesn't need to care about non-D threads?

-- 
/Jacob Carlborg
Dec 13 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2011 4:12 AM, Martin Nowak wrote:

 On x86-64 the PIC code is working fine, but there were some relocation issues
left.
 https://github.com/dawgfoto/dmd/commits/SharedElf


I see some good stuff there. When will you be ready for a pull request?
Dec 13 2011
parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Wed, 14 Dec 2011 05:54:19 +0100, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 12/13/2011 4:12 AM, Martin Nowak wrote:

 On x86-64 the PIC code is working fine, but there were some relocation  
 issues left.
 https://github.com/dawgfoto/dmd/commits/SharedElf


 I see some good stuff there. When will you be ready for a pull request?


I don't think that this belongs in the current release if that's what you  
meant.

So far I haven't found any regressions with these changes.
One part I'm not positive about is setting the size of public data symbols
to the DT size.
I also just found another issue with runtime relocations and EH so there  
will
be a little more in this direction but if you don't see any issues with the
data symbols we might as well merge it sooner than later.

martin
Dec 14 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2011 2:39 AM, Martin Nowak wrote:

 I don't think that this belongs in the current release if that's what you
meant.

 So far I haven't found any regressions with these changes.
 One part I'm not positive about is setting the size of public data symbols
 to the DT size.
 I also just found another issue with runtime relocations and EH so there will
 be a little more in this direction but if you don't see any issues with the
 data symbols we might as well merge it sooner than later.


I would like you to be confident that the changes are correct :-)
Dec 14 2011
prev sibling next sibling parent reply "Jesse Phillips" <jessekphillips+D gmail.com> writes:
I wish to add a little of why Mehrdad's complaints are very 
important. I think the delay is a good, over releasing 2.058 two 
days later.

Most in the community have chosen what they will use of D, they 
know of some issues (no multiple alias this), or don't know how 
best to use something (concurrency).

In our marketing for the language we express how great 
such-and-such is, but know that problems will be found by those 
that use it. We could not mention concurrency and how 
immutable/const plays its rule, but we need to answer what is 
different from D1 and how the future of computing will be easier 
in D.

Interestingly Mehrdad has chosen something which does basically 
nothing, the const system. Const isn't important at _all_, except 
that it is a pillar for our functional concurrent purity. We 
claim a language that makes an immutable and mutable world 
coexist. Yet the implementation doesn't back that up.

So why should we probably finish fixing up const, over say the 
multiple alias this,  safe, or no GC use? Because it is what will 
be touched by new users the most. You tell people how great 
mixing immutable and mutable is, they're going to give it a try. 
You pull users over from C++ or other languages with 
non-transitive const, they are going to use const as they do in 
that language without reading about how D does it. These people 
aren't going to be using const correctly in D, they couldn't 
possibly know how to. When they complain, we explain what is 
wrong and how they should be using it, but when they do start 
using it correctly (because they won't listen to our "don't use 
const yet" message) they will still fail to get it right because 
implementation doesn't support it.

We need to be able to prove transitive const is easy to work with 
and worth it. Transitive const is hard to see how it works, but 
no GC and explaining multiple alias this is simple to understand. 
And  safe D is not what brings people to D.

There was a concentration on TDPL bugs before the book came out, 
lets bring that back and get them done for 2.058: 
http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc=tdpl&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr

What do you say team?
Dec 11 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/11/11 1:05 PM, Jesse Phillips wrote:

 I wish to add a little of why Mehrdad's complaints are very important. I
 think the delay is a good, over releasing 2.058 two days later.

 Most in the community have chosen what they will use of D, they know of
 some issues (no multiple alias this), or don't know how best to use
 something (concurrency).

 In our marketing for the language we express how great such-and-such is,
 but know that problems will be found by those that use it. We could not
 mention concurrency and how immutable/const plays its rule, but we need
 to answer what is different from D1 and how the future of computing will
 be easier in D.


Agreed.


 Interestingly Mehrdad has chosen something which does basically nothing,
 the const system. Const isn't important at _all_, except that it is a
 pillar for our functional concurrent purity. We claim a language that
 makes an immutable and mutable world coexist. Yet the implementation
 doesn't back that up.

 So why should we probably finish fixing up const, over say the multiple
 alias this,  safe, or no GC use? Because it is what will be touched by
 new users the most. You tell people how great mixing immutable and
 mutable is, they're going to give it a try. You pull users over from C++
 or other languages with non-transitive const, they are going to use
 const as they do in that language without reading about how D does it.
 These people aren't going to be using const correctly in D, they
 couldn't possibly know how to. When they complain, we explain what is
 wrong and how they should be using it, but when they do start using it
 correctly (because they won't listen to our "don't use const yet"
 message) they will still fail to get it right because implementation
 doesn't support it.

 We need to be able to prove transitive const is easy to work with and
 worth it. Transitive const is hard to see how it works, but no GC and
 explaining multiple alias this is simple to understand. And  safe D is
 not what brings people to D.


Actually my experience is that new users try very early advanced 
examples all over the map. Some indeed try const. Some others try 
interfaces with contract. Some others try concurrency. Some others try 
dimensional analysis. And so on - these examples are drawn only from 
vague recent memories.

It took me a while to figure the psychology. I think what happens is 
that someone trying a new language tends to explore "deltas". Nobody is 
interested in stuff that works the same or similarly in D vs. other 
languages. Nobody's like, "hello world works - I'm sold!" Most often 
someone would see an interesting sample and go like, "Hmm, intriguing. I 
wonder how my idea of tweaking /that/ might work."

In brief, similar to my long experience with C++ "if it compiles, 
somebody will have tried it", my experience with being a sort of a PR 
representative for D suggests that "if it makes sense, a n00b will try 
it and expect it to work". Catering to such a demand is quite difficult 
because you need to cover all cases properly, and fail meaningfully 
(i.e. early and with a good diagnostic) if the demand is unreasonable.

(In the category of failing with a good diagnostic - the issue of 
restricted templates comes to mind. If a call doesn't satisfy any 
restricted template, the compiler should specify which part of the 
complex Boolean expression failed, a la:

test.d(24): Error: reduce(x) failed to match any function
test.d(24): Remark: Candidate std.result failed because 
isInputRange!(typeof(x)) is false
test.d(24): Remark: isInputRange!(typeof(x)) is false because x.front 
does not exist

)


 There was a concentration on TDPL bugs before the book came out, lets
 bring that back and get them done for 2.058:
 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc=tdpl&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr


 What do you say team?


We have indeed identified TDPL alignment an important strategic 
objective. There are more (and more important) bugs than those you 
linked, but I haven't found the time yet to make a pass through them.


Andrei
Dec 11 2011
parent reply Jesse Phillips <jessekphillips+d gmail.com> writes:
On Sun, 11 Dec 2011 14:08:15 -0600, Andrei Alexandrescu wrote:


 Actually my experience is that new users try very early advanced
 examples all over the map. Some indeed try const. Some others try
 interfaces with contract. Some others try concurrency. Some others try
 dimensional analysis. And so on - these examples are drawn only from
 vague recent memories.


I guess what gets me on const is that everyone thinks they know how to 
use it. It is one item where it isn't used because we say, "hey D has 
transitive const it is great!" The user is interested in just using D and 
if from C++ are in the habit of putting const everywhere.

So in essence it is one of the "not being interested as 'I've seen it 
before.'" And then the ultimate response we have to give is, "No, no, D 
is different, it is broken."

Concurrency, well there isn't a preconception on how D does it. And 
immutable is part of it, and const is part of that.

Interface contracts was definitely good.
 

 There was a concentration on TDPL bugs before the book came out, lets
 bring that back and get them done for 2.058:
 http://d.puremagic.com/issues/buglist.cgi?




query_format=advanced&short_desc=tdpl&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr

 What do you say team?


 
 We have indeed identified TDPL alignment an important strategic
 objective. There are more (and more important) bugs than those you
 linked, but I haven't found the time yet to make a pass through them.


I just search on bugs with tdpl in the subject (important convention). I 
don't want fixing other bugs to stop, but to have another concentrated 
effort on one thing, for the next week/two might be a good choice.
Dec 11 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 11, 2011 21:50:02 Jesse Phillips wrote:

 On Sun, 11 Dec 2011 14:08:15 -0600, Andrei Alexandrescu wrote:

 Actually my experience is that new users try very early advanced
 examples all over the map. Some indeed try const. Some others try
 interfaces with contract. Some others try concurrency. Some others try
 dimensional analysis. And so on - these examples are drawn only from
 vague recent memories.


 
 I guess what gets me on const is that everyone thinks they know how to
 use it. It is one item where it isn't used because we say, "hey D has
 transitive const it is great!" The user is interested in just using D and
 if from C++ are in the habit of putting const everywhere.
 
 So in essence it is one of the "not being interested as 'I've seen it
 before.'" And then the ultimate response we have to give is, "No, no, D
 is different, it is broken."
 
 Concurrency, well there isn't a preconception on how D does it. And
 immutable is part of it, and const is part of that.
 
 Interface contracts was definitely good.
 

 There was a concentration on TDPL bugs before the book came out, lets
 bring that back and get them done for 2.058:
 http://d.puremagic.com/issues/buglist.cgi?




 
 query_format=advanced&short_desc=tdpl&bug_status=NEW&bug_status=ASSIGNED&bug
 _status=REOPENED&short_desc_type=allwordssubstr

 What do you say team?


 
 We have indeed identified TDPL alignment an important strategic
 objective. There are more (and more important) bugs than those you
 linked, but I haven't found the time yet to make a pass through them.


 
 I just search on bugs with tdpl in the subject (important convention). I
 don't want fixing other bugs to stop, but to have another concentrated
 effort on one thing, for the next week/two might be a good choice.


And if we're going to really try and get the const issues sorted out, Walter 
really should look at Michel Fortin's changes which replace Rebindable.

And we definitely need to sort out what we want to be doing with const-
correctness and object. Kenji did some pull requests related to that, but 
there were some issues, and I'm not quite sure where that all stands at the 
moment. It _is_ a major element in fixing const though.

- Jonathan M Davis
Dec 11 2011
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Sunday, 11 December 2011 at 22:01:06 UTC, Jonathan M Davis 
wrote:

 And if we're going to really try and get the const issues 
 sorted out, Walter really should look at Michel Fortin's 
 changes which replace Rebindable.

 And we definitely need to sort out what we want to be doing 
 with const-
 correctness and object. Kenji did some pull requests related to 
 that, but there were some issues, and I'm not quite sure where 
 that all stands at the moment. It _is_ a major element in 
 fixing const though.

 - Jonathan M Davis


I concur, these two are major const issues.

Fixing Rebindable seems instrumental in fixing Variant if I 
understand the situation correctly. Fixing Variant is 
instrumental to fixing std.concurrency. A lot of issues are 
solved by going down this path.

As for Object - this week on IRC I had to explain to someone 
relatively new to D that the error he encountered was due to 
Object not being const-correct yet. Which surely sounds like a 
trivial problem to fix, but at least I could link to the 
discussion in the pull request to clarify that it isn't entirely 
straight-forward. This is definitely another source of 
frustration when working with const.
Dec 11 2011
prev sibling parent reply "F i L" <witte2008 gmail.com> writes:
On Saturday, 10 December 2011 at 19:23:02 UTC, Andrei 
Alexandrescu wrote:

 Sure, we can label Mehrdad as a whiny baby, but I suspect his 
 experience is representative for the out-of-the-box experience 
 of many others: they see D's cool features, they download the 
 compiler to try it out on their own terms, and as soon as they 
 deviate from what is tried and works, or they combine features 
 in an unusual yet meaningful manner, it all comes unglued.


As a new member myself, I can testify to this.
After stumbling upon D (via TIOBE top 20) I was very excited to 
find an open-source language with a focus on productivity AND 
efficiency. I bought TDPL book and dove in. However, I sunk a bit 
when I realized some features listed in the book where either 
missing or broken.

My biggest disappointment was(/is) with the lack of the alleged 
Pseudo Methods (section 5.9.1). It's one thing to play around 
with a language you understand is growing and under development. 
It's another to boast about the language to your co-workers, only 
to receive unexpected errors when they ask for demonstrations :/
Bad for publicity, that.


With that said, I think 2.057 should be released soon, and major 
bug resolution should be a focus of 2.058. Beyond bugs and 
missing features, D's weakest area with many of my co-workers, 
and with myself, is it's platform support. The company I work for 

and now we are paying for that choice with so much of the market 
focused on cross-platform, web, and mobile platforms. Mac OSX 
x86_64 support is very needed in D and I hope Window x86_64 and 
ARM support will be the major focus going forward.

D's ambitions far exceed other languages I've come across and I 
look forward to I'm sure is a bright future for the language.

-Philip
Dec 12 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
F i L:


 and I look forward to I'm sure is a bright future for the language.


http://www.youtube.com/watch?v=meRgT5Nmogw

Yeah yeah yeah,
bearophile
Dec 12 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 12, 2011 19:48:11 F i L wrote:

 My biggest disappointment was(/is) with the lack of the alleged
 Pseudo Methods (section 5.9.1). It's one thing to play around
 with a language you understand is growing and under development.
 It's another to boast about the language to your co-workers, only
 to receive unexpected errors when they ask for demonstrations :/
 Bad for publicity, that.


I think that that section was not clear enough. Calling free functions as if 
they were member functions on a type works with arrays and has only ever 
worked with arrays. TDPL doesn't actually say that it works with anything 
other than arrays. It talks about adding them to built-in types and 
specifically talks about arrays, but it's not particularly clear about anything 
other than arrays. My guess is that it was never intended to mean anything 
other than arrays, but I don't know. Only Andrei would know that.

There has been discussion of UFCS (universal function call syntax), which 
would then expand that beyond arrays to _all_ types - int, float, any user-
defined type, etc. However, there are a number of issues with that 
(particularly with user-defined types; e.g. what if a member function and a 
free function have the same name?), and it has yet to be implemented. It may 
never be implemented.

So, I think that there's a decent chance that you just misunderstood what that 
section in TDPL was really saying (it really should be clearer on whether it 
meant just arrays or all types), but there are definitely folks who want it to 
be extended to all types, so it may be eventually, but we'll have to wait and 
see.

- Jonathan M Davis
Dec 12 2011
parent reply "F i L" <witte2008 gmail.com> writes:
On Monday, 12 December 2011 at 21:57:36 UTC, Jonathan M Davis 
wrote:

 There has been discussion of UFCS (universal function call 
 syntax), which would then expand that beyond arrays to _all_ 
 types - int, float, any user-
 defined type, etc. However, there are a number of issues with 
 that (particularly with user-defined types; e.g. what if a 
 member function and a free function have the same name?), and 
 it has yet to be implemented. It may never be implemented.



the 'this' keyword as a parameter attribute in the pseudo method 
(http://msdn.microsoft.com/en-us/library/bb383977.aspx). Any 

understand using the 'this' keyword as a parameter attribute 
already serves a different purpose in D, but I'm sure another 
keyword ('pseudo' perhaps?) or equivalent syntax could be 
reached. At which point, any external pseudo method conflicting 
with an objects internal members could simply result in a 
compiler error (or, member functions could take priority over 
pseudo methods).

I understand this isn't exactly a priority, but IMO it could 
really help the overall syntax feel more consistent in some areas.

    import std.conv;

    void main()
    {
        string encoded = "1324.03";
        double actual = encoded.to!string; // similar to 
Object.toString()
    }

More importantly, pseudo methods could be used to bend the rules 
of member access, and to implement module-specific functionality 
for imported objects without breaking OOP syntax.

    module a;

    class A {
        int data;
    }

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    module b;

    pseudo void foo(A a, B b) {
        // A can access B's private members
        a.data = b._data;
    }

    class B {
        private int _data;
    }

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    import a, b;

    void main() {
        auto a = new A();
        auto b = new B();

        a.foo(b); // cool!
    }



 So, I think that there's a decent chance that you just 
 misunderstood what that section in TDPL was really saying (it 
 really should be clearer on whether it meant just arrays or all 
 types), but there are definitely folks who want it to be 
 extended to all types, so it may be eventually, but we'll have 
 to wait and see.


Undoubtedly a misunderstanding on my end. Still, +1 for seeing 
Pseudo Members for all types.

- Philip
Dec 12 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, December 13, 2011 05:13:29 F i L wrote:

 On Monday, 12 December 2011 at 21:57:36 UTC, Jonathan M Davis
 
 wrote:

 There has been discussion of UFCS (universal function call
 syntax), which would then expand that beyond arrays to _all_
 types - int, float, any user-
 defined type, etc. However, there are a number of issues with
 that (particularly with user-defined types; e.g. what if a
 member function and a free function have the same name?), and
 it has yet to be implemented. It may never be implemented.


 

 the 'this' keyword as a parameter attribute in the pseudo method
 (http://msdn.microsoft.com/en-us/library/bb383977.aspx). Any

 understand using the 'this' keyword as a parameter attribute
 already serves a different purpose in D, but I'm sure another
 keyword ('pseudo' perhaps?) or equivalent syntax could be
 reached. At which point, any external pseudo method conflicting
 with an objects internal members could simply result in a
 compiler error (or, member functions could take priority over
 pseudo methods).


There have been a variety of suggestions on how to do it - including one 
similar to what you're suggesting with the this keyword. However, it still 
leaves the problem of disambiguation that I mentioned. What happens when 
there's a free function and a member function with the same name and same 
parameters? Which one gets called? It's issues like that which are more of a 
problem than the exact syntax for declaring it IMHO. And all of those details 
need to be sorted out in a satisfactory manner before we can add UFCS to the 
language in any form.

For arrays, all you need to do is have the first argument be an array, and that 
works great for arrays, but arrays don't have much in the way of functions 
built in, so there's no conflict.

Realistically, at this point, I'd expect that if UFCS gets added any time 
soon, it's going to require that someone other than Walter do it and that they 
have do it very solidly, otherwise it could be a long time before it stands 
any chance of happening, simply because Walter is focused on fixing major bugs 
and stabilizing the compiler and isn't likely to look at adding new features 
anytime soon if there's no dire need (even if they're backwards compatible).

- Jonathan M Davis
Dec 12 2011
next sibling parent reply Mehrdad <wfunction hotmail.com> writes:
On 12/12/2011 8:25 PM, Jonathan M Davis wrote:

 There have been a variety of suggestions on how to do it - including one
 similar to what you're suggesting with the this keyword. However, it still
 leaves the problem of disambiguation that I mentioned. What happens when
 there's a free function and a member function with the same name and same
 parameters? Which one gets called?



well. There's really no problem in practice.
Dec 12 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 12, 2011 21:17:10 Mehrdad wrote:

 On 12/12/2011 8:25 PM, Jonathan M Davis wrote:

 There have been a variety of suggestions on how to do it - including one
 similar to what you're suggesting with the this keyword. However, it
 still leaves the problem of disambiguation that I mentioned. What
 happens when there's a free function and a member function with the
 same name and same parameters? Which one gets called?


 

 well. There's really no problem in practice.


I'm not saying that it can't be done. I'm just saying that all of the corner 
cases and the like have to be sorted out such that the feature is completely 
defined, and we don't have ambiguities that are going to cause problems. Things 
are complicated enough with alias this and opDispatch and the like. Adding yet 
another way to add functions to a type complicates things that much further. 
So, UFCS needs to be carefully designed, and that's more of an issue IMHO than 
the exact syntax used to determine if a function is supposed to work with 
UFCS.

- Jonathan M Davis
Dec 12 2011
parent reply Mehrdad <wfunction hotmail.com> writes:
On 12/12/2011 9:28 PM, Jonathan M Davis wrote:

 On Monday, December 12, 2011 21:17:10 Mehrdad wrote:



 well. There's really no problem in practice.


 I'm not saying that it can't be done. I'm just saying that all of the corner
 cases and the like have to be sorted out such that the feature is completely
 defined, and we don't have ambiguities that are going to cause problems. Things
 are complicated enough with alias this and opDispatch and the like. Adding yet
 another way to add functions to a type complicates things that much further.
 So, UFCS needs to be carefully designed, and that's more of an issue IMHO than
 the exact syntax used to determine if a function is supposed to work with
 UFCS.

 - Jonathan M Davis


Just wondering, what _are_ the corner cases?

Whatever is already accessible through the object would automatically 
override -- whether it's alias this, opDispatch, or whatever. Only if 
everything fails, then would extension methods work.
Wouldn't that work?
Dec 13 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-13 10:54, Mehrdad wrote:

 On 12/12/2011 9:28 PM, Jonathan M Davis wrote:

 On Monday, December 12, 2011 21:17:10 Mehrdad wrote:



 well. There's really no problem in practice.


 I'm not saying that it can't be done. I'm just saying that all of the
 corner
 cases and the like have to be sorted out such that the feature is
 completely
 defined, and we don't have ambiguities that are going to cause
 problems. Things
 are complicated enough with alias this and opDispatch and the like.
 Adding yet
 another way to add functions to a type complicates things that much
 further.
 So, UFCS needs to be carefully designed, and that's more of an issue
 IMHO than
 the exact syntax used to determine if a function is supposed to work with
 UFCS.

 - Jonathan M Davis


 Just wondering, what _are_ the corner cases?


The floating point syntax with an optional zero cause a conflict.

1. and .1


-- 
/Jacob Carlborg
Dec 13 2011
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-12-13 04:25:33 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:


 For arrays, all you need to do is have the first argument be an array, and that
 works great for arrays, but arrays don't have much in the way of functions
 built in, so there's no conflict.


Actually, there's still an open issue with array-member syntax and 
 property used together.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Dec 13 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, December 13, 2011 06:40:40 Michel Fortin wrote:

 On 2011-12-13 04:25:33 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:

 For arrays, all you need to do is have the first argument be an array,
 and that works great for arrays, but arrays don't have much in the way
 of functions built in, so there's no conflict.


 
 Actually, there's still an open issue with array-member syntax and
  property used together.


How so? If it's a property function, not a member function (which couldn't use 
array-member syntaxt anyway), and it takes an array as its first argument, then 
it _must_ be called with array-member syntax without parens. If it isn't a 
property, then you could call it with or without array-member syntax, but you 
have to use parens. I don't see any conflict there.

Now, I don't know what -property is doing with it at the moment, but I don't 
see how it could work any other way.

- Jonathan M Davis
Dec 13 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-12-13 16:57:33 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:


 On Tuesday, December 13, 2011 06:40:40 Michel Fortin wrote:

 On 2011-12-13 04:25:33 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:

 For arrays, all you need to do is have the first argument be an array,
 and that works great for arrays, but arrays don't have much in the way
 of functions built in, so there's no conflict.


 
 Actually, there's still an open issue with array-member syntax and
  property used together.


 
 How so? If it's a property function, not a member function (which couldn't use
 array-member syntaxt anyway), and it takes an array as its first argument, then
 it _must_ be called with array-member syntax without parens. If it isn't a
 property, then you could call it with or without array-member syntax, but you
 have to use parens. I don't see any conflict there.


The problem is that the definition of an array-member property getter 
is the same thing as the definition of a module-level property setter.



 Now, I don't know what -property is doing with it at the moment, but I don't
 see how it could work any other way.


Currently I think you can do this:

	import std.range;

	int[] array = [1, 2];
	int x = array.front; // fine
	int y = (front = a); // ???

And also you can't define array-member property setters because they 
take three arguments and three argument property functions are not 
allowed.

And also, in case of conflict, currently you can write 
`std.range.front(array)` to disambiguate, but how does that work with 
 property enforcement, probably not that well?


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Dec 13 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, December 13, 2011 12:14:37 Michel Fortin wrote:

 On 2011-12-13 16:57:33 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:

 On Tuesday, December 13, 2011 06:40:40 Michel Fortin wrote:

 On 2011-12-13 04:25:33 +0000, Jonathan M Davis <jmdavisProg gmx.com> 






said:

 For arrays, all you need to do is have the first argument be an
 array,
 and that works great for arrays, but arrays don't have much in the
 way
 of functions built in, so there's no conflict.


 
 Actually, there's still an open issue with array-member syntax and
  property used together.


 
 How so? If it's a property function, not a member function (which
 couldn't use array-member syntaxt anyway), and it takes an array as its
 first argument, then it _must_ be called with array-member syntax
 without parens. If it isn't a property, then you could call it with or
 without array-member syntax, but you have to use parens. I don't see
 any conflict there.


 
 The problem is that the definition of an array-member property getter
 is the same thing as the definition of a module-level property setter.


I forgot about that, though I never liked the idea of module-level properties 
in the first place.


 Now, I don't know what -property is doing with it at the moment, but I
 don't see how it could work any other way.


 
 Currently I think you can do this:
 
 import std.range;
 
 int[] array = [1, 2];
 int x = array.front; // fine
 int y = (front = a); // ???
 
 And also you can't define array-member property setters because they
 take three arguments and three argument property functions are not
 allowed.


You mean calling a property function on an element in an array? I would only 
have expected that to work if the element type had such a property. I wouldn't 
ever have expected you to be able to declare a property for arrays which 
allowed you to call it as a property on the array's elements.


 And also, in case of conflict, currently you can write
 `std.range.front(array)` to disambiguate, but how does that work with
  property enforcement, probably not that well?


Disambiguate with what? With a module-level property? As it stands, I expect 
that module-level properties which are arrays just wouldn't work.

- Jonathan M Davis
Dec 13 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-12-13 18:13:38 +0000, "Jonathan M Davis" <jmdavisProg gmx.com> said:


 On Tuesday, December 13, 2011 12:14:37 Michel Fortin wrote:

 On 2011-12-13 16:57:33 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:

 Now, I don't know what -property is doing with it at the moment, but I
 don't see how it could work any other way.


 
 Currently I think you can do this:
 
 import std.range;
 
 int[] array = [1, 2];
 int x = array.front; // fine
 int y = (front = a); // ???
 
 And also you can't define array-member property setters because they
 take three arguments and three argument property functions are not
 allowed.


 
 You mean calling a property function on an element in an array? I would only
 have expected that to work if the element type had such a property. I wouldn't
 ever have expected you to be able to declare a property for arrays which
 allowed you to call it as a property on the array's elements.


Oops. That was a typo. I meant (front = array). "a" is undefined in the 
example above.



 And also, in case of conflict, currently you can write
 `std.range.front(array)` to disambiguate, but how does that work with
  property enforcement, probably not that well?


 
 Disambiguate with what? With a module-level property? As it stands, I expect
 that module-level properties which are arrays just wouldn't work.


Say you have a array-member property called "front" defined in 
std.range (not hard to imagine) and an identical property called 
"front" in another module and you import both modules: "array.front" 
becomes ambiguous. With the function call syntax you can write 
std.range.front(array) and other.module.front(array) as a substitute to 
the property syntax to disambiguate, but if the property syntax is 
enforced should calling the property as a function still be allowed for 
array-member functions? Or should we invent a syntax such as 
array.(other.module.front)?

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Dec 13 2011
next sibling parent "F i L" <witte2008 gmail.com> writes:
Michel Fortin wrote:

 Or should we invent a syntax such as array.(other.module.front)?


I think the syntax should be:
array.(~[{*&=>other.module.front}])();


no, in all honesty is there a reason the syntax you came up with 
wouldn't work?

    module foo;

    struct Foo {
        void bar() { ... }
    }

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    import foo;
    import a, b; // both define Foo.bar()

    void main() {
        auto foo = Foo();
        foo.bar();     // internal member
        foo.(a.foo)(); // module a
    }
Dec 13 2011
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, December 13, 2011 16:35:08 Michel Fortin wrote:

 Say you have a array-member property called "front" defined in
 std.range (not hard to imagine) and an identical property called
 "front" in another module and you import both modules: "array.front"
 becomes ambiguous. With the function call syntax you can write
 std.range.front(array) and other.module.front(array) as a substitute to
 the property syntax to disambiguate, but if the property syntax is
 enforced should calling the property as a function still be allowed for
 array-member functions? Or should we invent a syntax such as
 array.(other.module.front)?


Hmmm. Obviously, we either end up with a function that can't be called due to 
an ambiguity, or we need to find a way to resolve the ambiguity. And to resolve 
the ambiguity, we'd either have to allow for the property function to be 
called as a normal function or introduce a new syntax. Bleh.

The simplest solution would be to simply have the function callable as a non-
property function when there's such an ambiguity, but that does go against the 
whole "require a property function to be used as a property" thing. Your 
suggested syntax is pretty good, but it's not exactly a desirable solution 
either. I don't know. Given the simplicity of it and the fact that there's no 
way that you're going to change the property function to a member variable 
(since it's not like you can add it to arrays), allowing for it to be called 
as normal function seems like the better solution, albeit not exactly ideal. 
Free functions definitely complicate the whole property thing.

- Jonathan M Davis
Dec 13 2011
parent reply "F i L" <witte2008 gmail.com> writes:
Jonathan M Davis wrote:

 The simplest solution would be to simply have the function 
 callable as a non-
 property function when there's such an ambiguity, but that does 
 go against the whole "require a property function to be used as 
 a property" thing. Your suggested syntax is pretty good, but 
 it's not exactly a desirable solution either. I don't know. 
 Given the simplicity of it and the fact that there's no way 
 that you're going to change the property function to a member 
 variable (since it's not like you can add it to arrays), 
 allowing for it to be called as normal function seems like the 
 better solution, albeit not exactly ideal. Free functions 
 definitely complicate the whole property thing.

 - Jonathan M Davis


Honestly I'm kind of a fan of having any method with zero or one 
parameters being usable as properties or methods at the 
programmer's discretion. Then conflicting pseudo methods could 
just be resolved through normal method semantics as you 
described. But I understand this is being removed so there must 
be a reason for it.

To bad the comma was used as new-line or we could remove the 
zero-or-one requirement all together and have Go-like return 
semantics:

    void foo(string a, int b, float c) { ... }

    float, float up() {
        return 0f, 1f;
    }

    void main() {
        foo = "bar", 1, 2.0f;
        float x, y = up;
    }

Of course, changing the language around like that is obviously 
not a realistic option. So this is just pointless speculation.
Dec 13 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, December 14, 2011 03:45:35 F i L wrote:

 Jonathan M Davis wrote:

 The simplest solution would be to simply have the function
 callable as a non-
 property function when there's such an ambiguity, but that does
 go against the whole "require a property function to be used as
 a property" thing. Your suggested syntax is pretty good, but
 it's not exactly a desirable solution either. I don't know.
 Given the simplicity of it and the fact that there's no way
 that you're going to change the property function to a member
 variable (since it's not like you can add it to arrays),
 allowing for it to be called as normal function seems like the
 better solution, albeit not exactly ideal. Free functions
 definitely complicate the whole property thing.
 
 - Jonathan M Davis


 
 Honestly I'm kind of a fan of having any method with zero or one
 parameters being usable as properties or methods at the
 programmer's discretion. Then conflicting pseudo methods could
 just be resolved through normal method semantics as you
 described. But I understand this is being removed so there must
 be a reason for it.


It was in part due to ambiguity with regards to delegates. Also, a fairly 
typical argument for properties is the ability to swap public member variables 
and property functions. That's not possible if you can't classify a function 
such that it _must_ be called as a property.

- Jonathan M Davis
Dec 13 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/14/2011 06:25 AM, Jonathan M Davis wrote:

 On Wednesday, December 14, 2011 03:45:35 F i L wrote:

 Jonathan M Davis wrote:

 The simplest solution would be to simply have the function
 callable as a non-
 property function when there's such an ambiguity, but that does
 go against the whole "require a property function to be used as
 a property" thing. Your suggested syntax is pretty good, but
 it's not exactly a desirable solution either. I don't know.
 Given the simplicity of it and the fact that there's no way
 that you're going to change the property function to a member
 variable (since it's not like you can add it to arrays),
 allowing for it to be called as normal function seems like the
 better solution, albeit not exactly ideal. Free functions
 definitely complicate the whole property thing.

 - Jonathan M Davis


 Honestly I'm kind of a fan of having any method with zero or one
 parameters being usable as properties or methods at the
 programmer's discretion. Then conflicting pseudo methods could
 just be resolved through normal method semantics as you
 described. But I understand this is being removed so there must
 be a reason for it.


 It was in part due to ambiguity with regards to delegates. Also, a fairly
 typical argument for properties is the ability to swap public member variables
 and property functions. That's not possible if you can't classify a function
 such that it _must_ be called as a property.

 - Jonathan M Davis


The transition most of the time goes field -> property. Then it is not 
necessary at all. I think proper properties > implicit properties = no 
properties > implicit properties with enforcement.
Dec 14 2011