Re: dmd 2.057 release
On Wednesday, December 14, 2011 08:09:53 Bernard Helyer wrote: Changelog isn't showing up for me. Walter does the release, but Andrei updates the site. So, there's always a delay after a release before the site is updated. - Jonathan M Davis
Re: dmd 2.057 release
On 14.12.2011 11:05, Walter Bright wrote:
Highlights are use of XMM floating point registers in 64 bit targets,
and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best release
ever. Thanks!
Indeed.
Yet I have to issue yet another warning about new std.regex compared
with old one:
import std.stdio;
import std.regex;
void main() {
string src = 4.5.1;
foreach (c; match(src, regex(r(\d+
writeln(c.hit);
}
previously this will find all matches, now it finds only first one. To
get all of matches use g option.
Seems like 100% compatibility was next to impossible.
--
Dmitry Olshansky
Re: dmd 2.057 release
On 2011-12-14 08:05, Walter Bright wrote: Highlights are use of XMM floating point registers in 64 bit targets, and now supporting OS X 64 as a target. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.057.zip A lot of people put a ton of effort into making this D's best release ever. Thanks! That's an impressive number of bug fixes and new features, nice. -- /Jacob Carlborg
Re: D1 dmd 1.072 release
On 2011-12-11 00:05, Walter Bright wrote: Highlights are use of XMM floating point registers in 64 bit targets, and now supporting OS X 64 as a target. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.072.zip The D2 version will follow in a few days, as those following the D n.g. know. A solid release as always. Nice to see 64bit Mac OS X target and new CTFE features. -- /Jacob Carlborg
Re: dmd 2.057 release
On 2011-12-14 08:05, Walter Bright wrote:
Highlights are use of XMM floating point registers in 64 bit targets,
and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best release
ever. Thanks!
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable using
argument types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type
Foo[] to Object[]
Have I missed something, I can't find this in the changelog?
--
/Jacob Carlborg
Re: dmd 2.057 release
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the object
slicing problem. The thing is, main() expects b to be an array of Foo's. If
foo() replaces one of the array elements with an Object, then b is no longer an
array of Foo's, and can crash.
Note that if you write foo as:
void foo(const(Object)[] a)
it will work.
Re: New homepage design of d-p-l.org is now live. eom
On 12/12/11 7:46 PM, Stewart Gordon wrote: On 06/12/2011 05:44, Andrei Alexandrescu wrote: http://d-p-l.org Andrei Why does it have an HTML 4.01 doctype but then go on to use XHTML syntax??? Stewart. I wouldn't know. What needs to be done? Andrei
Re: dmd 2.057 release
On 12/14/11 1:44 AM, Walter Bright wrote: On 12/13/2011 11:18 PM, Jacob Carlborg wrote: On 2011-12-14 08:09, Bernard Helyer wrote: Changelog isn't showing up for me. Same here, latest change log is 2.056, which is empty. Andrei's working on uploading it. Sorry about the delay. Yah, sorry. Andrei
Re: dmd 2.057 release
On 12/14/11 1:05 AM, Walter Bright wrote: Highlights are use of XMM floating point registers in 64 bit targets, and now supporting OS X 64 as a target. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.057.zip A lot of people put a ton of effort into making this D's best release ever. Thanks! Many thanks to all participants for this awesome release and in particular for the intense pace of the past few days! Andrei
Re: New homepage design of d-p-l.org is now live. eom
On 14/12/2011 10:12, Andrei Alexandrescu wrote: On 12/12/11 7:46 PM, Stewart Gordon wrote: On 06/12/2011 05:44, Andrei Alexandrescu wrote: http://d-p-l.org Andrei Why does it have an HTML 4.01 doctype but then go on to use XHTML syntax??? Stewart. I wouldn't know. What needs to be done? Andrei http://validator.w3.org/check?uri=http%3A%2F%2Fwww.d-programming-language.org%2Fcharset=%28detect+automatically%29doctype=Inlinegroup=0 ( http://goo.gl/pxtQE - the same link, just in case the above one gets wrapped and doesn't work) Basically, xHTML uses foobar /, html uses foobar or foobar/foobar depending on the tag. The rest of the issues are with non-standard tags, eg nobr and font I think. -- Robert http://octarineparrot.com/
Re: dmd 2.057 release
On 2011-12-14 11:10, Walter Bright wrote:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable
using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type
Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the
object slicing problem. The thing is, main() expects b to be an array of
Foo's. If foo() replaces one of the array elements with an Object, then
b is no longer an array of Foo's, and can crash.
I think it would be good if it's in the changelog, even if there is no
bugzilla entry for it.
Note that if you write foo as:
void foo(const(Object)[] a)
it will work.
Ok, thanks.
--
/Jacob Carlborg
Re: dmd 2.057 release
Jacob Carlborg:
What happened to arrays in this release:
They have closed a significant D2 hole.
As Walter has explained, this code used to compile fine and then crash at
runtime:
class Foo {
void spam() {}
}
class Bar {}
void foo(Object[] a) {
a[0] = new Bar;
}
void main() {
Foo[] b = [new Foo];
foo(b);
b[0].spam(); // crash
}
Now instead it gives this at compile-time:
test.d(10): Error: function test.foo (Object[] a) is not callable using
argument types (Foo[])
test.d(10): Error: cannot implicitly convert expression (b) of type Foo[] to
Object[]
Now a modified foo is accepted if its 'a' argoment is constant, because you
can't modify the array contents (unless you cast away const):
class Foo {
void spam() {}
}
void foo(const(Object[]) a) {
}
void main() {
Foo[] b = [new Foo];
foo(b);
}
This Java code compiles with no errors:
class Foo {
Foo() {}
void spam() {}
}
class Bar {
Bar() {}
}
class Test {
static void foo(Object[] a) {
a[0] = new Bar(); // line 10, runtime error here
}
public static void main(String[] args) {
Foo[] b = {new Foo()};
Test.foo(b);
b[0].spam(); // line 15
}
}
Instead of crashing at run-time at line 15, it raises a
java.lang.ArrayStoreException at runtime at line 10, where at runtime it tests
that in a[0] you put a Foo() instead of something else like a Bar() or
Object(). So (in theory) the JavaVM has to perform a runtime test every time
you perform an assignment of a class reference to an array cell.
Bye,
bearophile
Re: dmd 2.057 release
Am 14.12.2011 08:05, schrieb Walter Bright:
Highlights are use of XMM floating point registers in 64 bit targets,
and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best release
ever. Thanks!
I have a strange crash of the new dmd 2.057 compiler.
I am running the compiler from inside VisualD. In debug mode the code
compiles fine. In release mode the compiler crashes and Windows starts
the Just-In-Time-Debugger saying that there is an unhandled exception
inside dmd.exe.
as a side note: the same code did compile with 2.056 !
When I try to find the source of the error it gets really funky strange:
int main(string[] argv)
{
writeln(Hello D-World!);
auto i = uniform(0, 15); // line A
auto c = 0;
if (c++ c) // line B
writeln(Why did they call it c++); // line C
//writeln(bench!(doStringTest)); // line D
//writeln(bench!(doBench1)); // line E
//writeln(bench!(doBench2)); // line F
//writeln(bench!(doBench3)); // line G
// main1(argv); // line I
// return 0; // line J
//} // line K
//int main1(string[] argv)// line L
//{ // line M
... much more code
}
- the code above crashes
- when I comment out line A it compiles
- when I leave A comment out B and C - dmd gets into an endless loop (
I waited several minutes for the process to terminate)
- when I leave A and uncomment I to M it compiles
- when I uncomment A to G it compiles
- when I uncomment A to F it crashes
now I tried the following:
int main(string[] argv)
{
writeln(Hello D-World!);
auto i = uniform(0, 15); // line A
auto c = 0;
if (c++ c) // line B
writeln(Why did they call it c++); // line C
//writeln(bench!(doStringTest)); // line D
//writeln(bench!(doBench1)); // line E
//writeln(bench!(doBench2)); // line F
//writeln(bench!(doBench3)); // line G
main1(argv); // line I
return 0; // line J
} // line K
int main1(string[] argv)// line L
{ // line M
... much more code
}
- as soon as I uncomment line G it compiles with any combination of line
D to F uncommented
- when line G is commented out any combination of line D to F
uncommented crashes.
- when I comment out line I any other combination compiles
I really would like to find a minimal stripped down version of the code,
but as soon as I try to find it, the behavior changes.
Re: dmd 2.057 release
Ideally, every nontrivial change should have a bugzilla entry, even if that
means its created by whoever made the change. It's too easy to miss things
otherwise.
Sent from my iPhone
On Dec 14, 2011, at 3:11 AM, Jacob Carlborg d...@me.com wrote:
On 2011-12-14 11:10, Walter Bright wrote:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable
using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type
Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the
object slicing problem. The thing is, main() expects b to be an array of
Foo's. If foo() replaces one of the array elements with an Object, then
b is no longer an array of Foo's, and can crash.
I think it would be good if it's in the changelog, even if there is no
bugzilla entry for it.
Note that if you write foo as:
void foo(const(Object)[] a)
it will work.
Ok, thanks.
--
/Jacob Carlborg
Re: dmd 2.057 release
On Wednesday, December 14, 2011 12:11:03 Jacob Carlborg wrote:
On 2011-12-14 11:10, Walter Bright wrote:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable
using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type
Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the
object slicing problem. The thing is, main() expects b to be an array of
Foo's. If foo() replaces one of the array elements with an Object, then
b is no longer an array of Foo's, and can crash.
I think it would be good if it's in the changelog, even if there is no
bugzilla entry for it.
It's the first dmd bug on the list:
http://d.puremagic.com/issues/show_bug.cgi?id=2095
- Jonathan M Davis
Re: dmd 2.057 release
On 12/14/2011 6:59 AM, Adrian wrote: I have a strange crash of the new dmd 2.057 compiler. I can't do anything without a reproducible test case.
Re: dmd 2.057 release
On 14/12/11 7:05 AM, Walter Bright wrote: Highlights are use of XMM floating point registers in 64 bit targets, and now supporting OS X 64 as a target. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.057.zip A lot of people put a ton of effort into making this D's best release ever. Thanks! Great release. 64-bit OSX is working for my project without any problems. Had to change some uint's to size_t's and fix some inline asm but everything was fine after that :-)
Re: dmd 2.057 release
Am 14.12.2011 18:57, schrieb Walter Bright: On 12/14/2011 6:59 AM, Adrian wrote: I have a strange crash of the new dmd 2.057 compiler. I can't do anything without a reproducible test case. If you want, I can sent you the whole source. Its nothing real important, because I am playing around with D and porting some code to test. Adrian.
Re: dmd 2.057 release
On 2011-12-14 18:00, Jonathan M Davis wrote:
On Wednesday, December 14, 2011 12:11:03 Jacob Carlborg wrote:
On 2011-12-14 11:10, Walter Bright wrote:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable
using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type
Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the
object slicing problem. The thing is, main() expects b to be an array of
Foo's. If foo() replaces one of the array elements with an Object, then
b is no longer an array of Foo's, and can crash.
I think it would be good if it's in the changelog, even if there is no
bugzilla entry for it.
It's the first dmd bug on the list:
http://d.puremagic.com/issues/show_bug.cgi?id=2095
- Jonathan M Davis
I see, thanks. I was search for array on the changelog page.
--
/Jacob Carlborg
Re: dmd 2.057 release
On Thursday, December 15, 2011 08:19:39 Jacob Carlborg wrote:
On 2011-12-14 18:00, Jonathan M Davis wrote:
On Wednesday, December 14, 2011 12:11:03 Jacob Carlborg wrote:
On 2011-12-14 11:10, Walter Bright wrote:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable
using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of
type
Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the
object slicing problem. The thing is, main() expects b to be an
array of Foo's. If foo() replaces one of the array elements with an
Object, then b is no longer an array of Foo's, and can crash.
I think it would be good if it's in the changelog, even if there is no
bugzilla entry for it.
It's the first dmd bug on the list:
http://d.puremagic.com/issues/show_bug.cgi?id=2095
- Jonathan M Davis
I see, thanks. I was search for array on the changelog page.
The names of bug reports are frequently not particularly informative, and even
if they are, they frequently don't contain the necessary information to
understand the effects of fixing the bug. If you want to actually know what's
really being fixed, you frequently have to actually read all of the bug reports
rather than looking at their titles.
- Jonathan M Davis
Re: D1 to be discontinued on December 31, 2012
On 12/13/2011 11:29 PM, Jacob Carlborg wrote: Then let me say: I still use D1 for all my projects. I hear you. What can we do to make this work for you?
Re: D1 to be discontinued on December 31, 2012
On Saturday, 10 December 2011 at 21:19:02 UTC, Andrei Alexandrescu wrote: Hello everyone, With all respect to you Andrei, you had no input in D1, I thought that if D1 support will be ever dropped, Walter will announce it. Well... In my humble opinion D1 community is still active. Assuming that nobody uses it is wrong. Walter, thanks for good job on it! I will still stick to it for any serious project (non-hobby ones). I wish you good luck with bringing D2 stable. I just hope I will see such official news from you. Best regards, Damian Ziemba
Re: Tango for D2 (Was: D1 to be discontinued on December 31, 2012)
On 12/13/2011 11:26 PM, Jacob Carlborg wrote: Look no further than Array in the dmd sources :-) That always made me wonder. Is that an array just used internally by DMD or something related to D arrays, or both? Array predates usable C++ compilers.
Re: D1 to be discontinued on December 31, 2012
On 12/13/2011 11:27 PM, Jacob Carlborg wrote: On 2011-12-13 21:47, torhu wrote: I'm still using DMD 1.061, since there are very few remaining serious compiler bugs. The compiler has gotten pretty good, so the incentive to upgrade is not very strong. And I rarely need to ask questions about D1, since I've been using it for 5 years now. It's the same for me. But when I do ask questions everyone is surprised that I use D1. Well, since torhu is using 1.061 and appears to be happy with it, it doesn't look like he needs continuing support. Also, D1 isn't going to vanish in a puff of smoke. It'll still be there on github and on the web site.
Re: D1 to be discontinued on December 31, 2012
On 12/14/11 1:59 AM, Damian Ziemba wrote: On Saturday, 10 December 2011 at 21:19:02 UTC, Andrei Alexandrescu wrote: Hello everyone, With all respect to you Andrei, you had no input in D1, I thought that if D1 support will be ever dropped, Walter will announce it. Well... In my humble opinion D1 community is still active. Is there an online hang out place for the community - a forum? Assuming that nobody uses it is wrong. I am not assuming that. Thanks, Andrei
Re: D1 to be discontinued on December 31, 2012
On 12/14/11 1:44 AM, Jacob Carlborg wrote: On 2011-12-14 00:03, Andrei Alexandrescu wrote: On 12/13/11 3:00 PM, Jacob Carlborg wrote: I think it's selfish to decide for the hole community. Well the word selfish is not appropriate here because the decision does not bring me any benefit. Perhaps you meant arrogant or conceited. I don't know that you're trying to achieve but it seems you trying to erase D1 from the history, pretending it never happened. How does announcing cease of support (not retiring the product) more than one year in advance equate with attempting to erase a product from history? Thanks, Andrei
Re: D1 to be discontinued on December 31, 2012
On 12/14/11 1:35 AM, Jacob Carlborg wrote: No. It's not so much about the result (because I know basically everyone would vote to discontinue the D1 support), it's more about the attitude and the way it's handled. How would you have handled the situation if you were in our place? Thanks, Andrei
Re: D1 to be discontinued on December 31, 2012
On 12/14/11 1:42 AM, Jacob Carlborg wrote: I understand how you might see things that way, but please trust me on this one. It is the right thing do do, and the short-term difficulty will be greatly rewarded in the long run. Probably, but as with the rest of the development of D2 everything happen to fast. TDPL was released without a compiler backing up all the features. Also no one knows what the correct behavior of a features is, what's in TDPL, what's in the compiler or what's in the spec. That would have been a great point if the announcement used the date of December 31 of this year. Andrei
Re: Fixing const arrays
On 12/14/2011 12:35 AM, Peter Alexander wrote: On 13/12/11 11:11 PM, Timon Gehr wrote: On 12/14/2011 12:14 AM, Peter Alexander wrote: On 13/12/11 10:17 PM, Vladimir Panteleev wrote: On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu wrote: There's a phrase in Romanian that quite applies: From the lake into the well. I believe the English version is Out of the frying pan, into the fire :) Inconsequential space-filler opinion: I am OK with @property, mainly because it's a common feature among PLs, it's better than nothing, and don't know better solutions. In my opinion, it's not better than nothing. What it gives you: 1. A bit of syntactic sugar. 2. The ability to refactor member look up easily. What it costs: 1. Overloads syntax. a. obj.field can now be an arbitrary function call. b. May have arbitrary cost (e.g. T[].length) ??? T[].length is a field access, not a property function. It takes a small constant amount of time. Assigning to the length of an array may reallocate it, which is not a small, nor constant amount of time. int[] a; ... a.length = n; // may invoke a GC allocation + O(n) memcpy OK, I see, thanks. I don't think it is problematic in this particular case though.
Re: Fixing const arrays
On 13.12.2011 23:17, Vladimir Panteleev wrote: On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu wrote: There's a phrase in Romanian that quite applies: From the lake into the well. I believe the English version is Out of the frying pan, into the fire :) The Norwegian version is From ashes to fire (direct translation) or From the ashes into the fire
Re: If I had my way
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.
Re: D1 to be discontinued on December 31, 2012
On 14.12.2011 05:37, Andrei Alexandrescu wrote: On 12/13/11 10:12 PM, Don wrote: On 13.12.2011 17:00, Andrei Alexandrescu wrote: On 12/13/11 7:52 AM, Don wrote: On 10.12.2011 22:19, Andrei Alexandrescu wrote: In order to increase focus and unity in the language, we are discontinuing support for D1 on December 31, 2012. That's more than one year away, which gives enough time to D1 users to migrate libraries and applications to D2. I thought we had moved away from these kinds of unilateral decisions. I strongly oppose this decision. In particlar, I find the lack of community consulatation deplorable. Apologies for this being so sudden. This was deliberate as there would have been no way to achieve consensus in the matter. People prefer having choices and postponement options, and are generous with others' time. Allow me to recap the reasons why I think this is a necessary move. 1. We can't serve two masters. Working on two languages at the same time was non-committal and artificially sustained a rift in the community. The rift was created and sustained by unilateral statements like this one. Abandoning half the community doesn't help. There is no abandonment. Also, where is that 50/50 estimate from? Just curious. The D2 community is definitely bigger than the D1 community. But how much more? It's hard to be sure, but the Tango users used to be 75% of the community, based on a few polls that were held, but they never had much representation on the ng. I guess between half and 2/3 are gone now. I don't think the entire D community is as big as it was back then (based on number of public repositories). Additionally, the number of contributors, and level of activity, in Tango, was higher than Phobos has ever had. It also diffused our focus, delayed us to an ever-increasing extent, What on earth gives you that idea? The only resources involved are some fraction of Walter's time, which is obviously an important resource, but nobody other than Walter is affected. Walter told me so, and Walter is the single most important bottleneck. So us means Walter? You're seriously misrepresenting the situation. What is an accurate representation of the situation, and what evidence is there to back that up? This is an issue of Walter's time, and nothing more. I think the evidence for that is clear -- who else is spending time on D1? Important thing to notice: GDC and LDC also have D1 compilers. Does this decision apply to them? I spend some time on fixing D1 bugs, but that won't change, see below. and sent the wrong message out that we're lacking confidence of what our core thrust is, so we're trying to sort of please everyone. (Here's our flagship language! If you don't like it, well, we have another one.) This is a silly and offensive statement. Most languages are in this situation. Look at Python2 vs Python3, Perl6 vs Perl5. I wonder who would be offended by that. Other than me? Well, I think the Python guys would be offended if you said it of them. 2. The deadline is more than a year away. This is a long time, enough for us to make D2 compelling, and also for interested people to migrate. No, it's an exceedingly short timeframe. Other vendors give similar time scale for much larger migrations. Only when the migration is to a mature product. What gives you the idea that nobody is using D1? There is not one sentence in my message claiming nobody is using D1. Ok, I can't make sense of it otherwise. Don, it is you who is misrepresenting the situation, and repeatedly. I understand you find this frustrating, but please, let's have a constructive dialog. Have you thought about what would convince them to switch to D2, and what would be required for them to do it? I think the most important aspect for them would be completion of Tango's port to D2. The recent progress in the matter is encouraging. If the D1 community is sizable, resourceful, and interested, I believe that to be within the realm of possibility. At the present time, do they actually desire to move to D2? If not, why not? And the big one: are they confident that D2 is sufficiently stable? I suspect you don't know much about the D1 community. (Note that only a small fraction of D users have ever used the newsgroup, and it's mostly people with an interest in language design. They are not representative). I can already say with certainty that I will still be using D1 in 2013. That's great. The decision does not make it impossible or even particularly difficult for D1 users to continue using D1. Since there were near zero bug reports on D1, There are 400 open bugzilla D1 + common D1/D2 compiler bugs in Bugzilla, including nearly all of the heavily voted bugs. D1 is very much more stable than D2 (D2 has 800 open bugs), so there are far fewer bug reports. If you mean, there were no bug reports on the beta, that's not suprising, there are no D1 Phobos changes, which is where
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 08:35, Gour wrote: Compiler is free, everyone can contribute if they like...it's (almost) like in many other open-source projects... The few times I've contributed to the compiler I've sent a patch or a pull request and the end result is that nothing happens. If I'm lucky I get a few comments, I answer them and then nothing. -- /Jacob Carlborg
Re: Sitemap
Is there a sitemap.xml for search engine? http://www.sitemaps.org/protocol.html Il giorno mar, 13/12/2011 alle 14.22 -0600, Andrei Alexandrescu ha scritto: On 12/13/11 6:50 AM, Somedude wrote: Le 12/12/2011 20:52, Andrei Alexandrescu a écrit : I've added a sitemap to the website: http://dlang.org/sitemap.html I've already removed a bunch of obsolete documents. Feel free to look around and report bugs for various pages. Thanks, Andrei Also, I just noticed that the v2.056 changelog is empty. Walter? I'm not sure what the process of stitching the changelog together is. We need to integrate it with the website build process. Andrei
Re: Fixing const arrays
Jonathan M Davis: I tend to avoid const ranges precisely because they pretty much never work. I'd use them more if a tail-const version of them were easily obtainable - This is what I was trying to answer to Andrei :-) Bye, bearophile
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 08:56, Walter Bright wrote: On 12/13/2011 11:29 PM, Jacob Carlborg wrote: Then let me say: I still use D1 for all my projects. I hear you. What can we do to make this work for you? I think it's too soon to discontinue the support for D1. I would hope that we could continue like this, having D1 in maintenance mode, for a while longer. -- /Jacob Carlborg
Re: Some standard protocols in Phobos
Jesse Phillips: The others, I'm not sure what it is solving that isn't addressed by actually having it in Phobos (Why not have matrices and not just their protocol?). The focus of my post was mostly on the protocol for images. The problem with having actual code in Phobos is that a good matrix library, or a good image library, is a lot of well written code. And it can't be good enough for everyone, so other people will want to invent other image or matrix libraries. The point of having a protocol in Phobos is to avoid giving too much work to Phobos devs, and at the same time have a standard API to use a matrix or image. Bye, bearophile
Re: D1 to be discontinued on December 31, 2012
I use dwt and tango for some project recent. Before dwt2 and minid and other cool project is ready for d2, I will still need D1. On 13 December 2011 21:52, Don nos...@nospam.com wrote: On 10.12.2011 22:19, Andrei Alexandrescu wrote: In order to increase focus and unity in the language, we are discontinuing support for D1 on December 31, 2012. That's more than one year away, which gives enough time to D1 users to migrate libraries and applications to D2. I thought we had moved away from these kinds of unilateral decisions. I strongly oppose this decision. In particlar, I find the lack of community consulatation deplorable.
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 09:11, Andrei Alexandrescu wrote: On 12/14/11 1:42 AM, Jacob Carlborg wrote: I understand how you might see things that way, but please trust me on this one. It is the right thing do do, and the short-term difficulty will be greatly rewarded in the long run. Probably, but as with the rest of the development of D2 everything happen to fast. TDPL was released without a compiler backing up all the features. Also no one knows what the correct behavior of a features is, what's in TDPL, what's in the compiler or what's in the spec. That would have been a great point if the announcement used the date of December 31 of this year. Andrei It's still too soon because no one will know in what sate D2 is from a year from now. -- /Jacob Carlborg
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 09:09, Andrei Alexandrescu wrote: On 12/14/11 1:44 AM, Jacob Carlborg wrote: On 2011-12-14 00:03, Andrei Alexandrescu wrote: On 12/13/11 3:00 PM, Jacob Carlborg wrote: I think it's selfish to decide for the hole community. Well the word selfish is not appropriate here because the decision does not bring me any benefit. Perhaps you meant arrogant or conceited. I don't know that you're trying to achieve but it seems you trying to erase D1 from the history, pretending it never happened. How does announcing cease of support (not retiring the product) more than one year in advance equate with attempting to erase a product from history? That's the attitude you seem to have sometimes. Saying that D1 isn't usable because it lacks features. D1 is usable, something I couldn't say as much about D2. -- /Jacob Carlborg
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 09:03, Walter Bright wrote: On 12/13/2011 11:27 PM, Jacob Carlborg wrote: On 2011-12-13 21:47, torhu wrote: I'm still using DMD 1.061, since there are very few remaining serious compiler bugs. The compiler has gotten pretty good, so the incentive to upgrade is not very strong. And I rarely need to ask questions about D1, since I've been using it for 5 years now. It's the same for me. But when I do ask questions everyone is surprised that I use D1. Well, since torhu is using 1.061 and appears to be happy with it, it doesn't look like he needs continuing support. I would probably get by without support. But there are a few features I would really like before the development on D1 ends. I'm thinking particular on dynamic libraries. The latest release was a great release which brought 64bit support to Mac OS X and new CTFE features. I wouldn't won't to miss that because I'm using D1. It seems CTFE is still not completely finished and I think it's sad that every feature in D1 won't be implemented. Also, D1 isn't going to vanish in a puff of smoke. It'll still be there on github and on the web site. I know that. -- /Jacob Carlborg
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 09:13, Andrei Alexandrescu wrote: On 12/14/11 1:35 AM, Jacob Carlborg wrote: No. It's not so much about the result (because I know basically everyone would vote to discontinue the D1 support), it's more about the attitude and the way it's handled. How would you have handled the situation if you were in our place? I would first wait longer, until D2 and Phobos is in a more usable state. Then I would first bring up the ideas you and Walter have to the community before anything is decided. -- /Jacob Carlborg
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 09:30, Don wrote: On 14.12.2011 05:37, Andrei Alexandrescu wrote: On 12/13/11 10:12 PM, Don wrote: On 13.12.2011 17:00, Andrei Alexandrescu wrote: On 12/13/11 7:52 AM, Don wrote: On 10.12.2011 22:19, Andrei Alexandrescu wrote: In order to increase focus and unity in the language, we are discontinuing support for D1 on December 31, 2012. That's more than one year away, which gives enough time to D1 users to migrate libraries and applications to D2. I thought we had moved away from these kinds of unilateral decisions. I strongly oppose this decision. In particlar, I find the lack of community consulatation deplorable. Apologies for this being so sudden. This was deliberate as there would have been no way to achieve consensus in the matter. People prefer having choices and postponement options, and are generous with others' time. Allow me to recap the reasons why I think this is a necessary move. 1. We can't serve two masters. Working on two languages at the same time was non-committal and artificially sustained a rift in the community. The rift was created and sustained by unilateral statements like this one. Abandoning half the community doesn't help. There is no abandonment. Also, where is that 50/50 estimate from? Just curious. The D2 community is definitely bigger than the D1 community. But how much more? It's hard to be sure, but the Tango users used to be 75% of the community, based on a few polls that were held, but they never had much representation on the ng. I guess between half and 2/3 are gone now. I don't think the entire D community is as big as it was back then (based on number of public repositories). Additionally, the number of contributors, and level of activity, in Tango, was higher than Phobos has ever had. It also diffused our focus, delayed us to an ever-increasing extent, What on earth gives you that idea? The only resources involved are some fraction of Walter's time, which is obviously an important resource, but nobody other than Walter is affected. Walter told me so, and Walter is the single most important bottleneck. So us means Walter? You're seriously misrepresenting the situation. What is an accurate representation of the situation, and what evidence is there to back that up? This is an issue of Walter's time, and nothing more. I think the evidence for that is clear -- who else is spending time on D1? Important thing to notice: GDC and LDC also have D1 compilers. Does this decision apply to them? I spend some time on fixing D1 bugs, but that won't change, see below. and sent the wrong message out that we're lacking confidence of what our core thrust is, so we're trying to sort of please everyone. (Here's our flagship language! If you don't like it, well, we have another one.) This is a silly and offensive statement. Most languages are in this situation. Look at Python2 vs Python3, Perl6 vs Perl5. I wonder who would be offended by that. Other than me? Well, I think the Python guys would be offended if you said it of them. 2. The deadline is more than a year away. This is a long time, enough for us to make D2 compelling, and also for interested people to migrate. No, it's an exceedingly short timeframe. Other vendors give similar time scale for much larger migrations. Only when the migration is to a mature product. What gives you the idea that nobody is using D1? There is not one sentence in my message claiming nobody is using D1. Ok, I can't make sense of it otherwise. Don, it is you who is misrepresenting the situation, and repeatedly. I understand you find this frustrating, but please, let's have a constructive dialog. Have you thought about what would convince them to switch to D2, and what would be required for them to do it? I think the most important aspect for them would be completion of Tango's port to D2. The recent progress in the matter is encouraging. If the D1 community is sizable, resourceful, and interested, I believe that to be within the realm of possibility. At the present time, do they actually desire to move to D2? If not, why not? And the big one: are they confident that D2 is sufficiently stable? I suspect you don't know much about the D1 community. (Note that only a small fraction of D users have ever used the newsgroup, and it's mostly people with an interest in language design. They are not representative). I can already say with certainty that I will still be using D1 in 2013. That's great. The decision does not make it impossible or even particularly difficult for D1 users to continue using D1. Since there were near zero bug reports on D1, There are 400 open bugzilla D1 + common D1/D2 compiler bugs in Bugzilla, including nearly all of the heavily voted bugs. D1 is very much more stable than D2 (D2 has 800 open bugs), so there are far fewer bug reports. If you mean, there were no bug reports on the beta, that's not suprising, there are no D1 Phobos changes, which
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 10:08, Long Chang wrote: I use dwt and tango for some project recent. Cool to here that's someone is using DWT. Before dwt2 and minid and other cool project is ready for d2, I will still need D1. Exactly and see, the D1 users start to pop up. On 13 December 2011 21:52, Donnos...@nospam.com wrote: On 10.12.2011 22:19, Andrei Alexandrescu wrote: In order to increase focus and unity in the language, we are discontinuing support for D1 on December 31, 2012. That's more than one year away, which gives enough time to D1 users to migrate libraries and applications to D2. I thought we had moved away from these kinds of unilateral decisions. I strongly oppose this decision. In particlar, I find the lack of community consulatation deplorable. -- /Jacob Carlborg
DMD 1.072 and DMD 2.057 64bit on Mac OS X
I just downloaded both 1.072 and 2.057. I see that 2.057 is compiled as a 64bit binary and 1.072 as a 32bit binary. Is there a reason for this difference? -- /Jacob Carlborg
Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X
On 12/14/2011 1:35 AM, Jacob Carlborg wrote: I just downloaded both 1.072 and 2.057. I see that 2.057 is compiled as a 64bit binary and 1.072 as a 32bit binary. Is there a reason for this difference? They should have both been 64 bit. Probably something wrong with my build script. My intent is to go all 64 bit for the OS X binaries. Apple stopped shipping 32 bit only Macs several years ago. While I intend to still build and test the 32 bit binaries, I see no point in shipping them.
Re: D1 to be discontinued on December 31, 2012
On 12/14/2011 1:06 AM, Jacob Carlborg wrote: But there are a few features I would really like before the development on D1 ends. I'm thinking particular on dynamic libraries. I am too. Shared library support is bubbling up on the priority list :-)
Re: D1 to be discontinued on December 31, 2012
On Wed, 14 Dec 2011 09:45:51 +0100 Jacob Carlborg d...@me.com wrote: The few times I've contributed to the compiler I've sent a patch or a pull request and the end result is that nothing happens. If I'm lucky I get a few comments, I answer them and then nothing. Heh, then fork it. ;) Well, the situation is that resources in D are still not everwhelming and every bit spent on D1, means less time for D2. Moreover, D2 brings features which makes embracing D much more compelling. OK, I was not here in the time of D1, but seeing D1's feature list, I wouldn't think it is so special to invest in learning using it. Another thing is I believe that Walter didn't delve in designing new language in order to be used for small hobby projects. Can you give me a list of some successful open-source projects written in D1 and/or some proprietary ones? Is there demand of paying support for D1? If not and if Walter prefers spending time on D2, I really do not understand why there is so much whining about it. If D1 wants to keep it, they're, afaict, free to do it. Is there anyone who can prevent Walter to write a post saying: I'm fed up with D community being busy with faultfinding all the time, not being grateful for the time effort I'm putting into it, so from TODAY I'm quitting all the work on D1 D2 and will focus on designing new X language? I remember him from Zortech C++ compiler which was my *first* commercial package I bought and remembering the set of manuals coming along in a greyish hard box, I was thrilled with all support I got...same with updates. Now he is working for free... Sincerely, Gour -- The spirit soul bewildered by the influence of false ego thinks himself the doer of activities that are in actuality carried out by the three modes of material nature. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: D1 to be discontinued on December 31, 2012
On 12/14/11 2:30 AM, Don wrote: On 14.12.2011 05:37, Andrei Alexandrescu wrote: There is no abandonment. Also, where is that 50/50 estimate from? Just curious. The D2 community is definitely bigger than the D1 community. But how much more? I presume it's quite a bit larger. But then both are small, and we're interested in the potential and the rate of adoption. It's hard to be sure, but the Tango users used to be 75% of the community, based on a few polls that were held, but they never had much representation on the ng. I guess between half and 2/3 are gone now. That seems a reasonable assessment. Possibly even more left. I don't think the entire D community is as big as it was back then (based on number of public repositories). That is also entirely possible. Additionally, the number of contributors, and level of activity, in Tango, was higher than Phobos has ever had. Agreed. But this is all missing the mark - why would we cry over spilled milk. The point is assessing the state of affairs the minute before the announcement. How active was Tango? How active were the Tango forums? Where were other forums of the D1 community? In this day and age, I'd be hard-pressed to think of an active programming language community that has no online presence whatsoever. To add to that, there was no trickle of bug reports or pull requests for D1, although clearly D1 does have its bugs and issues. I haven't followed Tango closely, but if D1 had a large active community, Tango would receive a lot of attention from its users as it's the de facto standard library for D1. Yet the last post (http://www.dsource.org/projects/tango/forums/topic/903) dates from March 30. The intervals between changes to the trunk (http://www.dsource.org/projects/tango/changeset/5691/) are measured in months. I hope you'll agree that one would be hard-pressed to infer from the evidence there is that there's a large, active, and thriving D1 community. It also diffused our focus, delayed us to an ever-increasing extent, What on earth gives you that idea? The only resources involved are some fraction of Walter's time, which is obviously an important resource, but nobody other than Walter is affected. Walter told me so, and Walter is the single most important bottleneck. So us means Walter? A delay originated by Walter delays the entire community. So by us I meant the community. You're seriously misrepresenting the situation. What is an accurate representation of the situation, and what evidence is there to back that up? This is an issue of Walter's time, and nothing more. Walter said that he'd rather not spend that time anymore. I think the evidence for that is clear -- who else is spending time on D1? As I mentioned, the larger issue is the message we're sending out. We can't serve two masters, and we need to focus and specialize our brand. Please trust me on this; in only a few short months I'm confident you will agree this will have been a good move. Important thing to notice: GDC and LDC also have D1 compilers. Does this decision apply to them? No. I spend some time on fixing D1 bugs, but that won't change, see below. and sent the wrong message out that we're lacking confidence of what our core thrust is, so we're trying to sort of please everyone. (Here's our flagship language! If you don't like it, well, we have another one.) This is a silly and offensive statement. Most languages are in this situation. Look at Python2 vs Python3, Perl6 vs Perl5. I wonder who would be offended by that. Other than me? Well, I think the Python guys would be offended if you said it of them. 2. The deadline is more than a year away. This is a long time, enough for us to make D2 compelling, and also for interested people to migrate. No, it's an exceedingly short timeframe. Other vendors give similar time scale for much larger migrations. Only when the migration is to a mature product. Agreed. All things considered, one year seems to me a resonable time frame. It's reasonable of you to disagree. Time will tell whom of us was right. What gives you the idea that nobody is using D1? There is not one sentence in my message claiming nobody is using D1. Ok, I can't make sense of it otherwise. Don, it is you who is misrepresenting the situation, and repeatedly. I understand you find this frustrating, but please, let's have a constructive dialog. Have you thought about what would convince them to switch to D2, and what would be required for them to do it? I think the most important aspect for them would be completion of Tango's port to D2. The recent progress in the matter is encouraging. If the D1 community is sizable, resourceful, and interested, I believe that to be within the realm of possibility. At the present time, do they actually desire to move to D2? If not, why not? And the big one: are they confident that D2 is sufficiently stable? I don't know what
Re: D1 to be discontinued on December 31, 2012
On 12/14/11 2:55 AM, Jacob Carlborg wrote: On 2011-12-14 08:56, Walter Bright wrote: On 12/13/2011 11:29 PM, Jacob Carlborg wrote: Then let me say: I still use D1 for all my projects. I hear you. What can we do to make this work for you? I think it's too soon to discontinue the support for D1. I would hope that we could continue like this, having D1 in maintenance mode, for a while longer. How long? Andrei
Re: Sitemap
On 12/14/11 2:48 AM, Andrea Fontana wrote: Is there a sitemap.xml for search engine? http://www.sitemaps.org/protocol.html There isn't but that sounds like a great idea and should be easy to do. See linux.mak in the website repo on how the sitemap is generated, and feel free to adapt that code to generate xml. Thanks, Andrei
Re: D1 to be discontinued on December 31, 2012
On 12/14/2011 12:30 AM, Don wrote: So, didn't sound then as though D1 was a big issue. Yet a month later you announce you've made a private decision about axing D1. Feels exactly like a military coup. Well, it wasn't one. The thing is, as I posted in this thread recently, there's little to no evidence of D1 interest - nobody responded to the beta, no posts about D1, no new bug reports about D1, no response to the new D1 releases (yes, Jacob just did a reply to it), etc. I feel like I was supporting D1 in a vacuum. I've been thinking about ending support for it for some time because of that. I don't know where the D1 community is, or even if it exists anymore.
Re: D1 to be discontinued on December 31, 2012
On 12/14/11 3:09 AM, Jacob Carlborg wrote: On 2011-12-14 09:09, Andrei Alexandrescu wrote: On 12/14/11 1:44 AM, Jacob Carlborg wrote: On 2011-12-14 00:03, Andrei Alexandrescu wrote: On 12/13/11 3:00 PM, Jacob Carlborg wrote: I think it's selfish to decide for the hole community. Well the word selfish is not appropriate here because the decision does not bring me any benefit. Perhaps you meant arrogant or conceited. I don't know that you're trying to achieve but it seems you trying to erase D1 from the history, pretending it never happened. How does announcing cease of support (not retiring the product) more than one year in advance equate with attempting to erase a product from history? That's the attitude you seem to have sometimes. Saying that D1 isn't usable because it lacks features. I didn't say that either! How can we sustain a conversation if you claim I say things I didn't? Andrei
Re: D1 to be discontinued on December 31, 2012
On 12/14/11 3:09 AM, Jacob Carlborg wrote: On 2011-12-14 09:11, Andrei Alexandrescu wrote: On 12/14/11 1:42 AM, Jacob Carlborg wrote: I understand how you might see things that way, but please trust me on this one. It is the right thing do do, and the short-term difficulty will be greatly rewarded in the long run. Probably, but as with the rest of the development of D2 everything happen to fast. TDPL was released without a compiler backing up all the features. Also no one knows what the correct behavior of a features is, what's in TDPL, what's in the compiler or what's in the spec. That would have been a great point if the announcement used the date of December 31 of this year. Andrei It's still too soon because no one will know in what sate D2 is from a year from now. I predict that one year from now D2 will be better than D1 and the Tango/D2 port will be better than Tango/D1. Andrei
Re: D1 to be discontinued on December 31, 2012
On 12/14/2011 12:45 AM, Jacob Carlborg wrote: The few times I've contributed to the compiler I've sent a patch or a pull request and the end result is that nothing happens. If I'm lucky I get a few comments, I answer them and then nothing. There's currently one open dmd pull request from you. Any others you've done have been incorporated. There are currently 68 open dmd pull requests and 490 closed/incorporated ones.
Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X
On 2011-12-14 10:39, Walter Bright wrote: On 12/14/2011 1:35 AM, Jacob Carlborg wrote: I just downloaded both 1.072 and 2.057. I see that 2.057 is compiled as a 64bit binary and 1.072 as a 32bit binary. Is there a reason for this difference? They should have both been 64 bit. Probably something wrong with my build script. My intent is to go all 64 bit for the OS X binaries. Apple stopped shipping 32 bit only Macs several years ago. While I intend to still build and test the 32 bit binaries, I see no point in shipping them. Yeah, I see no point with the 32bit binaries either. But the 64bit binaries target 64bit by default, that's how I noticed it, my code wasn't completely 64bit compatible. -- /Jacob Carlborg
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 10:40, Walter Bright wrote: On 12/14/2011 1:06 AM, Jacob Carlborg wrote: But there are a few features I would really like before the development on D1 ends. I'm thinking particular on dynamic libraries. I am too. Shared library support is bubbling up on the priority list :-) I'm glad to hear that. -- /Jacob Carlborg
Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X
On 12/14/2011 2:03 AM, Jacob Carlborg wrote: Yeah, I see no point with the 32bit binaries either. But the 64bit binaries target 64bit by default, that's how I noticed it, my code wasn't completely 64bit compatible. The default is set to match gcc's default.
Re: If I had my way
On Tue, 13 Dec 2011 20:14:58 +0100, Walter Bright newshou...@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.
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 10:46, Gour wrote: On Wed, 14 Dec 2011 09:45:51 +0100 Jacob Carlborgd...@me.com wrote: The few times I've contributed to the compiler I've sent a patch or a pull request and the end result is that nothing happens. If I'm lucky I get a few comments, I answer them and then nothing. Heh, then fork it. ;) I've already done that. But it's time consuming to keep up with the changes in upstream. Well, the situation is that resources in D are still not everwhelming and every bit spent on D1, means less time for D2. Moreover, D2 brings features which makes embracing D much more compelling. OK, I was not here in the time of D1, but seeing D1's feature list, I wouldn't think it is so special to invest in learning using it. Another thing is I believe that Walter didn't delve in designing new language in order to be used for small hobby projects. Can you give me a list of some successful open-source projects written in D1 and/or some proprietary ones? I don't know if all of them are successful but important: Tango, DWT, Minid, Orange, DVM, xfbuild to mention a few. Is there demand of paying support for D1? If not and if Walter prefers spending time on D2, I really do not understand why there is so much whining about it. If D1 wants to keep it, they're, afaict, free to do it. Is there anyone who can prevent Walter to write a post saying: I'm fed up with D community being busy with faultfinding all the time, not being grateful for the time effort I'm putting into it, so from TODAY I'm quitting all the work on D1 D2 and will focus on designing new X language? No I remember him from Zortech C++ compiler which was my *first* commercial package I bought and remembering the set of manuals coming along in a greyish hard box, I was thrilled with all support I got...same with updates. Now he is working for free... Sincerely, Gour -- /Jacob Carlborg
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 10:46, Andrei Alexandrescu wrote: On 12/14/11 2:30 AM, Don wrote: On 14.12.2011 05:37, Andrei Alexandrescu wrote: There is no abandonment. Also, where is that 50/50 estimate from? Just curious. The D2 community is definitely bigger than the D1 community. But how much more? I presume it's quite a bit larger. But then both are small, and we're interested in the potential and the rate of adoption. It's hard to be sure, but the Tango users used to be 75% of the community, based on a few polls that were held, but they never had much representation on the ng. I guess between half and 2/3 are gone now. That seems a reasonable assessment. Possibly even more left. I don't think the entire D community is as big as it was back then (based on number of public repositories). That is also entirely possible. Additionally, the number of contributors, and level of activity, in Tango, was higher than Phobos has ever had. Agreed. But this is all missing the mark - why would we cry over spilled milk. The point is assessing the state of affairs the minute before the announcement. How active was Tango? How active were the Tango forums? Where were other forums of the D1 community? In this day and age, I'd be hard-pressed to think of an active programming language community that has no online presence whatsoever. To add to that, there was no trickle of bug reports or pull requests for D1, although clearly D1 does have its bugs and issues. I haven't followed Tango closely, but if D1 had a large active community, Tango would receive a lot of attention from its users as it's the de facto standard library for D1. Yet the last post (http://www.dsource.org/projects/tango/forums/topic/903) dates from March 30. The intervals between changes to the trunk (http://www.dsource.org/projects/tango/changeset/5691/) are measured in months. The forum has never been very active. Lately there hasn't been that much activity as it used to be but the if you look at the timeline, the last event was 7 days ago. http://www.dsource.org/projects/tango/timeline -- /Jacob Carlborg
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 10:48, Andrei Alexandrescu wrote: On 12/14/11 2:55 AM, Jacob Carlborg wrote: On 2011-12-14 08:56, Walter Bright wrote: On 12/13/2011 11:29 PM, Jacob Carlborg wrote: Then let me say: I still use D1 for all my projects. I hear you. What can we do to make this work for you? I think it's too soon to discontinue the support for D1. I would hope that we could continue like this, having D1 in maintenance mode, for a while longer. How long? Andrei I don't know, it's more about in what state D2 and Phobos is and what changes D1 will get before the support ends. I'm thinking mostly of dynamic libraries. -- /Jacob Carlborg
Re: Fedora 17 will include support for the D programming language
On 12/13/11 5:47 PM, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/nbndg/fedora_17_will_include_support_for_the_d/ The news seems to have been accepted quite positively. Andrei
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 10:50, Walter Bright wrote: On 12/14/2011 12:30 AM, Don wrote: So, didn't sound then as though D1 was a big issue. Yet a month later you announce you've made a private decision about axing D1. Feels exactly like a military coup. Well, it wasn't one. The thing is, as I posted in this thread recently, there's little to no evidence of D1 interest - nobody responded to the beta, no posts about D1, no new bug reports about D1, no response to the new D1 releases (yes, Jacob just did a reply to it), etc. I feel like I was supporting D1 in a vacuum. I've been thinking about ending support for it for some time because of that. I don't know where the D1 community is, or even if it exists anymore. There are constantly around 25 people in the Tango channel on IRC. -- /Jacob Carlborg
Re: D1 to be discontinued on December 31, 2012
On 12/14/2011 1:46 AM, Gour wrote: I remember him from Zortech C++ compiler which was my *first* commercial package I bought and remembering the set of manuals coming along in a greyish hard box, Those are valuable collectors' items now!
Re: D1 to be discontinued on December 31, 2012
On 12/14/2011 2:24 AM, Jacob Carlborg wrote: I don't know, it's more about in what state D2 and Phobos is and what changes D1 will get before the support ends. I'm thinking mostly of dynamic libraries. It's likely D1 and D2 will get dynamic libraries at the same time, because it's mostly a backend issue.
Re: If I had my way
On Wed, 14 Dec 2011 05:54:19 +0100, Walter Bright newshou...@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
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 10:56, Walter Bright wrote: On 12/14/2011 12:45 AM, Jacob Carlborg wrote: The few times I've contributed to the compiler I've sent a patch or a pull request and the end result is that nothing happens. If I'm lucky I get a few comments, I answer them and then nothing. There's currently one open dmd pull request from you. Any others you've done have been incorporated. Yeah and what happened to that. I got a few comments about the tests failing, but they ended up being a misunderstanding. The same thing happened recently with my attempt of fixing dynamic libraries. It always feel like I'm ending with a question I never get an answer to. There are currently 68 open dmd pull requests and 490 closed/incorporated ones. I added patches to a few bugzilla issues as well. But they are long outdated by now (the patches that is). -- /Jacob Carlborg
Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X
On 2011-12-14 11:13, Walter Bright wrote: On 12/14/2011 2:03 AM, Jacob Carlborg wrote: Yeah, I see no point with the 32bit binaries either. But the 64bit binaries target 64bit by default, that's how I noticed it, my code wasn't completely 64bit compatible. The default is set to match gcc's default. Yeah, it's the only reason this matters on Mac OS X. If it was a regular application I probably never would have noticed. -- /Jacob Carlborg
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 11:29, Walter Bright wrote: On 12/14/2011 2:24 AM, Jacob Carlborg wrote: I don't know, it's more about in what state D2 and Phobos is and what changes D1 will get before the support ends. I'm thinking mostly of dynamic libraries. It's likely D1 and D2 will get dynamic libraries at the same time, because it's mostly a backend issue. I thought it was mostly a runtime issue. I managed to implement it for Tango without any changes to the compiler. -- /Jacob Carlborg
Re: If I had my way
On 2011-12-14 11:17, Martin Nowak wrote: On Tue, 13 Dec 2011 20:14:58 +0100, Walter Bright newshou...@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
Re: D1 to be discontinued on December 31, 2012
On 12/14/2011 2:36 AM, Jacob Carlborg wrote: Yeah and what happened to that. I got a few comments about the tests failing, but they ended up being a misunderstanding. I need to take care of that. The same thing happened recently with my attempt of fixing dynamic libraries. It always feel like I'm ending with a question I never get an answer to. I don't know the answers for doing dynamic libraries, which is why they aren't done. I added patches to a few bugzilla issues as well. But they are long outdated by now (the patches that is). I'd appreciate if they were submitted as pull requests.
Re: If I had my way
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 :-)
Re: If I had my way
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.
Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X
On 12/14/2011 2:37 AM, Jacob Carlborg wrote: Yeah, it's the only reason this matters on Mac OS X. If it was a regular application I probably never would have noticed. I find I don't notice. (I think that's good!) Unless I'm debugging an issue specific to 32 or 64 bits. It makes me wonder if we need to support 32 bit generation on OSX at all.
Re: D1 to be discontinued on December 31, 2012
On 2011-12-14 11:49, Walter Bright wrote: On 12/14/2011 2:36 AM, Jacob Carlborg wrote: Yeah and what happened to that. I got a few comments about the tests failing, but they ended up being a misunderstanding. I need to take care of that. Thanks. The same thing happened recently with my attempt of fixing dynamic libraries. It always feel like I'm ending with a question I never get an answer to. I don't know the answers for doing dynamic libraries, which is why they aren't done. I'm not suggesting that you would know everything but at least that we could agree what we want to do about TLS and dynamic libraries on Mac OS X. 1. Should we stick with the TLS implementation we have and wait for 10.8 1.A. Does this mean 10.6 will not be supported in the future 1.B. Will we be able to solve the TLS issues with dynamic libraries with the current implementation 2. Should we try to emulate the 10.7 implementation our self to support 10.6 as well and at the same time be forward compatible I would hope that these are question we could try to figure out and agree upon. I added patches to a few bugzilla issues as well. But they are long outdated by now (the patches that is). I'd appreciate if they were submitted as pull requests. Yes, they were added a long time ago, before the move to github. -- /Jacob Carlborg
Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X
On 14-12-2011 11:54, Walter Bright wrote: On 12/14/2011 2:37 AM, Jacob Carlborg wrote: Yeah, it's the only reason this matters on Mac OS X. If it was a regular application I probably never would have noticed. I find I don't notice. (I think that's good!) Unless I'm debugging an issue specific to 32 or 64 bits. It makes me wonder if we need to support 32 bit generation on OSX at all. No point maintaining something that won't be used. I would also imagine that it can't be long before Windows stops supporting 32-bit. - Alex
Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X
On 2011-12-14 11:54, Walter Bright wrote: On 12/14/2011 2:37 AM, Jacob Carlborg wrote: Yeah, it's the only reason this matters on Mac OS X. If it was a regular application I probably never would have noticed. I find I don't notice. (I think that's good!) Unless I'm debugging an issue specific to 32 or 64 bits. It makes me wonder if we need to support 32 bit generation on OSX at all. Yeah, I wonder that too. But does it hurt/cause problems to do? I mean, it's already supported. -- /Jacob Carlborg
Re: Sitemap
You should give priority to each page and submit it on search engines. It gives better results and google/yahoo/msn give you some extra informations on pages. Check for example: http://www.google.it/webmasters/ http://www.bing.com/toolbox/webmaster Other tips: Internal search looks for results on d-programming-language.org also if i'm on dlang.org Search engines don't like duplication of contents. www.d-programming-language.com == www.dlang.org also: www.d-programming-language.com/index.html == www.d-programming-language.com - you should use canonical uri Search engines don't like javascript redirect (do a 301 redirect: when i search for docs I always found d1 docs i think this was the reason) www.digitalmars.com/d/ There's a blank line on top of page, before dtd. That's wrong... Il giorno mer, 14/12/2011 alle 03.47 -0600, Andrei Alexandrescu ha scritto: On 12/14/11 2:48 AM, Andrea Fontana wrote: Is there a sitemap.xml for search engine? http://www.sitemaps.org/protocol.html There isn't but that sounds like a great idea and should be easy to do. See linux.mak in the website repo on how the sitemap is generated, and feel free to adapt that code to generate xml. Thanks, Andrei
Re: Fedora 17 will include support for the D programming language
On Wednesday, 14 December 2011 at 11:11:20 UTC, Mattbeui wrote: On Wednesday, 14 December 2011 at 10:24:37 UTC, Andrei Alexandrescu wrote: On 12/13/11 5:47 PM, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/nbndg/fedora_17_will_include_support_for_the_d/ The news seems to have been accepted quite positively. Andrei D1 or D2? D1 won't will be discontinued on December 31, 2012? Why they don't move on directly to D2? D1 has been in Fedora for a while. This piece of news is about D2.
Re: What can be done to reduce executable size?
Martin Krejcirik: I don't know about D2, but for D1 it helps to recompile Phobos without -lib (use lib.exe, see win32.mak). What are the effects/disadvantages of doing this? Bye, bearophile
Re: D1 to be discontinued on December 31, 2012
On 14/12/2011 09:46, Andrei Alexandrescu wrote: On 12/14/11 2:30 AM, Don wrote: On 14.12.2011 05:37, Andrei Alexandrescu wrote: There is no abandonment. Also, where is that 50/50 estimate from? Just curious. The D2 community is definitely bigger than the D1 community. But how much more? I presume it's quite a bit larger. But then both are small, and we're interested in the potential and the rate of adoption. It's hard to be sure, but the Tango users used to be 75% of the community, based on a few polls that were held, but they never had much representation on the ng. I guess between half and 2/3 are gone now. That seems a reasonable assessment. Possibly even more left. I don't think the entire D community is as big as it was back then (based on number of public repositories). That is also entirely possible. Additionally, the number of contributors, and level of activity, in Tango, was higher than Phobos has ever had. Agreed. But this is all missing the mark - why would we cry over spilled milk. The point is assessing the state of affairs the minute before the announcement. How active was Tango? How active were the Tango forums? Where were other forums of the D1 community? In this day and age, I'd be hard-pressed to think of an active programming language community that has no online presence whatsoever. To add to that, there was no trickle of bug reports or pull requests for D1, although clearly D1 does have its bugs and issues. I haven't followed Tango closely, but if D1 had a large active community, Tango would receive a lot of attention from its users as it's the de facto standard library for D1. Yet the last post (http://www.dsource.org/projects/tango/forums/topic/903) dates from March 30. The intervals between changes to the trunk (http://www.dsource.org/projects/tango/changeset/5691/) are measured in months. I hope you'll agree that one would be hard-pressed to infer from the evidence there is that there's a large, active, and thriving D1 community. Many of the active contributors to Tango and other D1 projects (millions of lines of code in total) have completely abandoned D now, moving back to C, C++, Java, and other languages. Why? See the many posts at: http://h3.gd/devlog/ And also: http://www.jfbillingsley.com/blog/?p=53 These issues are why they left D. Notice how they're not just D1 problems, for the most part, they still exist with D2 (progress has been made with some of the issues). Some issues I've pulled out (by no means all of them, see the above posts for more info): * OPTLINK/OMF/The horrific windows situation * The GC * .di files * forward references/cyclic imports * Long standing bugs with patches, lots of votes and no fix applied * Decisions being made with NO community input. Cough. Things have been changing rapidly since the move to github, and many things that drove them away are being worked on, but still... They didn't migrate to D2 because it wasn't remotely stable, and D1 still wasn't (isn't!) finished. D2 still isn't stable/complete, and has inherited many issues from pre-D1. I really hope it is before you kill off D1. -- Robert http://octarineparrot.com/
Re: What can be done to reduce executable size?
On 2011-12-14 12:47, bearophile wrote: Martin Krejcirik: I don't know about D2, but for D1 it helps to recompile Phobos without -lib (use lib.exe, see win32.mak). What are the effects/disadvantages of doing this? Bye, bearophile You need to explicitly invoke the tool that creates libraries on the given system (ar on Posix, lib on Windows) making it platform dependent. -- /Jacob Carlborg
Re: D1 to be discontinued on December 31, 2012
On Wed, 14 Dec 2011 11:15:58 +0100 Jacob Carlborg d...@me.com wrote: I don't know if all of them are successful but important: Tango, DWT, Minid, Orange, Not to say those are not important, but there are, afaict, falling in the category of D1's ecosystem, not end-user apps. Otoh Tango is ported to D2, Minid has moved to Croc, while DWT Orange have D2 ports. DVM, don't know about that one, but xfbuild to mention a few. is revived with a D2 port. So, it looks that most of the stuff is ported to D2 and therefore not a great loss. Sincerely, Gour -- It is far better to discharge one's prescribed duties, even though faultily, than another's duties perfectly. Destruction in the course of performing one's own duty is better than engaging in another's duties, for to follow another's path is dangerous. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
2.057
If 2.057 is out where is it? http://www.d-programming-language.org/download.html only has 2.056. Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D1 to be discontinued on December 31, 2012
On 14/12/2011 08:13, Andrei Alexandrescu wrote: On 12/14/11 1:35 AM, Jacob Carlborg wrote: No. It's not so much about the result (because I know basically everyone would vote to discontinue the D1 support), it's more about the attitude and the way it's handled. How would you have handled the situation if you were in our place? your list of reasons why you're discontinuing D1 ... It is for these reasons we are planning to discontinue D1 support on December 31, 2012. Does anyone have any reasons why D1 support should be continued after these dates, or is there anything we've not thought about? For those of you still using D1, what can we do to make a transition more tempting and as pain-free as possible? The result would almost certainly been the same, but you would have a better idea of what's missing in D2 that D1 has, and this would seem like more of a community decision. Obviously I'm not suggesting that either you or Walter should spent time working on things you have little or no interest in, but this was incredibly sudden, and had no community input. Side note: If you'd done the above and worded it correctly, you may have found someone to take over maintenance of D1 until support ends, thus reducing Walter's workload even sooner (just to clarify, this is just speculation and opinion, I'm not saying it would have happened). -- Robert http://octarineparrot.com/
Cilk Plus and more
An computer science popularization article about Cilk and related matters, that I did miss, from the August: http://software.intel.com/en-us/articles/data-and-thread-parallelism/ It explains the not too much hard to undestand task parallelism with the spawn and sync keywords, the parallel for loops, that haven ot fully enforced constraints: The compiler will detect violations and enforce these restrictions in most cases. Exceptions are when the comparison value and index variable are updated through pointers. The Intel Cilk Plus Array Notation is similar to the vector syntax of D, you use: a[:] = b[:] + c[:] Instead of: a[] = b[] + c[] But the complete syntax supports a stride too: array_base[begin:length:stride] That allows code like this, similar to the Python NumPy one: a[0:5][3][0:8:2] Intrinsic functions like _sec_reduce_add remind me the desire for a sum() in Phobos: int[] a; int total = sum(a); // no exception here assert(total == 0); The Intel Cilk Plus Elemental Function annotated with __declspec(vector) seem similar to D2 pure functions, but the compieler seems to use them better (so it's not a matter of language, but implementation). I have a D version too of the Ambient Occlusion Benchmark (AOBench), of course. In the end a 16.5x with a 4-core CPU is nice. Bye, bearophile
Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X
On Wednesday, 14 December 2011 at 11:07:22 UTC, Alex Rønne Petersen wrote: No point maintaining something that won't be used. I would also imagine that it can't be long before Windows stops supporting 32-bit. Windows still supports 16-bit apps (even 64-bit versions do, for some rare exceptions)!
Re: Fixing const arrays
On Wed, 14 Dec 2011 02:36:43 -, Michel Fortin
michel.for...@michelf.com wrote:
On 2011-12-13 23:08:43 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
We could have inferred property intention from the code pattern,
without requiring any keyword. That solution (which was discussed and
rejected in this newsgroup) was miles ahead from the drivel of
@property we have now.
By code patterns, you mean something like this?
struct Foo
{
int getBar();
void setBar(int);
}
void main()
{
Foo foo;
int a = foo.bar; // calls getBar()
foo.bar = a; // calls setBar(a)
}
Why not something similar to C# syntax...
struct Foo
{
int bar // - does DMD do lookahead? detect { instead of ; here and
trigger property parsing
{
get
{
return value; // - 'value' meaning the value of the 'bar' member
}
set
{
this = value; // - 'this' meaning the 'bar' member, 'value' meaning
the RHS of the £instance.bar = value statement
}
}
}
Regan
Re: Fixing const arrays
On Wed, 14 Dec 2011 13:27:57 -, Regan Heath re...@netmail.co.nz
wrote:
On Wed, 14 Dec 2011 02:36:43 -, Michel Fortin
michel.for...@michelf.com wrote:
On 2011-12-13 23:08:43 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
We could have inferred property intention from the code pattern,
without requiring any keyword. That solution (which was discussed and
rejected in this newsgroup) was miles ahead from the drivel of
@property we have now.
By code patterns, you mean something like this?
struct Foo
{
int getBar();
void setBar(int);
}
void main()
{
Foo foo;
int a = foo.bar; // calls getBar()
foo.bar = a; // calls setBar(a)
}
Why not something similar to C# syntax...
struct Foo
{
int bar // - does DMD do lookahead? detect { instead of ; here and
trigger property parsing
{
get
{
return this; // - 'this' meaning the 'bar' member
}
set
{
this = value; // - 'this' meaning the 'bar' member, 'value'
meaning the RHS of the £instance.bar = value statement
}
}
}
Regan
Apologies, there was a typo/mistake in the 'get' above. :)
Regan
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X
On 2011-12-14 10:54:55 +, Walter Bright newshou...@digitalmars.com said: On 12/14/2011 2:37 AM, Jacob Carlborg wrote: Yeah, it's the only reason this matters on Mac OS X. If it was a regular application I probably never would have noticed. I find I don't notice. (I think that's good!) Unless I'm debugging an issue specific to 32 or 64 bits. It makes me wonder if we need to support 32 bit generation on OSX at all. If I were to develop a Mac application in D at this time, not being able to target older 32-bit macs would make me reconsider using D. The app I'm working on still has PowerPC support! Perhaps I'm not the typical Mac developer though. But as long as Apple supports compiling for 32-bit with the provided developer tools I'd keep it in DMD too, if only because it'd make D look cheep otherwise. Also, I think it'd make sense that druntime and phobos continue to support 32-bit OS X in case someone wants to target iOS one day, which is basically 32-bit OS X on ARM. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Java Backend?
Does it exist a project to use D as frontend to generate Java bytecode? Something like Jython / Python...
Re: Fixing const arrays
On 2011-12-14 13:27:57 +, Regan Heath re...@netmail.co.nz said:
On Wed, 14 Dec 2011 02:36:43 -, Michel Fortin
michel.for...@michelf.com wrote:
By code patterns, you mean something like this?
struct Foo
{
int getBar();
void setBar(int);
}
void main()
{
Foo foo;
int a = foo.bar; // calls getBar()
foo.bar = a; // calls setBar(a)
}
Why not something similar to C# syntax...
I know the basics of the C# property syntax, but how do you take the
address of the getter with it? And how do you define array-member
properties like you can do with functions? And how do you disambiguate
access those array members properties if two imported modules define a
property with the same name for an array? It basically has the same
undefined areas as the current syntax using @property.
With the code pattern syntax used above:
foo.bar; // take the address of the returned value (if returned by ref)
foo.getBar; // take the address of the getter
foo.setBar; // take the address of the setter
void getFront(int[] array) { return array[0]; }
int[] a;
a.front; // array-member property made from a module-level function
// disambiguated access if two imported modules
// define the same array-member property
std.range.getFront(a);
other.mod.getFront(a);
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Fixing const arrays
On Tue, 13 Dec 2011 18:08:43 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 12/13/11 5:14 PM, Peter Alexander wrote: On 13/12/11 10:17 PM, Vladimir Panteleev wrote: On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu wrote: There's a phrase in Romanian that quite applies: From the lake into the well. I believe the English version is Out of the frying pan, into the fire :) Inconsequential space-filler opinion: I am OK with @property, mainly because it's a common feature among PLs, it's better than nothing, and don't know better solutions. In my opinion, it's not better than nothing. What it gives you: 1. A bit of syntactic sugar. 2. The ability to refactor member look up easily. What it costs: 1. Overloads syntax. a. obj.field can now be an arbitrary function call. b. May have arbitrary cost (e.g. T[].length) 2. Complicating the language (proof: this discussion) 3. Another thing to learn. 4. Another thing for tools to process. I don't think the syntax sugar it provides counts for anything really. The ability to refactor member look ups is nice, but I find that this rarely occurs in practice and even when it occurs, it's not hard to replace obj.field with obj.field() or obj.getField(). The costs far outweigh the benefits IMO. We could have inferred property intention from the code pattern, without requiring any keyword. That solution (which was discussed and rejected in this newsgroup) was miles ahead from the drivel of @property we have now. I noticed there's a tunnel vision phenomenon when it comes to keyword-based solutions: once a special notation is on the table, there's no appreciation for anything else. That's what happened with lazy (another design misfire I'm very unhappy about) and with @property. I literally feel my heart rate getting up when I think of them. @property wasn't my first choice, there were probably a dozen proposals on the table. I liked the C# version the best: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4 But here is the phenomenon I noticed: N different solutions get proposed, and are debated by the community. Walter is very vocal about what he doesn't like, but silent on other aspects (presumably because he is considering them?) All of a sudden Walter picks a solution, then posts a thread to flesh out the details. After that, it's hard to change his mind. For the property debate, looking back through the newsgroups, it looks like Walter and you came up with a solution that nobody had proposed and nobody liked. Then somehow @property was chosen. Not sure how that happened or what the convincing argument was. But you will notice in that discussion that many of the solutions did not involve keywords, and all were given equal air time (I don't see tunnel vision). Thread: http://dfeed.kimsufi.thecybershadow.net/discussion/post/h53g3i$elk$1...@digitalmars.com I personally don't mind @property, even if there are better solutions. It's not as horrible as you say IMO. -Steve
Re: Fixing const arrays
I don't mind @property, usually I just create one property block for a
class, e.g.:
@property
{
// funcs..
}
Re: 2.057
http://ftp.digitalmars.com/dmd.2.057.zip
Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X
On 2011-12-14 14:39, Michel Fortin wrote: Also, I think it'd make sense that druntime and phobos continue to support 32-bit OS X in case someone wants to target iOS one day, which is basically 32-bit OS X on ARM. Never thought of that, it's a good point. -- /Jacob Carlborg
Re: graph algorithms library
https://github.com/dawgfoto/dranges I'm slowly coming back to D : updating my compilers, setting them up on a dual boot computer, etc. Heck, I'm even reading the Pro Git book to get what's the fuss about. So yeah, I may well update it. The code still compiles with git dmd, nice :)
Re: D1 to be discontinued on December 31, 2012
On Wednesday, 14 December 2011 at 10:25:59 UTC, Jacob Carlborg wrote: There are constantly around 25 people in the Tango channel on IRC. A warning for those not familiar with IRC: this is not a very good metric. The #d channel has 101 people at this moment, but I don't recall most of them to ever say something. https://www.google.com/search?q=irc+idling
Re: dfeed
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.v6dq5dj9eav7ka@localhost.localdomain... On Sat, 10 Dec 2011 17:44:05 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: One idea for Vladimir's dfeed: it would be great to automatically post the tweets of D_language to digitalmars.D.announce. Please don't involve twitter on the newsgroups. If I wanted to follow D on twitter, I'd sign up for a twitter account. Ditto. I don't mind the twitter feed on the front page, because I rarely ever view that page, and it's good to appeal to people already involved with twitter. I do enter through the front page a lot, and while I don't usually see the twitface feed (b/c I use FF2 with lots of crap-blocking plugins...and please, can I mention FF2 *ONCE* without some crusader deciding I need to be saved by upgrade your browser evangelism?), I do get the twit feed with other browsers and I'd be thrilled for it to disappear. Even setting aside my own opinions of twitface (ie, that it's useless, moronic, aptly-named, and deserves to go out of business), there are still real issues with it: - It *significantly* slows down the page load. I'll describe it this way: FF2 is well known to be super-slow compared to every other modern browser, including newer versions of FF. And yet, my twitface-blocking FF2 loads the page many times *faster* (it's *very* noticable) than *every* modern non-twitface-blocking browser I've thrown at it. - I think it may be crashing Iron (ie, Chrome sans the malware). It's either the twit feed or the google translator, but something on the homepage is crashing Iron/Chrome for me (it happens after the main HTML/CSS loads and gets displayed). - It's extremely visually-jarring. It doesn't fit the visual style of the rest of the page at all. Which might be acceptable on a minor sub-page, but it's no good for the language's primary entryway. - People who care about twitface can subscribe to it themselves. Forcing it on everyone else is not only rude, but it effectively amounts to an advertisement for twitface right on D's homepage - which is grossly inappropriate (even regardless of anyone's personal opinions of twitface). It's no different from sticking Drink Mountin Dew! up on there.
