www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.045 / 2.030 release

reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
Is there a reason for the missing announcement ?

http://digitalmars.com/d/1.0/changelog.html#new1_045

http://www.digitalmars.com/d/2.0/changelog.html#new2_030

and what happened to 1.044 ?

-Tomas
May 12 2009
next sibling parent reply Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Tomas Lindquist Olsen Wrote:

 Is there a reason for the missing announcement ?
 
 http://digitalmars.com/d/1.0/changelog.html#new1_045
 
 http://www.digitalmars.com/d/2.0/changelog.html#new2_030
 
 and what happened to 1.044 ?
 
 -Tomas

Walter usuallly updates the changelog pages just before the actual release. Expect the announcement shortly, if you haven't already ruined the surprise! And thanks, Walter, for another big release with lots of bug fixes and improvements. Paul
May 12 2009
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Tomas Lindquist Olsen wrote:
<snip>
 And what happened to the D1 stability stance ? 1.045 is a breaking
 release (both code and binary)! I don't mind, but I'm very surprised..

Which changes are you talking about here? Stewart.
May 12 2009
prev sibling next sibling parent Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Tue, May 12, 2009 at 6:19 PM, Paul D. Anderson
<paul.d.removethis.anderson comcast.andthis.net> wrote:
 Tomas Lindquist Olsen Wrote:

 Is there a reason for the missing announcement ?

 http://digitalmars.com/d/1.0/changelog.html#new1_045

 http://www.digitalmars.com/d/2.0/changelog.html#new2_030

 and what happened to 1.044 ?

 -Tomas

Walter usuallly updates the changelog pages just before the actual release. Expect the announcement shortly, if you haven't already ruined the surprise!

But it says May 11th... That's yesterday!
 And thanks, Walter, for another big release with lots of bug fixes and
improvements.

 Paul

And what happened to the D1 stability stance ? 1.045 is a breaking release (both code and binary)! I don't mind, but I'm very surprised.. -Tomas
May 12 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:
 Is there a reason for the missing announcement ?

Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it.
May 12 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:
 I do apologize if I made a lot of people download a broken DMD
 release, but ... Some people watch the changelog, so if you don't want
 to release to be public, don't update the site!

I suppose at this point we might as well make it official.
May 12 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 I suppose at this point we might as well make it official.

I can see a large number of bugfixes. Lot of work. DMD v1.042 compiles my dlibs fine. But if I try to compile them with v1.045 the compiler prints before stopping: Assertion failure: '0' on line 136 in file 'statement.c' So I'll keep using v1.042 for now. I can't see the "vtls" switch when dmd v2.030 prints its usage switches, but it works.
added .typeinfo to ClassInfo<

Can someone explain me a bit the purpose/usefulness of this?
As D is a systems language, of course there's a way to do this. Use the storage
class __gshared:<

