Re: dmd 1.045 / 2.030 release
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?
Re: dmd 1.045 / 2.030 release
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.))
Re: dmd 1.045 / 2.030 release
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
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Derek Parnell wrote: On Tue, 12 May 2009 15:59:05 -0500, Andrei Alexandrescu wrote: Walter Bright wrote: BLS wrote: No, promoting D also means having a couple of newsgroup entries each day. Otherwise you'll have several "10 entries a month" D newsgroups and this imo not very appealing to new visitors. In other words, Bier erm, quantity rulez. Yeah, I had second thoughts along those same lines. I think -users and -developers should work. It works for Boost very well. I'm not used to Boost groups, so who is expected to post to "-users"? Are they users of D (that is, application developers)? Who posts to "-developers"? Are they the people developing D itself or application/tool/library developers (otherwise known as users of D)? Those who use Boost hang out in the users group. Those who are interested in the implementation of Boost hang out in the devel group, whether or not they have written a Boost library. Andrei
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Hello BLS, (I think it is not really top secret to talk about what is in use. 1) OCAML, 2) C and 3) ADA ... ) The only surprise there (if any) is OCAML. *Everyone* uses C and, last I heard, Ada is still the #1 choice for Bugs==DeadBodiesOrWorse development. From what I've heard, it's actually a darn nice language to work in if you are going to be doing all the engineering process stuff anyway.
Re: dmd 1.045 / 2.030 release
Tomas Lindquist Olsen wrote: 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.
Re: dmd 1.045 / 2.030 release
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.
Re: Off topic
On Wed, 13 May 2009 00:46:25 +0200, BLS wrote: > Derek, may I contact you by Skype ? Sure. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Off topic
Derek Parnell wrote: On Tue, 12 May 2009 15:59:05 -0500, Andrei Alexandrescu wrote: Walter Bright wrote: BLS wrote: No, promoting D also means having a couple of newsgroup entries each day. Otherwise you'll have several "10 entries a month" D newsgroups and this imo not very appealing to new visitors. In other words, Bier erm, quantity rulez. Yeah, I had second thoughts along those same lines. I think -users and -developers should work. It works for Boost very well. I'm not used to Boost groups, so who is expected to post to "-users"? Are they users of D (that is, application developers)? Who posts to "-developers"? Are they the people developing D itself or application/tool/library developers (otherwise known as users of D)? Derek, may I contact you by Skype ? I will stay for about 6 month in Brisbane to fulfill a software contract. Live in Europe, Time difference GMT +8. Björn nanali at wanadoo dot ... fr
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Andrei Alexandrescu wrote: Walter Bright wrote: BLS wrote: No, promoting D also means having a couple of newsgroup entries each day. Otherwise you'll have several "10 entries a month" D newsgroups and this imo not very appealing to new visitors. In other words, Bier erm, quantity rulez. Yeah, I had second thoughts along those same lines. you mean Beer or ... :) I think -users and -developers should work. It works for Boost very well. Andrei May be I am wrong, but the Boost respective CPP community is atm not comparable to the D community. I mean let's wait a while. F.I. I am in contact with airbus industries since 2.5 years and I can assure you they have an eye on D. (I think it is not really top secret to talk about what is in use. 1) OCAML, 2) C and 3) ADA ... ) Björn
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Andrei Alexandrescu wrote: Walter Bright wrote: BLS wrote: No, promoting D also means having a couple of newsgroup entries each day. Otherwise you'll have several "10 entries a month" D newsgroups and this imo not very appealing to new visitors. In other words, Bier erm, quantity rulez. Yeah, I had second thoughts along those same lines. Beer or ... :) I think -users and -developers should work. It works for Boost very well. Andrei May be I am wrong, but the Boost respective CPP community is atm not comparable to the D community. I mean let's wait a while. F.I. I am in contact with airbus industries since 2.5 years and I can assure you they have an eye on D. (I think it is not really top secret to tell you that 1) OCAML, 2) C and 3) ADA are in use... so far) Björn
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
On Tue, 12 May 2009 15:59:05 -0500, Andrei Alexandrescu wrote: > Walter Bright wrote: >> BLS wrote: >>> No, promoting D also means having a couple of newsgroup entries each day. >>> Otherwise you'll have several "10 entries a month" D newsgroups and >>> this imo not very appealing to new visitors. >>> In other words, Bier erm, quantity rulez. >> >> Yeah, I had second thoughts along those same lines. > > I think -users and -developers should work. It works for Boost very well. I'm not used to Boost groups, so who is expected to post to "-users"? Are they users of D (that is, application developers)? Who posts to "-developers"? Are they the people developing D itself or application/tool/library developers (otherwise known as users of D)? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: dmd 1.045 / 2.030 release
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.
Re: dmd 1.045 / 2.030 release
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)
Re: dmd 1.045 / 2.030 release
== Quote from Walter Bright (newshou...@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?
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Walter Bright wrote: BLS wrote: No, promoting D also means having a couple of newsgroup entries each day. Otherwise you'll have several "10 entries a month" D newsgroups and this imo not very appealing to new visitors. In other words, Bier erm, quantity rulez. Yeah, I had second thoughts along those same lines. I think -users and -developers should work. It works for Boost very well. Andrei
Re: dmd 1.045 / 2.030 release
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.
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Walter Bright wrote: > Tomas Lindquist Olsen wrote: >> I think it's a great idea, there's some decent arguments that they >> should have more general names, but I like the idea that you'd always >> know which group to look in for specific issues, even when we're at >> D4! > > I do have reservations about the idea, based on experience with all the > Digital Mars C++ newsgroups. There are too many, making for rather thin > traffic. It's tedious to check them all for new postings, which means > that that doesn't happen, and new postings often languish as a result. > > The main D n.g. gets a lot of action, which feeds on itself. I'm > reluctant to mess with success. Similar to what Knud Soerensen suggested: Rename .learn to .programming and .d to .design or .future. And while we're at it: merge .dwt .gnu .ide .debugger into .tools or .toolchain or something like that. That way you end up with even less newsgroups!
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
BLS wrote: No, promoting D also means having a couple of newsgroup entries each day. Otherwise you'll have several "10 entries a month" D newsgroups and this imo not very appealing to new visitors. In other words, Bier erm, quantity rulez. Yeah, I had second thoughts along those same lines.
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Walter Bright wrote: Is this a good idea? No, promoting D also means having a couple of newsgroup entries each day. Otherwise you'll have several "10 entries a month" D newsgroups and this imo not very appealing to new visitors. In other words, Bier erm, quantity rulez. Björn
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Tomas Lindquist Olsen wrote: However, why propose it if you don't like the idea in the first place ? I changed my mind.
Re: dmd 1.045 / 2.030 release
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: pushEAX
xor EAX,EAX
L3: inc dword ptr _D17thread_local_test1xi
inc EAX
cmp EAX,03B9ACA00h
jb L3
pushdword ptr _D17thread_local_test1xi
mov EAX,offset FLAT:_DATA
pushEAX
callnear ptr _printf
[...]
---
DMD2 global for:
L0: pushEAX
xor ECX,ECX
pushEBX
pushESI
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
pushdword ptr _D17thread_local_test1xi[EBX]
pushESI
callnear ptr _printf
[...]
Bye,
bearophile
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
On Tue, May 12, 2009 at 7:38 PM, Walter Bright wrote: > Tomas Lindquist Olsen wrote: >> >> I think it's a great idea, there's some decent arguments that they >> should have more general names, but I like the idea that you'd always >> know which group to look in for specific issues, even when we're at >> D4! > > I do have reservations about the idea, based on experience with all the > Digital Mars C++ newsgroups. There are too many, making for rather thin > traffic. It's tedious to check them all for new postings, which means that > that doesn't happen, and new postings often languish as a result. > > The main D n.g. gets a lot of action, which feeds on itself. I'm reluctant > to mess with success. > It's a good point... I still don't think it's a bad idea, but I can see your reason to be reluctant perfectly well. However, why propose it if you don't like the idea in the first place ?
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Tomas Lindquist Olsen wrote: I think it's a great idea, there's some decent arguments that they should have more general names, but I like the idea that you'd always know which group to look in for specific issues, even when we're at D4! I do have reservations about the idea, based on experience with all the Digital Mars C++ newsgroups. There are too many, making for rather thin traffic. It's tedious to check them all for new postings, which means that that doesn't happen, and new postings often languish as a result. The main D n.g. gets a lot of action, which feeds on itself. I'm reluctant to mess with success.
Re: dmd 1.045 / 2.030 release
== Quote from Walter Bright (newshou...@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.
Re: dmd 1.045 / 2.030 release
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.
Re: dmd 1.045 / 2.030 release
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.
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
On Tue, May 12, 2009 at 2:26 AM, Walter Bright wrote: > Is this a good idea? > I think it's a great idea, there's some decent arguments that they should have more general names, but I like the idea that you'd always know which group to look in for specific issues, even when we're at D4! vote +1 !
Re: dmd 1.045 / 2.030 release
On Tue, May 12, 2009 at 6:40 PM, Walter Bright 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
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
What about D.programming and D.compilers Then all programming questions goes to D.programming and D.compilers could be the goto group for discussion on compiler design. Close D.learn and D.gnu. I agree the D.learn sounds like it is for newbies. And I think that all the compilers could benefit form a shared discussion. Robert Clipsham wrote: Walter Bright wrote: Is this a good idea? Yes, but maybe not .D and .D2. I think a separate news group for the huge threads about the future of D/D2 would be good, but there still needs to be a general newsgroup for general discussion - some discussions aren't specific to either or would be best left open. I like the idea of D.future as others have suggested. -- Knud Sørensen Programmer for hire.
Re: dmd 1.045 / 2.030 release
== Quote from Robert Jacques (sandf...@jhu.edu)'s article
> On Tue, 12 May 2009 12:41:50 -0400, dsimcha wrote:
> > == Quote from Tomas Lindquist Olsen (tomas.l.ol...@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.
Re: dmd 1.045 / 2.030 release
* added .typeinfo to ClassInfo Very nice. Maybe I can go remove some hacks from my code now...
Re: dmd 1.045 / 2.030 release
On Tue, 12 May 2009 12:41:50 -0400, dsimcha wrote:
== Quote from Tomas Lindquist Olsen (tomas.l.ol...@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);
Re: dmd 1.045 / 2.030 release
On Tue, May 12, 2009 at 6:40 PM, Walter Bright 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
Re: dmd 1.045 / 2.030 release
== Quote from Tomas Lindquist Olsen (tomas.l.ol...@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?
Re: dmd 1.045 / 2.030 release
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.
Re: dmd 1.045 / 2.030 release
On Tue, May 12, 2009 at 6:19 PM, Paul D. Anderson 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
Re: 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
dmd 1.045 / 2.030 release
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
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Jarrett Billingsley, el 12 de mayo a las 01:01 me escribiste: > On Mon, May 11, 2009 at 8:26 PM, Walter Bright > wrote: > > Is this a good idea? > > > > My gut reaction is 'yes'. But what would be left on .D without the > hundred-post threads about ranges? There really _isn't_ that much > conversation about D1, and most of it probably belongs on .D.learn > anyway. That's why I think D.learn should be named D.users and D should be named D.devel. D.learn seems to be a "newbie" group and D seems to be an "expert" group. Since there is no develpment in the D1 side, there would be no much D1 talking in D.devel (as it is now), except for some bug report discussion or something. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Re: Numpy Random Number Generators
On 2009-05-02 12:36:16 +0200, Michel Fortin said: On 2009-05-01 15:10:50 -0400, dsimcha said: IDK, I mean, I cut and pasted the code into my D IDE and tweaked it to get it to compile and then did some statistical tests to make sure the distributions were still reproduced faithfully. I didn't even change any of the variable names or code structure or anything in most cases. It's a straight translation, not a real reimplementation. I don't see how something like this could possibly *not* be considered a derivative work, and I think the people who wrote the original lib definitely deserve to be given credit. It's just that some of the BSD legalese is a little bit of a PITA for code that's in a standard lib. You can always ask for permission at the source. You never know, they may agree to allow you to put your D port under a license that'd work for Phobos. As long as there isn't too many copyright holders, it might work. otherwise adding the missing distributions (gaussian, exponential & gamma are already there, and done efficiently) to tango.math.random.Random would also be welcomed. Fawzi
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
Walter Bright wrote: Is this a good idea? Yes, but maybe not .D and .D2. I think a separate news group for the huge threads about the future of D/D2 would be good, but there still needs to be a general newsgroup for general discussion - some discussions aren't specific to either or would be best left open. I like the idea of D.future as others have suggested.
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
No. If we had D and D2, then we'll need D3 (and D4). And we don't need both a D([1]) and a D.learn newsgroup. Not enough volume three groups. We need _D.programming_ and _D.future_, that's all. Once they're up, we post into d.learn that "please post in D.programming instead", and in D that "post in D.future instead". The whole point of this name change is to steer people into *D.programming* by default. That means /anybody/ who approaches our news for the first time. D.programming should contain both newbie questions, and general talk about the Current D version (i.e. D1 for now, and once "D2 is out", D1 and D2 together). People who don't fancy themselves as language development guys, should get scared enough of the name D.future that they approach with caution. And that's all we need. If they peek in, and are comfortable with hairy stuff, and want to contribute, then just jump in, of course. - For this to serve the purpose we intend, D1 should be more prominent on the digitalmars web site, too. It is the Current Version, after all! D2 is only alpha, and not intended for use by others than the D language developers.
