|
Archives
D Programming
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.ide
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
D.gnu
D
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
electronics
|
digitalmars.D.announce - dmd 1.045 / 2.030 release
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
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.
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
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.
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.
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
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.
== 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?
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.
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)
----------------------------------------------------------------------------
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.
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
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.
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).
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)
----------------------------------------------------------------------------
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 :)
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.
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).
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.
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
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
== 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?
== 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.
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.
== 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.
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
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);
* added .typeinfo to ClassInfo
Very nice. Maybe I can go remove some hacks from my code now...
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
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.))
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?
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
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.
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);
}
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.
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
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...
|
|
C & C++
DMDScript
Stewart Gordon <smjg_1998 yahoo.com> 