In future this may change, but at the moment a significant percentage of the little programs is single-thread. So if the decrease of performance is significant (and I don't know if it is, see below) then a compiler switch may be added that defaults all global variables to __gshared (and if possible optionally uses simple means to try to forbid multi-threaded code). I have done a tiny benchmark: import std.c.stdio: printf; //int x; // global __gshared int x; //shared int x; void main() { //int x; // local //for (int i; i < 1_000_000_000; i++) foreach (i; 0 .. 1_000_000_000) x++; printf("%d\n", x); } Timings, n=1_000_000_000, best of 6, seconds: DMD2: global for: 2.72 global foreach: 2.62 __gshared for: 3.03 __gshared foreach: 3.09 shared for: 3.07 shared foreach: 3.08 local for: 0.57 local foreach: 0.57 DMD1: global for: 3.08 local for: 0.55 For this tiny code it seems that __gshared reduces the loop performance. --------------------------- DMD2 __gshared for: L0: push EAX xor EAX,EAX L3: inc dword ptr _D17thread_local_test1xi inc EAX cmp EAX,03B9ACA00h jb L3 push dword ptr _D17thread_local_test1xi mov EAX,offset FLAT:_DATA push EAX call near ptr _printf [...] --------------------------- DMD2 global for: L0: push EAX xor ECX,ECX push EBX push ESI L5: mov EAX,FS:__tls_array mov EDX,[EAX] inc ECX inc dword ptr _D17thread_local_test1xi[EDX] cmp ECX,03B9ACA00h jb L5 mov ECX,FS:__tls_array mov EBX,[ECX] mov ESI,offset FLAT:_DATA push dword ptr _D17thread_local_test1xi[EBX] push ESI call near ptr _printf [...] Bye, bearophile
May 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Walter Bright:
 I suppose at this point we might as well make it official.

I can see a large number of bugfixes. Lot of work. DMD v1.042 compiles my dlibs fine. But if I try to compile them with v1.045 the compiler prints before stopping: Assertion failure: '0' on line 136 in file 'statement.c'

I need a bugzilla post.
 Can someone explain me a bit the purpose/usefulness of this?

Frank needed it for dwt.
 In future this may change, but at the moment a significant percentage
 of the little programs is single-thread. So if the decrease of
 performance is significant (and I don't know if it is, see below)
 then a compiler switch may be added that defaults all global
 variables to __gshared (and if possible optionally uses simple means
 to try to forbid multi-threaded code).

Therein lies madness. Having compiler switches that alter binary interfaces makes life very hard for library developers. With some minor work on the part of the user, there are ways to address all the performance issues. Using __gshared is the easiest.
May 12 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 bearophile wrote:
 Walter Bright:
 I suppose at this point we might as well make it official.

I can see a large number of bugfixes. Lot of work. DMD v1.042 compiles my dlibs fine. But if I try to compile them with v1.045 the compiler prints before stopping: Assertion failure: '0' on line 136 in file 'statement.c'

 Can someone explain me a bit the purpose/usefulness of this?

 In future this may change, but at the moment a significant percentage
 of the little programs is single-thread. So if the decrease of
 performance is significant (and I don't know if it is, see below)
 then a compiler switch may be added that defaults all global
 variables to __gshared (and if possible optionally uses simple means
 to try to forbid multi-threaded code).

interfaces makes life very hard for library developers. With some minor work on the part of the user, there are ways to address all the performance issues. Using __gshared is the easiest.

So __gshared is expected to stick around as part of the spec long term? It's not something that you just hacked in there for now so that, for example, druntime would compile?
May 12 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 So __gshared is expected to stick around as part of the spec long term?

Yes.
 It's not
 something that you just hacked in there for now so that, for example, druntime
 would compile?

It's so users can "cowboy" quick and dirty changes to get their code to work. It isn't allowed in "safe" mode.
May 12 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 12 de mayo a las 09:40 me escribiste:
 Tomas Lindquist Olsen wrote:
Is there a reason for the missing announcement ?

Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it.

I think a better way to do prereleases is to do a "full" release but mark it as a release candidate. For example, make a DMD 1.045rc release. Wait a week, if nobody complains, release DMD 1.045. If somebody complains, fix the bug, make a DMD 1.045rc2, etc (normally the final would be the same as the rc, and there should be very rare cases where a rc2+ would be needed). Maybe it's a little more work, but I'm sure the prerelease will get a lot more testing than a hidden release and people won't get confused thinking that something that is in the website ready for download and looks like a final release, really is a "hidden prerelease". Anyways, I think pre-releasing is great and it's better to have it this way than not having them at all. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
May 12 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el 12 de mayo a las 09:40 me escribiste:
 Tomas Lindquist Olsen wrote:
 Is there a reason for the missing announcement ?

check their builds against it.

I think a better way to do prereleases is to do a "full" release but mark it as a release candidate. For example, make a DMD 1.045rc release. Wait a week, if nobody complains, release DMD 1.045. If somebody complains, fix the bug, make a DMD 1.045rc2, etc (normally the final would be the same as the rc, and there should be very rare cases where a rc2+ would be needed). Maybe it's a little more work, but I'm sure the prerelease will get a lot more testing than a hidden release and people won't get confused thinking that something that is in the website ready for download and looks like a final release, really is a "hidden prerelease". Anyways, I think pre-releasing is great and it's better to have it this way than not having them at all.

-rc is good when you have long release cycles. It isn't appropriate for dmd, which has very short release cycles. If dmd had public source control, we could set up continuous integration for it that will, for instance, run dstress and attempt to compile the latest release of various common libraries. Then Walter can just check its results when he wants to do a release -- depending on how long that takes to run.
May 12 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Christopher Wright, el 12 de mayo a las 19:14 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el 12 de mayo a las 09:40 me escribiste:
Tomas Lindquist Olsen wrote:
Is there a reason for the missing announcement ?

check their builds against it.

it as a release candidate. For example, make a DMD 1.045rc release. Wait a week, if nobody complains, release DMD 1.045. If somebody complains, fix the bug, make a DMD 1.045rc2, etc (normally the final would be the same as the rc, and there should be very rare cases where a rc2+ would be needed). Maybe it's a little more work, but I'm sure the prerelease will get a lot more testing than a hidden release and people won't get confused thinking that something that is in the website ready for download and looks like a final release, really is a "hidden prerelease". Anyways, I think pre-releasing is great and it's better to have it this way than not having them at all.

-rc is good when you have long release cycles. It isn't appropriate for dmd, which has very short release cycles.

The Linux kernel has a release every 3 months (aprox.) and they release about 10 rc for each version. DMD is released roughly every month. I think having 1 or 2 rc version (just when they are needed, not like the Linux kernel where it's know that there will be more than 5 rc for sure) makes perfect sense.
 If dmd had public source control, we could set up continuous integration
 for it that will, for instance, run dstress and attempt to compile the
 latest release of various common libraries. Then Walter can just check
 its results when he wants to do a release -- depending on how long that
 takes to run.

This would be very nice indeed, I suggested to put DMD (specially the frontend) in a SCM a long time ago, but I think this is orthogonal with the rc. A lot of people don't want to keep checking a development version. They just want to test the compiler as it would be release (considered a "finished version") to report weird regressions. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- DESCARTAN BIDET VIRTUAL PORQUE NO LAVA -- Cronista TV
May 12 2009
parent Christopher Wright <dhasenan gmail.com> writes:
Leandro Lucarella wrote:
 Christopher Wright, el 12 de mayo a las 19:14 me escribiste:
 Leandro Lucarella wrote:
 Walter Bright, el 12 de mayo a las 09:40 me escribiste:
 Tomas Lindquist Olsen wrote:
 Is there a reason for the missing announcement ?

check their builds against it.

it as a release candidate. For example, make a DMD 1.045rc release. Wait a week, if nobody complains, release DMD 1.045. If somebody complains, fix the bug, make a DMD 1.045rc2, etc (normally the final would be the same as the rc, and there should be very rare cases where a rc2+ would be needed). Maybe it's a little more work, but I'm sure the prerelease will get a lot more testing than a hidden release and people won't get confused thinking that something that is in the website ready for download and looks like a final release, really is a "hidden prerelease". Anyways, I think pre-releasing is great and it's better to have it this way than not having them at all.

dmd, which has very short release cycles.

The Linux kernel has a release every 3 months (aprox.) and they release about 10 rc for each version. DMD is released roughly every month. I think having 1 or 2 rc version (just when they are needed, not like the Linux kernel where it's know that there will be more than 5 rc for sure) makes perfect sense.

Releases take effort. If more people were involved with D -- even in a decoupled sense, which could be provided simply by putting DMD on public source control -- then people other than Walter could manage release candidates. Don mentioned that there are, in fact, release candidates for dmd. However, private RCs are easier to manage than public ones.
 If dmd had public source control, we could set up continuous integration
 for it that will, for instance, run dstress and attempt to compile the
 latest release of various common libraries. Then Walter can just check
 its results when he wants to do a release -- depending on how long that
 takes to run.

This would be very nice indeed, I suggested to put DMD (specially the frontend) in a SCM a long time ago, but I think this is orthogonal with the rc. A lot of people don't want to keep checking a development version. They just want to test the compiler as it would be release (considered a "finished version") to report weird regressions.

Automating as much of that as possible would help.
May 13 2009
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
Christopher Wright wrote:
 If dmd had public source control, we could set up continuous integration 
 for it that will, for instance, run dstress and attempt to compile the 
 latest release of various common libraries. Then Walter can just check 
 its results when he wants to do a release -- depending on how long that 
 takes to run.

This is already done (to an extent) for ldc after each changeset at http://ldc.buildbot.octarineparrot.com/ (note that this needs updating to llvm /trunk, hence all the failures currently). If Walter is willing to put dmd under public source control I'd happily set this up to automatically compile dmd, run tests suites, compile libraries etc. I could even set up a one command/one click release candidate/final release thing if needed (maybe even nightly builds too).
May 14 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Robert Clipsham, el 14 de mayo a las 13:11 me escribiste:
 Christopher Wright wrote:
If dmd had public source control, we could set up continuous integration for it 
that will, for instance, run dstress and attempt to compile the latest release 
of various common libraries. Then Walter can just check its results when he 
wants to do a release -- depending on how long that takes to run.

This is already done (to an extent) for ldc after each changeset at http://ldc.buildbot.octarineparrot.com/ (note that this needs updating to llvm /trunk, hence all the failures currently).

I can't access to this URL right now, it is really working?
 If Walter is willing to put dmd under public source control I'd happily
 set this up to automatically compile dmd, run tests suites, compile
 libraries etc. I could even set up a one command/one click release
 candidate/final release thing if needed (maybe even nightly builds too).

That would be great. What would be the excuse not to do this? =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
May 14 2009
parent Robert Clipsham <robert octarineparrot.com> writes:
Leandro Lucarella wrote:
 I can't access to this URL right now, it is really working?

Yes, sorry, I picked the perfect time to make a post... I started doing some upgrades to my server about 20 minutes after posting this :P It is back up now.
 That would be great. What would be the excuse not to do this? =)

Well, only Walter can answer this :)
May 14 2009
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello Robert,

 If Walter is willing to put dmd under public source control I'd
 happily set this up to automatically compile dmd, run tests suites,
 compile libraries etc. I could even set up a one command/one click
 release candidate/final release thing if needed (maybe even nightly
 builds too).
 

that would also make setting up RPM/DEB genation something walter dosn't need to worry about.
May 14 2009
parent Vincenzo Ampolo <vincenzo.ampolo gmail.com> writes:
BCS wrote:

 that would also make setting up RPM/DEB genation something walter 

 need to worry about.
 

This have already been done for ldc. Have a look at http://www.dsource.org/projects/ldc/wiki/WikiStart#Ubuntuldcandldcdailypackages And at https://launchpad.net/~d-language-packagers/+archive/ppa (-hg packages are automatically built every night, by a d program, for x86 and x86_64).
May 14 2009
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
Robert Clipsham wrote:
 Christopher Wright wrote:
 If dmd had public source control, we could set up continuous 
 integration for it that will, for instance, run dstress and attempt to 
 compile the latest release of various common libraries. Then Walter 
 can just check its results when he wants to do a release -- depending 
 on how long that takes to run.

This is already done (to an extent) for ldc after each changeset at http://ldc.buildbot.octarineparrot.com/ (note that this needs updating to llvm /trunk, hence all the failures currently).

As of a few days ago, DStress is now automatically run for LDC, and developers get (almost, it's generally about 30 minutes off) immediate feedback on IRC about any regressions or improvements! Now that it's set up for ldc, it would be very easy to set it up for dmd if Walter is willing to put it under version control.
May 22 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Robert Clipsham:
 Now that it's set up for ldc, it would be very easy to set it up for dmd 
 if Walter is willing to put it under version control.

Very good idea, it will improve the improvement process. Let's suggest it to Walter. Bye, bearophile
May 23 2009
prev sibling parent Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Tue, 12 May 2009 12:40:11 -0400, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 Tomas Lindquist Olsen wrote:
 Is there a reason for the missing announcement ?

Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it.

This should be a private release then. If 1.045 is to be a "pre-release", then it should not be on the web site. If 1.045 has some critical bug that you decide needs to be fixed, then do you release 1.045 again with the fix, or 1.046? The only sane choice is to not rerelease a version that people already have, that would make bug reporting a constant struggle (oh, you have 1.045? Is that the broken 1.045 or the good 1.045?) not only for DMD but for other projects where compiler version is important in the bug reports. A prerelease version of DMD should be marked as such (i.e. 1.045rc as people have suggested).

Agreed. This is why recently DMD2.028 was released, rather than a re-release of DMD2.027 with bug 2812 fixed.
 
 I'm not trying to cause trouble, I just don't want to see something like 
 this (2 releases with the same identifier).  I know in the past I've 
 advocated for "prerelease" versions, but I meant private pre-release.  

Private prereleases are happening. This was actually DMD2.030 RC3.
 The response was always, "how do you know who should get the 
 prerelease?"  It's a fair point.  The counter argument is, libraries 
 like Tango have to blanketly disregard all bugs reported with a broken 
 compiler, which sometimes isn't included on the bug report.
 
 -Steve

May 13 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Tomas Lindquist Olsen (tomas.l.olsen gmail.com)'s article
 Is there a reason for the missing announcement ?
 http://digitalmars.com/d/1.0/changelog.html#new1_045
 http://www.digitalmars.com/d/2.0/changelog.html#new2_030
 and what happened to 1.044 ?
 -Tomas

Probably because it doesn't quite work yet. I'm waiting for some crufty old 2.029 code to run, so I thought I'd try out shared a little. Here are the results: import std.stdio, std.perf, core.thread; shared uint foo; void main() { auto t = new Thread({stuff();}); t.start; scope pc = new PerformanceCounter; pc.start; foreach(i; 0..10_000_000) { foo++; } t.join; pc.stop; writeln(pc.milliseconds); uint bar = foo; writeln(bar); // Prints some pseudorandom, wrong number. } void stuff() { foreach(i; 0..10_000_000) { foo++; } } Or is the automatic synchronization of shared variables part not supposed to be implemented yet?
May 12 2009
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Robert Jacques (sandford jhu.edu)'s article
 On Tue, 12 May 2009 12:41:50 -0400, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Tomas Lindquist Olsen (tomas.l.olsen gmail.com)'s article
 Is there a reason for the missing announcement ?
 http://digitalmars.com/d/1.0/changelog.html#new1_045
 http://www.digitalmars.com/d/2.0/changelog.html#new2_030
 and what happened to 1.044 ?
 -Tomas

Probably because it doesn't quite work yet. I'm waiting for some crufty old 2.029 code to run, so I thought I'd try out shared a little. Here are the results: import std.stdio, std.perf, core.thread; shared uint foo; void main() { auto t = new Thread({stuff();}); t.start; scope pc = new PerformanceCounter; pc.start; foreach(i; 0..10_000_000) { foo++; } t.join; pc.stop; writeln(pc.milliseconds); uint bar = foo; writeln(bar); // Prints some pseudorandom, wrong number. } void stuff() { foreach(i; 0..10_000_000) { foo++; } } Or is the automatic synchronization of shared variables part not supposed to be implemented yet?

seeing is a classic read/write race, and is expected even if foo is sequential consistent or locked. What you'd need to test is the Peterson lock

 Remember foo++ ->
 r1 = foo;
 r1++;
 foo = r1;
 So
 lock(foo);
 r1 = foo;
 unlock(foo);
 r1++;
 lock(foo);
 foo = r1;
 unlock(foo);

Yes, but I thought the whole point of shared was to make it impossible to have these kinds of bugs in your code, i.e. all the synchronization primitives necessary are supposed to occur below the level of the language abstraction.
May 12 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 Or is the automatic synchronization of shared variables part not supposed to be
 implemented yet?

The implementation of the synchronization of shared variables is not done yet. It's a big step to just make the default thread local, and to upgrade the static type system.
May 12 2009
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 dsimcha wrote:
 Or is the automatic synchronization of shared variables part not supposed to be
 implemented yet?

done yet. It's a big step to just make the default thread local, and to upgrade the static type system.

Ok, certainly understandable. In that case, congratulations on the release.
May 12 2009
prev sibling next sibling parent Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Tue, May 12, 2009 at 6:40 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Tomas Lindquist Olsen wrote:
 Is there a reason for the missing announcement ?

Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it.

I do apologize if I made a lot of people download a broken DMD release, but ... Some people watch the changelog, so if you don't want to release to be public, don't update the site! -Tomas
May 12 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 12 May 2009 12:41:50 -0400, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Tomas Lindquist Olsen (tomas.l.olsen gmail.com)'s article
 Is there a reason for the missing announcement ?
 http://digitalmars.com/d/1.0/changelog.html#new1_045
 http://www.digitalmars.com/d/2.0/changelog.html#new2_030
 and what happened to 1.044 ?
 -Tomas

Probably because it doesn't quite work yet. I'm waiting for some crufty old 2.029 code to run, so I thought I'd try out shared a little. Here are the results: import std.stdio, std.perf, core.thread; shared uint foo; void main() { auto t = new Thread({stuff();}); t.start; scope pc = new PerformanceCounter; pc.start; foreach(i; 0..10_000_000) { foo++; } t.join; pc.stop; writeln(pc.milliseconds); uint bar = foo; writeln(bar); // Prints some pseudorandom, wrong number. } void stuff() { foreach(i; 0..10_000_000) { foo++; } } Or is the automatic synchronization of shared variables part not supposed to be implemented yet?

Bartosz hasn't talked about D's shared system yet. Anyways, what you are seeing is a classic read/write race, and is expected even if foo is sequential consistent or locked. What you'd need to test is the Peterson lock (http://bartoszmilewski.wordpress.com/2008/11/11/who-ordered-sequential-consistency/) Remember foo++ -> r1 = foo; r1++; foo = r1; So lock(foo); r1 = foo; unlock(foo); r1++; lock(foo); foo = r1; unlock(foo);
May 12 2009
prev sibling next sibling parent grauzone <none example.net> writes:
* added .typeinfo to ClassInfo

Very nice. Maybe I can go remove some hacks from my code now...
May 12 2009
prev sibling next sibling parent Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Tue, May 12, 2009 at 6:40 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Tomas Lindquist Olsen wrote:
 Is there a reason for the missing announcement ?

Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it.

I do apologize if I made a lot of people download a broken DMD release, but ... Some people watch the changelog, so if you don't want to release to be public, don't update the site! -Tomas
May 12 2009
prev sibling next sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Tomas Lindquist Olsen wrote:
 Is there a reason for the missing announcement ?

Well, traditionally (as during the last ten years), Walter has made the announcements of new D releases. It's hardly conceivable that he'd forget to do so, all of a sudden. If there's no announcement, then there's a reason for it. (But you're right, updating the changelog when not announcing a new version in this NG, is a deviation from established praxis. So it's understandable that you brought it up, this time.) ((For other readers, a question in the regular D newsgroup would have been more appropriate.))
May 12 2009
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Tue, 12 May 2009 23:58:32 -0300, Leandro Lucarella wrote:

 Christopher Wright, el 12 de mayo a las 19:14 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el 12 de mayo a las 09:40 me escribiste:
Tomas Lindquist Olsen wrote:
Is there a reason for the missing announcement ?

check their builds against it.

mark it as a release candidate. For example, make a DMD 1.045rc release. Wait a week, if nobody complains, release DMD 1.045. If somebody complains, fix the bug, make a DMD 1.045rc2, etc (normally the final would be the same as the rc, and there should be very rare cases where a rc2+ would be needed). Maybe it's a little more work, but I'm sure the prerelease will get a lot more testing than a hidden release and people won't get confused thinking that something that is in the website ready for download and looks like a final release, really is a "hidden prerelease". Anyways, I think pre-releasing is great and it's better to have it this way than not having them at all.

-rc is good when you have long release cycles. It isn't appropriate for dmd, which has very short release cycles.

The Linux kernel has a release every 3 months (aprox.) and they release about 10 rc for each version. DMD is released roughly every month. I think having 1 or 2 rc version (just when they are needed, not like the Linux kernel where it's know that there will be more than 5 rc for sure) makes perfect sense.
 If dmd had public source control, we could set up continuous
 integration for it that will, for instance, run dstress and attempt to
 compile the latest release of various common libraries. Then Walter can
 just check its results when he wants to do a release -- depending on
 how long that takes to run.

This would be very nice indeed, I suggested to put DMD (specially the frontend) in a SCM a long time ago, but I think this is orthogonal with the rc. A lot of people don't want to keep checking a development version. They just want to test the compiler as it would be release (considered a "finished version") to report weird regressions.

The issue with having rc releases is exactly the same as the one for the stable release which we already have. We don't have the people to coordinate when the release is "good enough." I'm not talking users, but those that are living on the edge and finding flaws. Maybe what should be done is once Walter releases a version, the library writers that want their code working for the "stable" release should speak approval for increasing the stable version?
May 12 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 12 May 2009 12:40:11 -0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Tomas Lindquist Olsen wrote:
 Is there a reason for the missing announcement ?

Yes, I sent it to people who'd asked for a prerelease so they could check their builds against it.

This should be a private release then. If 1.045 is to be a "pre-release", then it should not be on the web site. If 1.045 has some critical bug that you decide needs to be fixed, then do you release 1.045 again with the fix, or 1.046? The only sane choice is to not rerelease a version that people already have, that would make bug reporting a constant struggle (oh, you have 1.045? Is that the broken 1.045 or the good 1.045?) not only for DMD but for other projects where compiler version is important in the bug reports. A prerelease version of DMD should be marked as such (i.e. 1.045rc as people have suggested). I'm not trying to cause trouble, I just don't want to see something like this (2 releases with the same identifier). I know in the past I've advocated for "prerelease" versions, but I meant private pre-release. The response was always, "how do you know who should get the prerelease?" It's a fair point. The counter argument is, libraries like Tango have to blanketly disregard all bugs reported with a broken compiler, which sometimes isn't included on the bug report. -Steve
May 13 2009
prev sibling next sibling parent Don <nospam nospam.com> writes:
Tomas Lindquist Olsen wrote:
 Is there a reason for the missing announcement ?
 
 http://digitalmars.com/d/1.0/changelog.html#new1_045
 
 http://www.digitalmars.com/d/2.0/changelog.html#new2_030
 
 and what happened to 1.044 ?
 
 -Tomas

NOTE: These releases fix _every_ D2 compiler segfault, stack overflow, or hang which was reported in DStress or Bugzilla prior to today. Two D1-specific bugs were accidentally missed.
May 13 2009
prev sibling next sibling parent davesun <davesun 126.com> writes:
I write a fiber scheduler use threads,segfault accur on the code,what's the
matter? thanks!

private import core.thread;
private import std.stdio;

private class SyncQueue(T)
{

    private T[] queue;

    public synchronized void push(T o)
    {
        queue ~= o;
    }

    public synchronized T pop()
    {
        T o = null;
        if (queue.length > 1)
        {
            o = queue[0];
            queue = queue[1..$];
        }
        else if (queue.length == 1)
        {
            o = queue[0];
            queue = [];
        }
        return o;
    }

    public bool empty()
    {
        return queue.length ==0;
    }

}

Fiber spawn(Args...)(void function(Args) fn, Args args)
{
    Fiber fiber = Scheduler.instance.createFiber(fn,args);
    Scheduler.instance.schedule(fiber);
    return fiber;
}

Fiber spawn(Args...)(void delegate(Args) dg, Args args)
{
    Fiber fiber = Scheduler.instance.createFiber(dg,args);
    Scheduler.instance.schedule(fiber);
    return fiber;
}

private class Scheduler
{
    private SyncQueue!(Fiber) runQueue;
    private SyncQueue!(Fiber) reuseQueue;

    private static Scheduler _scheduler;

    private static this()
    {
        _scheduler = new Scheduler;
    }

    private this ()
    {
        runQueue   = new SyncQueue!(Fiber);
        reuseQueue = new SyncQueue!(Fiber);
    }

    public void schedule(Fiber fiber)
    {
        runQueue.push(fiber);
    }

    public void run(int threadNum =1)
    {
        ThreadGroup tg = new ThreadGroup;
        for (int i =0;i<threadNum;i++)
        {
            tg.create(
            {
                while (!runQueue.empty)
                {
                    Fiber fiber = runQueue.pop();
                    if (fiber is null)
                    {
                        continue;
                    }
                    else
                    {
                        fiber.call();
                        if (fiber.state == Fiber.State.TERM)
                        {
                            fiber.reset();
                            reuseQueue.push(fiber);//segmentation fault accur
here
                        }
                        else
                        {
                            runQueue.push(fiber);//segmentation fault accur here
                        }
                    }
                }
            });
        }
        tg.joinAll;
    }

    public Fiber createFiber(Args...)(void function(Args) fn, Args args)
    {
        void proc()
        {
            fn(args);
        }
        Fiber fiber = reuseQueue.pop();
        if (!fiber)
            fiber = new Fiber(&proc);
        return fiber;
    }

    public Fiber createFiber(Args...)(void delegate(Args) dg, Args args)
    {
        void proc()
        {
            dg(args);
        }
        Fiber fiber = reuseQueue.pop();
        if (!fiber)
            fiber = new Fiber(&proc);
        return fiber;
    }

    public static Scheduler instance()
    {
        return _scheduler;
    }
}

void main()
{
    spawn(
    {
        writefln("%p",cast(void *) Fiber.getThis);
        spawn(
        {
           writefln("%p",cast(void *)Fiber.getThis);
        });
    });

    Scheduler.instance.run(4);
}
May 14 2009
prev sibling next sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Tue, 12 May 2009 17:25:20 +0000, dsimcha wrote:

 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 dsimcha wrote:
 Or is the automatic synchronization of shared variables part not
 supposed to be implemented yet?

done yet. It's a big step to just make the default thread local, and to upgrade the static type system.

Ok, certainly understandable. In that case, congratulations on the release.

vote++ I like both the shared/tls stuff AND the big emphasis on bug-fixes.
May 14 2009
prev sibling next sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
 http://digitalmars.com/d/1.0/changelog.html#new1_045
 
 http://www.digitalmars.com/d/2.0/changelog.html#new2_030

Seems like D2 is still semi-usable on Mac OS X Tiger, after recompilation. (official binary is Leopard-only) Besides for some low-hanging fruit like missing versions and need to update make and some paths in the makefiles, there was only a few (known) regressions with threads and some weird linker issue that I hadn't seen before... But "hello" does build, and most of the unittests pass: core.exception.AssertError core.thread(1664): Assertion failure dyld: corrupt binary, library ordinal too big make-3.81: *** [obj/posix/release/unittest/std/regex] Trace/BPT trap core.exception.RangeError core.thread(2183): Range violation --anders
May 15 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Holy bugfixes, Batman! It took me ten minutes to skip through all the 
"fixed in dmd1.045" / "fixed in dmd2.030" messages. I'm so happy...
May 15 2009