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 reply 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
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 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 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
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'


 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.


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 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 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 ?


 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.


-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 ?


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.


 
 -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
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 ?


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.


 
 -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 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 ?


 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.


 -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.


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 


dosn't

 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 reply "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
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 reply "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
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?


 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);


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 reply 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?


 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.


Ok, certainly understandable.  In that case, congratulations on the release.
May 12 2009
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?


 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.


 
 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 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 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 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 =?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