www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.027 and 2.011 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
A whole lotta library improvements.

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.027.zip

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.011.zip

I had planned on doing struct destructors for this update, but they are 
not done yet.
Feb 19 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fpf9bk$2upn$1 digitalmars.com...
A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they are 
 not done yet.

.tupleof can now access private fields of a struct/class Any reason why this was fixed in D2 but not in D1? My binding library is still broken because of it..
Feb 19 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 .tupleof can now access private fields of a struct/class
 
 Any reason why this was fixed in D2 but not in D1?  My binding library is 
 still broken because of it.. 

I guess that depends on if it's an enhancement or a bug fix. Obviously, you consider it the latter :-)
Feb 19 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fpfco5$7j5$1 digitalmars.com...
 Jarrett Billingsley wrote:
 .tupleof can now access private fields of a struct/class

 Any reason why this was fixed in D2 but not in D1?  My binding library is 
 still broken because of it..

I guess that depends on if it's an enhancement or a bug fix. Obviously, you consider it the latter :-)

Obviously I do ;) Especially since it's not mentioned anywhere in the spec.
Feb 19 2008
prev sibling next sibling parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Tue, 19 Feb 2008 21:06:31 +0200, Walter Bright <newshound1 digitalmars.com>
wrote:

 A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they are
 not done yet.

That looks great! However, D1's Phobos did not get any of the fixes? Also, it seems that bug 1815 doesn't belong in D1's changelog. -- Best regards, Vladimir mailto:thecybershadow gmail.com
Feb 19 2008
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 A whole lotta library improvements.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip
 I had planned on doing struct destructors for this update, but they
 are not done yet.
 

Is there now some way to force dmd to output the link command?
Feb 19 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 Is there now some way to force dmd to output the link command?

-v
Feb 19 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to Walter,

 BCS wrote:
 
 Is there now some way to force dmd to output the link command?
 


:)
Feb 19 2008
prev sibling parent Frank Benoit <keinfarbton googlemail.com> writes:
Walter Bright schrieb:
 BCS wrote:
 Is there now some way to force dmd to output the link command?

-v

For me it still prints the gcc line. I use dmd 1.027 on linux.
Feb 20 2008
prev sibling next sibling parent reply Extrawurst <spam extrawurst.org> writes:
Wow what a huge changelist for the std lib, awesome !

But i wonder about one thing:

[CODE]

class Foo {
   int foo() {
       synchronized(this){
           return 8;
       }
   }
}

[/CODE]

why does 2.011 in contrast to the previous 2.010 warn me with "warning - 
main.d(3): function main.Foo.foo no return at end of function" ? why is 
this a probem suddenly ? i have plenty of this warnings spit out in my 
project now ;(


Walter Bright schrieb:
 A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they 
 are not done yet.

Feb 19 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Extrawurst wrote:
 Wow what a huge changelist for the std lib, awesome !
 
 But i wonder about one thing:
 
 [CODE]
 
 class Foo {
   int foo() {
       synchronized(this){
           return 8;
       }
   }
 }
 
 [/CODE]
 
 why does 2.011 in contrast to the previous 2.010 warn me with "warning - 
 main.d(3): function main.Foo.foo no return at end of function" ? why is 
 this a probem suddenly ? i have plenty of this warnings spit out in my 
 project now ;(

Because I reimplemented the flow analysis, and it looks like there's a bug in it :-(
Feb 19 2008
parent reply Extrawurst <spam extrawurst.org> writes:
Walter Bright schrieb:
 Extrawurst wrote:
 Wow what a huge changelist for the std lib, awesome !

 But i wonder about one thing:

 [CODE]

 class Foo {
   int foo() {
       synchronized(this){
           return 8;
       }
   }
 }

 [/CODE]

 why does 2.011 in contrast to the previous 2.010 warn me with 
 "warning - main.d(3): function main.Foo.foo no return at end of 
 function" ? why is this a probem suddenly ? i have plenty of this 
 warnings spit out in my project now ;(

Because I reimplemented the flow analysis, and it looks like there's a bug in it :-(

i made an entry in bugzilla
Feb 20 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Extrawurst wrote:
 i made an entry in bugzilla

Thank you.
Feb 20 2008
prev sibling next sibling parent reply "Saaa" <empty needmail.com> writes:
Is it possible to check how many known bugs are still unsolved for D1 ? 
Feb 19 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Saaa wrote:
 Is it possible to check how many known bugs are still unsolved for D1 ? 

I think you can get that from bugzilla.
Feb 19 2008
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 A whole lotta library improvements.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip
 
 I had planned on doing struct destructors for this update, but they are 
 not done yet.

For all who care, Tango appears to compile with D1.027. (It didn't compile with D1.026 -- some errors about "scope". I tested with the SVN version of Tango with DMD. I did not try the 0.99.4 "Frank" release, or GCD so I can't vouch for those.) --bb
Feb 19 2008
prev sibling next sibling parent reply torhu <no spam.invalid> writes:
Walter Bright wrote:
 A whole lotta library improvements.

I had to copy and paste the 2.0 changelog into my editor to be able to even read it. Would it be possible to get a readable font face and size? There is no shame in just using black text on a white background either. Please? I use FF 2 on winxp, so I don't think I have a weird setup. 19 inch CRT, 1152x864. That's pretty mainstream, and the 1.0 docs look just fine on my screen.
Feb 19 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
torhu wrote:
 Walter Bright wrote:
 A whole lotta library improvements.

I had to copy and paste the 2.0 changelog into my editor to be able to even read it. Would it be possible to get a readable font face and size? There is no shame in just using black text on a white background either. Please? I use FF 2 on winxp, so I don't think I have a weird setup. 19 inch CRT, 1152x864. That's pretty mainstream, and the 1.0 docs look just fine on my screen.

The font is pretty darned small over here too. Also WinXP/FF2. I wouldn't say unreadable, but the 1.0 changelog is definitely easier on the eyes. I thought a web developer was helping you to make the D site more modern. Is this the result of that? Or is that yet to come? --bb
Feb 19 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 The font is pretty darned small over here too.  Also WinXP/FF2.  I 
 wouldn't say unreadable, but the 1.0 changelog is definitely easier on 
 the eyes.

That's good feedback. You can try tweaking the style.css, and let me know what makes it look better.
 I thought a web developer was helping you to make the D site more 
 modern.  Is this the result of that?  Or is that yet to come?

That kinda fizzled out.
Feb 19 2008
next sibling parent reply Jacob Carlborg <doobnet gmail.com> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 The font is pretty darned small over here too.  Also WinXP/FF2.  I 
 wouldn't say unreadable, but the 1.0 changelog is definitely easier on 
 the eyes.

That's good feedback. You can try tweaking the style.css, and let me know what makes it look better.
 I thought a web developer was helping you to make the D site more 
 modern.  Is this the result of that?  Or is that yet to come?

That kinda fizzled out.

Why not use the same style sheet for D 1 and 2 or do you want them to look different?
Feb 20 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:
 Why not use the same style sheet for D 1 and 2 or do you want them to 
 look different?

I think it's a good idea that they look a bit different.
Feb 20 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Jacob Carlborg wrote:
 Why not use the same style sheet for D 1 and 2 or do you want them to 
 look different?

I think it's a good idea that they look a bit different.

I do like that there's a difference. But I think the color scheme may be enough to achieve that. --bb
Feb 20 2008
parent Jacob Carlborg <doobnet gmail.com> writes:
Bill Baxter wrote:
 Walter Bright wrote:
 Jacob Carlborg wrote:
 Why not use the same style sheet for D 1 and 2 or do you want them to 
 look different?

I think it's a good idea that they look a bit different.

I do like that there's a difference. But I think the color scheme may be enough to achieve that. --bb

Why not just add "font-family: Helvetica, Verdana, Arial, sans-serif;" in D 2's style sheet in "body" like D 1 has
Feb 20 2008
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
I sent you an email, did you receive it?  Or did I use the wrong address?

-[Unknown]


Walter Bright wrote:
 Bill Baxter wrote:
 The font is pretty darned small over here too.  Also WinXP/FF2.  I 
 wouldn't say unreadable, but the 1.0 changelog is definitely easier on 
 the eyes.

That's good feedback. You can try tweaking the style.css, and let me know what makes it look better.
 I thought a web developer was helping you to make the D site more 
 modern.  Is this the result of that?  Or is that yet to come?

That kinda fizzled out.

Feb 22 2008
prev sibling parent Jacob Carlborg <doobnet gmail.com> writes:
Bill Baxter wrote:
 torhu wrote:
 Walter Bright wrote:
 A whole lotta library improvements.

I had to copy and paste the 2.0 changelog into my editor to be able to even read it. Would it be possible to get a readable font face and size? There is no shame in just using black text on a white background either. Please? I use FF 2 on winxp, so I don't think I have a weird setup. 19 inch CRT, 1152x864. That's pretty mainstream, and the 1.0 docs look just fine on my screen.

The font is pretty darned small over here too. Also WinXP/FF2. I wouldn't say unreadable, but the 1.0 changelog is definitely easier on the eyes. I thought a web developer was helping you to make the D site more modern. Is this the result of that? Or is that yet to come? --bb

It's the same in osx/ff3beta and osx/safari
Feb 20 2008
prev sibling parent Jascha Wetzel <firstname mainia.de> writes:
torhu wrote:
 Walter Bright wrote:
 A whole lotta library improvements.

I had to copy and paste the 2.0 changelog into my editor to be able to even read it. Would it be possible to get a readable font face and size? There is no shame in just using black text on a white background either. Please? I use FF 2 on winxp, so I don't think I have a weird setup. 19 inch CRT, 1152x864. That's pretty mainstream, and the 1.0 docs look just fine on my screen.

it's readable but still *pretty* small on ff2/linux and opera/vista
Feb 20 2008
prev sibling next sibling parent Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 A whole lotta library improvements.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip
 
 I had planned on doing struct destructors for this update, but they are 
 not done yet.

Thanks! What happened to my fixes to std.math? They are still in phobos candidate, but not in the trunk.
Feb 19 2008
prev sibling next sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
Walter Bright wrote:

 A whole lotta library improvements.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip
 
 I had planned on doing struct destructors for this update, but they are
 not done yet.

Thanks! If anybody cares about Konqueror, phobos 2 docs layout is broken in Konqueror 3 and 4. I suspect this is because of the possibly redundant </div> tag right above <div id="content">.
Feb 20 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Max Samukha wrote:
 If anybody cares about Konqueror, phobos 2 docs layout is broken in
 Konqueror 3 and 4. I suspect this is because of the possibly redundant
 </div> tag right above <div id="content">.

Try it now.
Feb 20 2008
parent Max Samukha <maxsamukha gmail.com> writes:
Walter Bright wrote:

 Max Samukha wrote:
 If anybody cares about Konqueror, phobos 2 docs layout is broken in
 Konqueror 3 and 4. I suspect this is because of the possibly redundant
 </div> tag right above <div id="content">.

Try it now.

Fixed.
Feb 20 2008
prev sibling next sibling parent reply Extrawurst <spam extrawurst.org> writes:
Walter Bright schrieb:
 A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they 
 are not done yet.

btw. whats the nothrow keyword gonna be for ? ~Extrawurst
Feb 20 2008
next sibling parent reply Jacob Carlborg <doobnet gmail.com> writes:
Extrawurst wrote:
 Walter Bright schrieb:
 A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they 
 are not done yet.

btw. whats the nothrow keyword gonna be for ? ~Extrawurst

Indicating that a function/method won't throw an exception?
Feb 20 2008
parent reply Extrawurst <spam extrawurst.org> writes:
Jacob Carlborg schrieb:
 Extrawurst wrote:
 Walter Bright schrieb:
 A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they 
 are not done yet.

btw. whats the nothrow keyword gonna be for ? ~Extrawurst

Indicating that a function/method won't throw an exception?

yeah but what happend to the express-such-things-via-documention policy to keep syntax simple ?
Feb 20 2008
next sibling parent reply Jacob Carlborg <doobnet gmail.com> writes:
Extrawurst wrote:
 Jacob Carlborg schrieb:
 Extrawurst wrote:
 Walter Bright schrieb:
 A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they 
 are not done yet.

btw. whats the nothrow keyword gonna be for ? ~Extrawurst

Indicating that a function/method won't throw an exception?

yeah but what happend to the express-such-things-via-documention policy to keep syntax simple ?

The compiler can probably do some optimization if it knows that
Feb 20 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:
 The compiler can probably do some optimization if it knows that

Exactly. This will become more important later.
Feb 20 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Graham St Jack wrote:
 It is also very helpful when writing code to know that a function you are 
 calling won't throw an exception - it means you have three kinds of 
 functions: those that don't throw, those with comments telling you what 
 they throw, and those that you need to fix the comments for.

Experience with this indicates that it is impractical to specify what exceptions a function may throw. The only practical states to specify are: 1) does not throw 2) always throws 3) might throw What is thrown is not reliably computable. For example: import foo; void test() { foo.bar(); } What exceptions does test() throw? That would require knowledge of the import foo, which is not necessarily knowable and can change over time.
Feb 20 2008
next sibling parent Georg Wrede <georg nospam.org> writes:
Walter Bright wrote:
 Graham St Jack wrote:
 
 It is also very helpful when writing code to know that a function you 
 are calling won't throw an exception - it means you have three kinds 
 of functions: those that don't throw, those with comments telling you 
 what they throw, and those that you need to fix the comments for.

Experience with this indicates that it is impractical to specify what exceptions a function may throw. The only practical states to specify are: 1) does not throw 2) always throws 3) might throw What is thrown is not reliably computable. For example: import foo; void test() { foo.bar(); } What exceptions does test() throw? That would require knowledge of the import foo, which is not necessarily knowable and can change over time.

So both of you are right! (Heh, couldn't resist ;-) ) What my comment above incidentally uncovers is that this is a profound aspect that especially Programmer Group Managers should be aware of. The ability to see things /simultaneously/ from the perspective of the library programmer, the app programmer, and Real Reality, is fundamental to the success of the Group. If all three of these persons can see it from all three points of view, the better. And much better. (It's a pity that all we have left in Finland currently on the job market are ex-truck-drivers. Everybody else already are in managerial positions at Nokia, F-Secure, and a few other firms.)
Feb 21 2008
prev sibling next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote

 which is not necessarily knowable and can change over time

This holds also for the reduction to the three states Always, Never, Sometimes. -manfred
Feb 21 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Manfred Nowak wrote:
 Walter Bright wrote
 
 which is not necessarily knowable and can change over time

This holds also for the reduction to the three states Always, Never, Sometimes.

If they are part of the type signature, then it can be enforced.
Feb 21 2008
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:

 If they are part of the type signature, then it can be enforced.

For this one would have to ensure that the prerequisites of Rice's Theorem [http://en.wikipedia.org/wiki/Rice's_theorem] do not hold. How to do that? -manfred
Feb 21 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Manfred Nowak wrote:
 Walter Bright wrote:
 
 If they are part of the type signature, then it can be enforced.

For this one would have to ensure that the prerequisites of Rice's Theorem [http://en.wikipedia.org/wiki/Rice's_theorem] do not hold. How to do that?

Don't have to compute it, just check it since it's part of the type signature.
Feb 22 2008
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:

 Don't have to compute it, just check it since it's part of the type 
 signature.

Enforcing, checking but not computing? I don't get that. So I'll have to wait for the docs for "nothrow". -manfred
Feb 22 2008
next sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= writes:
Manfred Nowak schrieb:
 Walter Bright wrote:
 
 Don't have to compute it, just check it since it's part of the type 
 signature.

Enforcing, checking but not computing? I don't get that. So I'll have to wait for the docs for "nothrow". -manfred

If you specify that some function does not throw an exception, you can enforce that simply by disallowing the use of "throw", as well as the use of any function which does not specify "nothrow" inside of the function. I'd guess thats how it's supposed to work. With this system, there would of course be some functions, which could never throw an exception, but are not allowed to carry the nothrow flag, however (i.e. a function which catches all the exceptions of all used functions).
Feb 22 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
S鰊ke Ludwig wrote:
 Manfred Nowak schrieb:
 Walter Bright wrote:

 Don't have to compute it, just check it since it's part of the type 
 signature.

Enforcing, checking but not computing? I don't get that. So I'll have to wait for the docs for "nothrow". -manfred

If you specify that some function does not throw an exception, you can enforce that simply by disallowing the use of "throw", as well as the use of any function which does not specify "nothrow" inside of the function. I'd guess thats how it's supposed to work. With this system, there would of course be some functions, which could never throw an exception, but are not allowed to carry the nothrow flag, however (i.e. a function which catches all the exceptions of all used functions).

According to the conference slides, it'll allow any function that just has a "catch exception". It does indeed support catches (i.e. the function itself can set up exception handlers, but callers needn't). Also be aware that "new" throws exceptions if there's no memory left.
Feb 22 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Manfred Nowak wrote:
 Walter Bright wrote:
 
 Don't have to compute it, just check it since it's part of the type 
 signature.

Enforcing, checking but not computing?

Yes.
 I don't get that. So I'll have 
 to wait for the docs for "nothrow".

It would work just like "nothrow" does for C++.
Feb 22 2008
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:

 It would work just like "nothrow" does for C++.

BTW, wasn't there one of your arguments to have no negation in keywords? Which would make "exfree" a better choice? -manfred
Feb 24 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Manfred Nowak wrote:
 Walter Bright wrote:
 
 It would work just like "nothrow" does for C++.

BTW, wasn't there one of your arguments to have no negation in keywords?

Yes. But everyone knows what "nothrow" means.
 Which would make "exfree" a better choice?

Feb 24 2008
parent Derek Parnell <derek psych.ward> writes:
On Sun, 24 Feb 2008 11:53:00 -0800, Walter Bright wrote:

 Manfred Nowak wrote:
 Walter Bright wrote:
 
 It would work just like "nothrow" does for C++.

BTW, wasn't there one of your arguments to have no negation in keywords?

Yes. But everyone knows what "nothrow" means.

ROTFLMAO -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Feb 24 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Graham St Jack wrote:
 It would work just like "nothrow" does for C++.

Just checking - I hope this means that if a nothrow function actually DID try to throw an exception (by calling something that throws), compiler- generated code would trap it and terminate the program with an error message?

No, but it will try to detect errors at compile time.
Feb 24 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright escribi贸:
 Graham St Jack wrote:
 It would work just like "nothrow" does for C++.

Just checking - I hope this means that if a nothrow function actually DID try to throw an exception (by calling something that throws), compiler- generated code would trap it and terminate the program with an error message?

No, but it will try to detect errors at compile time.

Does this mean this will not compile: int foo(int[] someArray, int someIndex) nothrow { return someArray[someIndex]; } but this will: int foo(int[] someArray, int someIndex) nothrow { if (someIndex < someArray.length) { return someArray[someIndex]; } else { return -1; } }
Feb 25 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:
 Does this mean this will not compile:
 
 int foo(int[] someArray, int someIndex) nothrow {
     return someArray[someIndex];
 }
 
 but this will:
 
 int foo(int[] someArray, int someIndex) nothrow {
     if (someIndex < someArray.length) {
         return someArray[someIndex];
     } else {
         return -1;
     }
 }

I don't know yet. But the idea is to do static checking of what can throw.
Feb 25 2008
next sibling parent reply eao197 <eao197 intervale.ru> writes:
On Mon, 25 Feb 2008 12:44:15 +0300, Walter Bright  =

<newshound1 digitalmars.com> wrote:

 Ary Borenszweig wrote:
 Does this mean this will not compile:
  int foo(int[] someArray, int someIndex) nothrow {
     return someArray[someIndex];
 }
  but this will:
  int foo(int[] someArray, int someIndex) nothrow {
     if (someIndex < someArray.length) {
         return someArray[someIndex];
     } else {
         return -1;
     }
 }

I don't know yet. But the idea is to do static checking of what can =

 throw.

Just my $0.02 about nothrow and DesignByContract: I think that nothrow a= re = incompatible with DbC. A function/method could have contracts or nothrow= = but not both of them. It is especially actual for virtual (non-final) = methods. Suppose that some class has: class A { public void cleanup() nothrow { ... }; } so it could be safely used in 'finally' statement: A someResource =3D acquireResource(); try { ... /* some processing */ ... } finally { someResource.cleanup; /* looks like exception-safe action */ } But if there is a derived class B, which overrides cleanup() with = postcondition: class B : A { public void cleanup() nothrow out { ... some checking ... } body { ... some actions ... } } and acquireResource() would return B instead of A, then the code above = won't be exception-safe. Moreover the behaviour of 'someResource.cleanup= ' = would depend on compiler switches. -- = Regards, Yauheni Akhotnikau
Feb 25 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
eao197 wrote:
 On Mon, 25 Feb 2008 12:44:15 +0300, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 Ary Borenszweig wrote:
 Does this mean this will not compile:
  int foo(int[] someArray, int someIndex) nothrow {
     return someArray[someIndex];
 }
  but this will:
  int foo(int[] someArray, int someIndex) nothrow {
     if (someIndex < someArray.length) {
         return someArray[someIndex];
     } else {
         return -1;
     }
 }

I don't know yet. But the idea is to do static checking of what can throw.

Just my $0.02 about nothrow and DesignByContract: I think that nothrow are incompatible with DbC. A function/method could have contracts or nothrow but not both of them. It is especially actual for virtual (non-final) methods. Suppose that some class has: class A { public void cleanup() nothrow { ... }; } so it could be safely used in 'finally' statement: A someResource = acquireResource(); try { ... /* some processing */ ... } finally { someResource.cleanup; /* looks like exception-safe action */ } But if there is a derived class B, which overrides cleanup() with postcondition: class B : A { public void cleanup() nothrow out { ... some checking ... } body { ... some actions ... } } and acquireResource() would return B instead of A, then the code above won't be exception-safe. Moreover the behaviour of 'someResource.cleanup' would depend on compiler switches.

So the code generated depends on compiler switches... Isn't this always true? The "nothrow" spec could only actually be used when building release mode, and in non-release mode code, exception handling frames are always set up. This means that nothrow functions can still use assert() and array indexing without worries, since these only throw exceptions in non-release-mode code. Of course, then problems occur when mixing code compiled with different switches...
Feb 26 2008
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 27 Feb 2008 10:42:07 +0300, Robert Fraser  =

<fraserofthenight gmail.com> wrote:

 eao197 wrote:
 On Mon, 25 Feb 2008 12:44:15 +0300, Walter Bright  =


 <newshound1 digitalmars.com> wrote:

 Ary Borenszweig wrote:
 Does this mean this will not compile:
  int foo(int[] someArray, int someIndex) nothrow {
     return someArray[someIndex];
 }
  but this will:
  int foo(int[] someArray, int someIndex) nothrow {
     if (someIndex < someArray.length) {
         return someArray[someIndex];
     } else {
         return -1;
     }
 }

I don't know yet. But the idea is to do static checking of what can =



 throw.



 are incompatible with DbC. A function/method could have contracts or =


 nothrow but not both of them. It is especially actual for virtual  =


 (non-final) methods. Suppose that some class has:
  class A {
   public void cleanup() nothrow { ... };
 }
  so it could be safely used in 'finally' statement:
  A someResource =3D acquireResource();
 try { ... /* some processing */ ... }
 finally {
   someResource.cleanup; /* looks like exception-safe action */
 }
  But if there is a derived class B, which overrides cleanup() with  =


 postcondition:
  class B : A {
   public void cleanup() nothrow
     out { ... some checking ... }
     body { ... some actions ... }
 }
  and acquireResource() would return B instead of A, then the code abo=


 won't be exception-safe. Moreover the behaviour of  =


 'someResource.cleanup' would depend on compiler switches.

So the code generated depends on compiler switches... Isn't this alway=

 true? The "nothrow" spec could only actually be used when building  =

 release mode, and in non-release mode code, exception handling frames =

 are always set up. This means that nothrow functions can still use  =

 assert() and array indexing without worries, since these only throw  =

 exceptions in non-release-mode code.

 Of course, then problems occur when mixing code compiled with differen=

 switches...

I'm affraid that you misunderstand my point. When you use a[i] or new in= = nothrow function you always known what could happen. But if you call = virtual method from any object you can't predict its behaviour. Because = = the method implementation in some derived class could define contract fo= r = that method. And you may don't known about it. And becouse of this I think that 'nothrow' is a kind of function contrac= t. = And if a function defines such contract then it can't redefine it in = derived classes. -- = Regards, Yauheni Akhotnikau
Feb 27 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
eao197 escribi贸:
 eao197 wrote:

nothrow function you always known what could happen. But if you call virtual method from any object you can't predict its behaviour. Because the method implementation in some derived class could define contract for that method. And you may don't known about it. And becouse of this I think that 'nothrow' is a kind of function contract. And if a function defines such contract then it can't redefine it in derived classes.

But contracts are predictable. Say B extends A, and A has a foo method. If foo says nothrow, than if B overrides foo, it must also be nothrow (this will be enforced by the compiler, I'm sure). For in and out, http://www.digitalmars.com/d/1.0/dbc.html shows there will be no problem.
Feb 27 2008
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 27 Feb 2008 12:40:03 +0300, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 eao197 escribi贸:
 eao197 wrote:

in nothrow function you always known what could happen. But if you call virtual method from any object you can't predict its behaviour. Because the method implementation in some derived class could define contract for that method. And you may don't known about it. And becouse of this I think that 'nothrow' is a kind of function contract. And if a function defines such contract then it can't redefine it in derived classes.

But contracts are predictable. Say B extends A, and A has a foo method. If foo says nothrow, than if B overrides foo, it must also be nothrow (this will be enforced by the compiler, I'm sure).

B.foo may looks like: void foo() nothrow in { assert( <some condition> ); } out { assert( <some condition> ); } body { <some code without exception> } Body of B.foo() doesn't throw exception but assert in pre/postcondition could do that. A call of B.foo could produce exception but B.foo is declared as 'nothrow' :( -- Regards, Yauheni Akhotnikau
Feb 27 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
eao197 wrote:
 B.foo may looks like:
 
 void foo() nothrow
   in { assert( <some condition> ); }
   out { assert( <some condition> ); }
   body { <some code without exception> }
 
 Body of B.foo() doesn't throw exception but assert in pre/postcondition 
 could do that. A call of B.foo could produce exception but B.foo is 
 declared as 'nothrow' :(
 

I'm happy with that. Contracts aren't compiled in release mode, and they aren't part of the function; they're part of the tests. I'd hate to have to avoid one language feature for reliability in order to gain another one.
Feb 27 2008
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 27 Feb 2008 16:56:34 +0300, Christopher Wright  
<dhasenan gmail.com> wrote:

 eao197 wrote:
 B.foo may looks like:
  void foo() nothrow
   in { assert( <some condition> ); }
   out { assert( <some condition> ); }
   body { <some code without exception> }
  Body of B.foo() doesn't throw exception but assert in  
 pre/postcondition could do that. A call of B.foo could produce  
 exception but B.foo is declared as 'nothrow' :(

I'm happy with that. Contracts aren't compiled in release mode, and they aren't part of the function; they're part of the tests. I'd hate to have to avoid one language feature for reliability in order to gain another one.

People are different. You want to compile your programs in release mode to remove any run-time checks and contracts. I want to save them in my programs to catch errors at the most earliest stage ('fail fast' principle is very important in server-side systems). But a programing language must provide logical and consistent rules for each of us. -- Regards, Yauheni Akhotnikau
Feb 27 2008
parent reply Russell Lewis <webmaster villagersonline.com> writes:
I wonder if asserts() should be the exception to nothrow.  Like eao197, 
I normally run my programs with assert()s turned on.  But it would be a 
shame to lose nothrow because of that.

Are assert()s catchable?  Other than in some sort of weird systems 
programming context (where you are running one program inside another), 
why would you want to catch them?  (I'm sure somebody has a compelling 
example...but would that example be ruined by 
asserts-that-penetrate-nothrow.)

eao197 wrote:
 On Wed, 27 Feb 2008 16:56:34 +0300, Christopher Wright 
 <dhasenan gmail.com> wrote:
 
 eao197 wrote:
 B.foo may looks like:
  void foo() nothrow
   in { assert( <some condition> ); }
   out { assert( <some condition> ); }
   body { <some code without exception> }
  Body of B.foo() doesn't throw exception but assert in 
 pre/postcondition could do that. A call of B.foo could produce 
 exception but B.foo is declared as 'nothrow' :(

I'm happy with that. Contracts aren't compiled in release mode, and they aren't part of the function; they're part of the tests. I'd hate to have to avoid one language feature for reliability in order to gain another one.

People are different. You want to compile your programs in release mode to remove any run-time checks and contracts. I want to save them in my programs to catch errors at the most earliest stage ('fail fast' principle is very important in server-side systems). But a programing language must provide logical and consistent rules for each of us. --Regards, Yauheni Akhotnikau

Feb 27 2008
parent reply eao197 <eao197 intervale.ru> writes:
On Thu, 28 Feb 2008 07:27:24 +0300, Russell Lewis  =

<webmaster villagersonline.com> wrote:

 I wonder if asserts() should be the exception to nothrow.  Like eao197=

 I normally run my programs with assert()s turned on.  But it would be =

 shame to lose nothrow because of that.

 Are assert()s catchable?

Yes, it is catchable: import std.stdio; import std.asserterror; void do_something( int i, int j ) in { assert( i < j, "i must be lesser than j" ); } body { writefln( "i=3D", i, ", j=3D", j ); } void main() { try { do_something( 0, 1 ); do_something( 1, 0 ); } catch( AssertError x ) { writefln( x ); } }
 Other than in some sort of weird systems programming context (where yo=

 are running one program inside another), why would you want to catch  =

 them?

It is not necessary to catch AssertError. Sometimes it is necessary to = catch any error. For example, in a HTTP-server you could start processin= g = of a new request and catch different kinds of errors to make appropriate= = response: void processNewRequest( SomeRequestData request ) { try { requestProcessingActions( request ); } catch( Error x ) { logError( x ); classifyErrorAndMakeAppropriateResponse( x ); } } There is no difference between some application-logic error, index out o= f = range error, no memory error or AssertError. The request processing fail= ed = and the reason must be logged.
  (I'm sure somebody has a compelling example...but would that example =

 ruined by asserts-that-penetrate-nothrow.)

May be I don't understand your question, but I think that nothrow should= = help write exception-safe code. For example, some resource cleanup actio= ns = in finally statements: auto firstStream =3D createStream(); auto secondStream =3D createStream(); auto thirdStream =3D createStream(); try { firstStream.open( 'first' ); secondStream.open( 'second' ); thirdStream.open( 'third' ); ... some actions with firstStream, secondStream and thirdStream ... } finally { // All stream should be closed here. firstStream.close; secondStream.close; thirdStream.close; ... some other cleanup code... } It is rather naive resource cleanup code, because without nothrow = specification we can't assume that a 'close' call doesn't throw an = exception. If close can throw exceptions we must rewrite it, for example= : finally { void safeClose( Stream s ) { try { s.close; } catch( Error ) {} } safeClose( firstStream ); safeClose( secondStream ); safeClose( thirdStream ); ... some other cleanup code... } But if we know that close doesn't throw exceptions then we can write les= s = code (without safeClose helper function). And I suppose that 'nothrow' i= s = a promise of function's developer that the function doesn't throw an = exception. But if 'close' is written as: close() nothrow in { assert( is_opened(), "close() must be called only in stream is = open" ); } body { ... } I think that such implementation brokes a promise about non-throwing = exception. For example, what if some exception is thrown at = secondStream.open("second") in the sample above? We are going to finally= = statement, successfully close firstStream, but get AssertError at = secondStream.close(). It breaks finally statement and we have no chance = to = perform other cleanup code. So I think that nothrow is a contract which is violated by any assert in= = in/out statements. And because of that nothrow shouldn't be used with = in/out contracts. But here is another kind of problem with nothrow. I don't know is it = possible to write really exception free code in D (AFAIK it is impossibl= e = on JVM/.NET because VM could raise some of it internal exception at any = = moment). Exceptions could be everywere -- on accessing array items, on = string concatenations, on new statements, on calling some functions with= = pre/postconditions and so on. So probably nothrow function could throw = some kind of exceptions even if function's writter don't known about the= m = (it reminds me unchecked exceptions in Java which could be thrown despit= e = of method's exception specification). In such case AssertError could be = = one of such 'unchecked exception' in D, and in such case nothrow could b= e = combined with in/out statements. But in such case the profit from nothro= w = is under doubt for me. Disclaimer: I know that my sample with streams and resource cleanup in = finally statement could be rewritten in different ways. It is just a = sample.
 eao197 wrote:
 On Wed, 27 Feb 2008 16:56:34 +0300, Christopher Wright  =


 <dhasenan gmail.com> wrote:

 eao197 wrote:
 B.foo may looks like:
  void foo() nothrow
   in { assert( <some condition> ); }
   out { assert( <some condition> ); }
   body { <some code without exception> }
  Body of B.foo() doesn't throw exception but assert in  =




 pre/postcondition could do that. A call of B.foo could produce  =




 exception but B.foo is declared as 'nothrow' :(

I'm happy with that. Contracts aren't compiled in release mode, and =



 they aren't part of the function; they're part of the tests. I'd hat=



 to have to avoid one language feature for reliability in order to ga=



 another one.



 mode to remove any run-time checks and contracts. I want to save them=


 in my programs to catch errors at the most earliest stage ('fail fast=


 principle is very important in server-side systems). But a programing=


 language must provide logical and consistent rules for each of us.
  --Regards,
 Yauheni Akhotnikau


-- = Regards, Yauheni Akhotnikau
Feb 28 2008
parent reply Russell Lewis <webmaster villagersonline.com> writes:
eao197 wrote:
 On Thu, 28 Feb 2008 07:27:24 +0300, Russell Lewis 
 <webmaster villagersonline.com> wrote:
 
 I wonder if asserts() should be the exception to nothrow.  Like 
 eao197, I normally run my programs with assert()s turned on.  But it 
 would be a shame to lose nothrow because of that.

 Are assert()s catchable?

Yes, it is catchable:

(snip)
 Other than in some sort of weird systems programming context (where 
 you are running one program inside another), why would you want to 
 catch them?

It is not necessary to catch AssertError. Sometimes it is necessary to catch any error. For example, in a HTTP-server you could start processing of a new request and catch different kinds of errors to make appropriate response:

I agree that a web server needs to post an appropriate response. But if an assert() has failed, you don't know if the failure is in your main program, in a library, or maybe even in your network code. In that case, you can't really rely on your program to keep working correctly, and the only sane solution would be to restart it. My argument, then, is that you need a metaprogram or "watchdog" (such as the init process in *NIX, or maybe just a "web server launcher") which manages the server programs and restarts them when they crash.
 There is no difference between some application-logic error, index out 
 of range error, no memory error or AssertError. The request processing 
 failed and the reason must be logged.

From the web client's or the system administrator's perspective, I agree. The error should be reported to the client, and logged for the admin. But from the internal-consistency-of-the-program perspective, these are very different. An out-of-memory error is a (possibly transient) memory issue. The internal logic of the program is intact. Array index out of range might (or might not) be survivable. But a failed assert() means that something is (or might be) deeply wrong with the internal logic of the program. That's not something, IMHO, that you ought to try to catch and then forget. Things which are recoverable should throw Exceptions. Things which are fatal should fail assert()s.
Feb 28 2008
parent reply eao197 <eao197 intervale.ru> writes:
On Thu, 28 Feb 2008 19:34:45 +0300, Russell Lewis  =

<webmaster villagersonline.com> wrote:

  It is not necessary to catch AssertError. Sometimes it is necessary =


 catch any error. For example, in a HTTP-server you could start  =


 processing of a new request and catch different kinds of errors to ma=


 appropriate response:

I agree that a web server needs to post an appropriate response. But =

 an assert() has failed, you don't know if the failure is in your main =

 program, in a library, or maybe even in your network code.  In that  =

 case, you can't really rely on your program to keep working correctly,=

 and the only sane solution would be to restart it.

Violation of contract is not a sign of unrecoverable failure of the = program, expecially for preconditions. Quite the contrary contracts help= = detect unappropriate conditions at earlier stages. For example, SMS body in 140 bytes long. 7-bit message could be up to 16= 0 = symbols, packed into 140 bytes SMS body. You could have 7-bit message = packing functions with precondition: byte[] pack7bitMessage( byte[] message ) in { assert( message.length <=3D 160 ); } body { ... } When pack7bitMessage receives message which is longer than 160 symbols = there isn't any sign of unrecoverable error. For example, the too long = body of message may be received from SMPP PDU submit_sm from a ESME who = = simply had made an error in their PDU. It may be a sign of presence of = error in your code for submit_sm parsing (length of SMS body not checked= ) = but there nothing fatal for whole application. And that is a situation where application abort and restart don't solve = a = problem -- ESME simply repeat the problem submit_sm after server restart= = and server go down again and so on.
 My argument, then, is that you need a metaprogram or "watchdog" (such =

 the init process in *NIX, or maybe just a "web server launcher") which=

 manages the server programs and restarts them when they crash.

A rather complex application is build from a several layers. A failure o= n = some layer should abort all current processing on that layer, but parent= = layer could restart the problem layer. So that model with = metaprogram/watchdogs or supervisor processes (from Erlang) could be = implemented inside a single application with use of safe languages like = D, = Java or C#. -- = Regards, Yauheni Akhotnikau
Feb 29 2008
next sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
It seems that we have a significant programming style difference.  Let 
me explain and advocate for my style...

I believe that assert()s are ways to programmatically document things 
that the program must enforce.  An in() contract on a function is a 
statement that says "any code which calls me, but violates this 
contract, is buggy."  Exceptions are the way to programmatically handle 
unusual conditions in well-ordered ways.

So, in your example below, since pack7bitMessage asserts that the 
message must be no more than 160 characters, then any code which called 
it must enforce that contract.  Any code which didn't enforce the 
contract has a bug.

IMHO, if what you want is to have a function which will take input of 
any length, but refuse to encode things which are longer than 160 
characters, then it should be coded as follows:

   byte[] pack7bitMessage( byte[] message )
   {
     if(message.length > 160)
       throw InputTooLongException;

     ... encode ...
   }

This is why I argued that assert()s are unrecoverable errors and 
exceptions are reasonably recoverable.


Finally, let me ask you a question:

If an failed assert() doesn't represent an unrecoverable logic error, 
then what does???


eao197 wrote:
 On Thu, 28 Feb 2008 19:34:45 +0300, Russell Lewis 
 <webmaster villagersonline.com> wrote:
 
  It is not necessary to catch AssertError. Sometimes it is necessary 
 to catch any error. For example, in a HTTP-server you could start 
 processing of a new request and catch different kinds of errors to 
 make appropriate response:

I agree that a web server needs to post an appropriate response. But if an assert() has failed, you don't know if the failure is in your main program, in a library, or maybe even in your network code. In that case, you can't really rely on your program to keep working correctly, and the only sane solution would be to restart it.

Violation of contract is not a sign of unrecoverable failure of the program, expecially for preconditions. Quite the contrary contracts help detect unappropriate conditions at earlier stages. For example, SMS body in 140 bytes long. 7-bit message could be up to 160 symbols, packed into 140 bytes SMS body. You could have 7-bit message packing functions with precondition: byte[] pack7bitMessage( byte[] message ) in { assert( message.length <= 160 ); } body { ... } When pack7bitMessage receives message which is longer than 160 symbols there isn't any sign of unrecoverable error. For example, the too long body of message may be received from SMPP PDU submit_sm from a ESME who simply had made an error in their PDU. It may be a sign of presence of error in your code for submit_sm parsing (length of SMS body not checked) but there nothing fatal for whole application. And that is a situation where application abort and restart don't solve a problem -- ESME simply repeat the problem submit_sm after server restart and server go down again and so on.
 My argument, then, is that you need a metaprogram or "watchdog" (such 
 as the init process in *NIX, or maybe just a "web server launcher") 
 which manages the server programs and restarts them when they crash.

A rather complex application is build from a several layers. A failure on some layer should abort all current processing on that layer, but parent layer could restart the problem layer. So that model with metaprogram/watchdogs or supervisor processes (from Erlang) could be implemented inside a single application with use of safe languages like D, Java or C#. --Regards, Yauheni Akhotnikau

Feb 29 2008
parent eao197 <eao197 intervale.ru> writes:
On Fri, 29 Feb 2008 18:42:05 +0300, Russell Lewis  =

<webmaster villagersonline.com> wrote:

 I believe that assert()s are ways to programmatically document things =

 that the program must enforce.  An in() contract on a function is a  =

 statement that says "any code which calls me, but violates this  =

 contract, is buggy."  Exceptions are the way to programmatically handl=

 unusual conditions in well-ordered ways.

Contract may be considered another way: a function with precodition says= = "I guarantee correct behaviour only when you keeps my precondition".
 So, in your example below, since pack7bitMessage asserts that the  =

 message must be no more than 160 characters, then any code which calle=

 it must enforce that contract.  Any code which didn't enforce the  =

 contract has a bug.

Yes it is. But a bug in code is not always should lead to abortion of = entire application.
 IMHO, if what you want is to have a function which will take input of =

 any length, but refuse to encode things which are longer than 160  =

 characters, then it should be coded as follows:

    byte[] pack7bitMessage( byte[] message )
    {
      if(message.length > 160)
        throw InputTooLongException;

      ... encode ...
    }

Yes that function could be rewritten in such way. But there could be = condition when DbC is preferable than defensive programming: - contracts are part of function prototype, so conract help understandin= g = function behaviour. For example, try look at EiffelBase reference manual= = (http://docs.eiffel.com) -- sometimes bodies of 'require' and 'ensure' = give more information that description of a methods; - contracts could be turned off in release mode when you sure that there= = isn't critical bugs. So, function with contracts: byte[] pack7bitMessage( byte[] message ) in { assert( message ); assert( message.length <=3D 160 ); assert( !is8bitCharFound( message ) ); } body { ... } will be much faster in speed-critical applications then the function whi= ch = is written in defensive-programming style.
 Finally, let me ask you a question:

 If an failed assert() doesn't represent an unrecoverable logic error, =

 then what does???

As in the case with ordinal exception -- it depends. When you try to add= a = member into associative array you and get NoMemory exception you don't = know is that exception would be unrecoverable or recoverable. If you wri= te = yet another WordCounter example such exception will be fatal for your = application. But if you write, for example, some image-transformation = program for http://picasa.google.com/ you could simple throw away curren= t = problematic image, clear all resouces which was allocated for that image= , = and go to next image in queue.
 eao197 wrote:
 On Thu, 28 Feb 2008 19:34:45 +0300, Russell Lewis  =


 <webmaster villagersonline.com> wrote:

  It is not necessary to catch AssertError. Sometimes it is necessar=




 to catch any error. For example, in a HTTP-server you could start  =




 processing of a new request and catch different kinds of errors to =




 make appropriate response:

I agree that a web server needs to post an appropriate response. Bu=



 if an assert() has failed, you don't know if the failure is in your =



 main program, in a library, or maybe even in your network code.  In =



 that case, you can't really rely on your program to keep working  =



 correctly, and the only sane solution would be to restart it.



 program, expecially for preconditions. Quite the contrary contracts  =


 help detect unappropriate conditions at earlier stages.
  For example, SMS body in 140 bytes long. 7-bit message could be up t=


 160 symbols, packed into 140 bytes SMS body. You could have 7-bit  =


 message packing functions with precondition:
  byte[] pack7bitMessage( byte[] message )
   in { assert( message.length <=3D 160 ); }
   body { ... }
  When pack7bitMessage receives message which is longer than 160 symbo=


 there isn't any sign of unrecoverable error. For example, the too lon=


 body of message may be received from SMPP PDU submit_sm from a ESME w=


 simply had made an error in their PDU. It may be a sign of presence o=


 error in your code for submit_sm parsing (length of SMS body not  =


 checked) but there nothing fatal for whole application.
  And that is a situation where application abort and restart don't  =


 solve a problem -- ESME simply repeat the problem submit_sm after  =


 server restart and server go down again and so on.

 My argument, then, is that you need a metaprogram or "watchdog" (suc=



 as the init process in *NIX, or maybe just a "web server launcher") =



 which manages the server programs and restarts them when they crash.=



  A rather complex application is build from a several layers. A failu=


 on some layer should abort all current processing on that layer, but =


 parent layer could restart the problem layer. So that model with  =


 metaprogram/watchdogs or supervisor processes (from Erlang) could be =


 implemented inside a single application with use of safe languages li=


 D, Java or C#.
  --Regards,
 Yauheni Akhotnikau


-- = Regards, Yauheni Akhotnikau
Feb 29 2008
prev sibling parent Charles D Hixson <charleshixsn earthlink.net> writes:
eao197 wrote:
 On Thu, 28 Feb 2008 19:34:45 +0300, Russell Lewis 
 <webmaster villagersonline.com> wrote:
 
  It is not necessary to catch AssertError. Sometimes it is necessary 
 to catch any error. For example, in a HTTP-server you could start 
 processing of a new request and catch different kinds of errors to 
 make appropriate response:

I agree that a web server needs to post an appropriate response. But if an assert() has failed, you don't know if the failure is in your


 
 For example, SMS body in 140 bytes long. 7-bit message could be up to 
 160 symbols, packed into 140 bytes SMS body. You could have 7-bit 
 message packing functions with precondition:
 
 byte[] pack7bitMessage( byte[] message )
   in { assert( message.length <= 160 ); }
   body { ... }
 

I think you are misunderstanding the purpose of assert and of other conditions. Remember, these statements will be stripped out of the code when it is compiled for release. As such, they should only be used to detect conditions which are genuine errors. The reason that they might be cause would be so that the actual error could be raised from the location where the error is generated, rather than from where it was detected. In Other Words: Don't use contracts as a substitute for conditionals, even if the conditional *would* raise an exception. They aren't the same concept. Now I'll grant that in some languages the two concepts are fused, and conditionals are constrained to do double duty as exceptions. Even in those languages, however, there is often a flag that will cause assertions to become null statements when compiled with optimization (or without debugging turned on). [N.B.: The prior paragraph is based on certain dialects of C or C++ that are over a decade old now. It may not apply to currently extant compilers.]
Feb 29 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Graham St Jack wrote:
 It will be a good trick if you can pull it off. I don't see how it can be 
 done without examining the source code of all the called functions, 
 leaving us back where we started with throw specs.
 
 The C++ approach of a runtime check isn't perfect, but at least it can be 
 done, and provides a more definite form of documentation than comments.

Are you sure it does a runtime check for nothrow?
 If the static checks aren't done well enough and runtime checks aren't 
 done at all, I would prefer to rely on comments.

Feb 25 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Graham St Jack wrote:
 It will be a good trick if you can pull it off. I don't see how it can be
 done without examining the source code of all the called functions,
 leaving us back where we started with throw specs.

 The C++ approach of a runtime check isn't perfect, but at least it can be
 done, and provides a more definite form of documentation than comments.


I think it depends on the compiler. The MS compiler, for example, ignores exception specs, except possibly for nothrow (it's been a while and I cant recall). However, isn't the app supposed to terminate if an exception is thrown from a nothrow routine? I don't have my copy of the spec handy or I'd check. Sean
Feb 26 2008
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Graham St Jack (Graham.StJack internode.on.net)'s article
 On Mon, 25 Feb 2008 08:55:17 -0800, Walter Bright wrote:
 Graham St Jack wrote:
 It will be a good trick if you can pull it off. I don't see how it can
 be done without examining the source code of all the called functions,
 leaving us back where we started with throw specs.

 The C++ approach of a runtime check isn't perfect, but at least it can
 be done, and provides a more definite form of documentation than
 comments.

Are you sure it does a runtime check for nothrow?

at all. We use the throw() and throw(list-of-exceptions) specs all the time in our C++ code, relying on the runtime checking to tell us if we get it wrong. This is quite horrible compared to static checking, but it is a lot better than nothing, because we find out what exception was thrown and which throw-spec was violated. The vast majority of functions in our C++ code use an empty throw-spec, so if D had nothrow with some static checking plus a runtime check, I would be better off than I am now with C++. Of course I would be even better off if the static checking was complete, but that seems to be too tricky.

The nice thing about offering nothrow only is that it implicitly marks any unlabeled routine as one that may throw an exception. The problem in C++ with explicit exception specs is those unlabeled routines--they can throw anything but they're also callable from nothrow routines because they might not actually throw anything. It's a mess. Sean
Feb 26 2008
prev sibling parent reply Georg Wrede <georg nospam.org> writes:
Walter Bright wrote:
 Graham St Jack wrote:
 
 It will be a good trick if you can pull it off. I don't see how it can 
 be done without examining the source code of all the called functions, 
 leaving us back where we started with throw specs.

 The C++ approach of a runtime check isn't perfect, but at least it can 
 be done, and provides a more definite form of documentation than 
 comments.

Are you sure it does a runtime check for nothrow?
 If the static checks aren't done well enough and runtime checks aren't 
 done at all, I would prefer to rely on comments.


IMHO, it would behoove the compiler to keep track of possible/potential exceptions a function can throw. (Just as well as (again, IMHO) it would behoove the compiler to keep track of functions that /potentially/ have side effects.) The workload for doing either defines a pattern, and doing the other is simply a repetition of the pattern. Therefore, doing both is not much more work than doing only one of these. In the optimal future, entering a function would give you information (not necessarily runtime, but definitely info when browsing the docs) on whether it potentially generates an exception/changes data. A year after this info is standard in the docs, several new ideas about Functional Programming will emerge, in D. (Ermmmm, new to D, anyway.) ----- Keeping track of these two things may be considered superfluous drudgery, but the potential benefits well outweigh the invested effort.
Mar 03 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Georg Wrede wrote:
 Walter Bright wrote:
 Graham St Jack wrote:

 It will be a good trick if you can pull it off. I don't see how it 
 can be done without examining the source code of all the called 
 functions, leaving us back where we started with throw specs.

 The C++ approach of a runtime check isn't perfect, but at least it 
 can be done, and provides a more definite form of documentation than 
 comments.

Are you sure it does a runtime check for nothrow?
 If the static checks aren't done well enough and runtime checks 
 aren't done at all, I would prefer to rely on comments.


IMHO, it would behoove the compiler to keep track of possible/potential exceptions a function can throw. (Just as well as (again, IMHO) it would behoove the compiler to keep track of functions that /potentially/ have side effects.)

There's a few problems with what you're asking for: - extern(D) - .di files - delegates - dynamic loading There's also the matter of executable bloat.
Mar 03 2008
parent Georg Wrede <georg nospam.org> writes:
    Caveat lector!
    Er, upon proofreading it dawned upon me:

        This post does NOT interest Walter or anybody
        else who is concerned with compiler issues,
        the laguage itself, or optimizing. (What, is that
        like everybody in this newsgroup??)

        BUT, it still is very relevant to the advancement
        of D.

        IDE developers, framework architects, and library
        programmers may want to read this.


Christopher Wright wrote:
 Georg Wrede wrote:
 IMHO, it would behoove the compiler to keep track of 
 possible/potential exceptions a function can throw. (Just as well as 
 (again, IMHO) it would behoove the compiler to keep track of functions 
 that /potentially/ have side effects.)

There's a few problems with what you're asking for: - extern(D) - .di files - delegates - dynamic loading

We probably should reverse the bookkeeping to what the function does /not/ throw. With that, the above things would all be classified as unknown, which translates to "no exception is guaranteed to not get thrown". (For recursive implications, see below.)
 There's also the matter of executable bloat.

All of this is compile-time-only stuff. Once compiled, the code should "look like" code that's never heard of the issue. But it still does the Right Thing. To be more precise, we're not [here] interested in what a function throws, only in what it is guaranteed /not/ to throw. For example, an in-place string transformation would be guaranteed to not throw an out-of-memory exception. (Unless the programmer is an idiot, but that doesn't count here.) By the same token, anytime I write a function in my code, the result of what other functions it calls and which they call in their turn, can be drawn as a tree structure. If we had machine readable documentation on each of the leaves, telling us /what it will not throw/, we might go on to the function that uses the leaf, see if it creates new kinds of exceptions and whether it may throw the new ones or any existing exceptions, and then compute the Set Intersection of the exceptions any of them /can not throw/. This gives us a guaranteed set of exceptions that /will not be thrown/ as a result of calling this (er...) Intermediate Node in the tree. By recursively applying this reasoning we ultimately end up with a hard document about my Brand New function, and what it doesn't throw. (( And as you pointed out earlier, anytime any of the leaves or the nodes uses any of: extern(D), .di files, delegates, dynamic loading; the entire tree gets tainted. That might actually be a shortcut from traversing the tree since we don't need any more information: NO EXCEPTION is guaranteed not to be thrown. )) While we're at it, this precisely same kind of analysis could be made about side effects. And even using precisely the same mechanics. All we need is data on the primary functions. Everything else is automatically computable from that. Including the library functions. (As in Phobos, etc.) The end result is, by the time we've written our own function, it is KNOWABLE what exceptions OUR function doesn't throw. And it is knowable whether our function DOES NOT create ANY side effects. The value of these two hardly need advertising. Functional programming, real-time stuff, robust code, secure code, the list goes on and on.
Mar 07 2008
prev sibling next sibling parent Russell Lewis <webmaster villagersonline.com> writes:
The example would be (reasonably) compilable, without whole-program 
knowledege, if foo() had an in{} condition which asserted that the index 
was valid.

It would be possible (though not trivial) for the compiler to say "ah, 
provided that the caller follows the in{} contract, this function cannot 
throw an exception."

Walter Bright wrote:
 Ary Borenszweig wrote:
 Does this mean this will not compile:

 int foo(int[] someArray, int someIndex) nothrow {
     return someArray[someIndex];
 }

 but this will:

 int foo(int[] someArray, int someIndex) nothrow {
     if (someIndex < someArray.length) {
         return someArray[someIndex];
     } else {
         return -1;
     }
 }

I don't know yet. But the idea is to do static checking of what can throw.

Feb 25 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Graham St Jack wrote:
 It will be a good trick if you can pull it off. I don't see how it can be 
 done without examining the source code of all the called functions, 
 leaving us back where we started with throw specs.

I think the idea would be that nothrow is part of the function signature and a nothrow function can only call other nothrow functions or wrap any function calls or news in a catch(Exception) (since there's no way to know specifically which exceptions could be thrown).
Feb 26 2008
parent Georg Wrede <georg nospam.org> writes:
Robert Fraser wrote:
 Graham St Jack wrote:
 
 It will be a good trick if you can pull it off. I don't see how it can 
 be done without examining the source code of all the called functions, 
 leaving us back where we started with throw specs.

I think the idea would be that nothrow is part of the function signature and a nothrow function can only call other nothrow functions or wrap any function calls or news in a catch(Exception) (since there's no way to know specifically which exceptions could be thrown).

Yes. Therefore, the compiler has to know which functions are "nothrow", at compile time. Keeping track of this would be a lot of work -- ONE single time when implementing the bokkeeping of it. Later, the compiler programmer (Walter?) would only have to deal with this when creating totally new basic functions or severely altering the existing ones. And at that time it would not feel like a lot of work. Probably it would be like filling in a few items on a row in a (sql-like) table of function properties for the compiler.
Mar 03 2008
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Ary Borenszweig wrote:

 Walter Bright escribi贸:
 Graham St Jack wrote:
 It would work just like "nothrow" does for C++.

Just checking - I hope this means that if a nothrow function actually DID try to throw an exception (by calling something that throws), compiler- generated code would trap it and terminate the program with an error message?

No, but it will try to detect errors at compile time.

Does this mean this will not compile: int foo(int[] someArray, int someIndex) nothrow { return someArray[someIndex]; }

I sincerely hope that design by contract will allow for us to iron out issues like this. Ideally, something very near the following should be valid: int foo(int[] someArray, int someIndex) nothrow in{ assert(someIndex < someArray.length && someIndex >= 0); } body{ return someArray[someIndex]; } I've always hoped for in and out contracts to be usable by the compiler for optimization (such as verifying nothrow). I know this looks like it violates the nothrow (when not compiled with the release flag), but I'm ok with that for code I'm debugging. Printing the failed assert and ending the program is more useful to me anyway.
Feb 25 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:
 Graham St Jack wrote:
 It would work just like "nothrow" does for C++.

Just checking - I hope this means that if a nothrow function actually DID try to throw an exception (by calling something that throws), compiler- generated code would trap it and terminate the program with an error message?

No, but it will try to detect errors at compile time.

And nothrow will be a valid part of a delegate signature, correct? So I can use nothrow with delegates. Nothrow is especially tricky because it doesn't require a function call to get an exception. But those cases are relatively rare.
Feb 25 2008
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 20 de febrero a las 18:58 me escribiste:
 Graham St Jack wrote:
It is also very helpful when writing code to know that a function you are
calling won't 
throw an exception - it means you have three kinds of functions: those that
don't throw, 
those with comments telling you what they throw, and those that you need to fix
the 
comments for.

Experience with this indicates that it is impractical to specify what exceptions a function may throw. The only practical states to specify are: 1) does not throw 2) always throws 3) might throw What is thrown is not reliably computable. For example: import foo; void test() { foo.bar(); } What exceptions does test() throw? That would require knowledge of the import foo, which is not necessarily knowable and can change over time.

And what's the difference with nothrow? foo.bar's nothrow-ness "is not necessarily knowable and can change over time". It's exactly the same, you're just limiting the way you specify exceptions, but you are specifing them after all. This is like limiting C++ exception specification to nothing or an empty throw() qualifier. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Hace diez a帽os ten铆a una visi贸n Pero nadie m谩s la vi贸 y hoy sigo pidiendo perd贸n
Feb 25 2008
parent Georg Wrede <georg nospam.org> writes:
Leandro Lucarella wrote:
 Walter Bright, el 20 de febrero a las 18:58 me escribiste:
 
Graham St Jack wrote:

It is also very helpful when writing code to know that a function you are
calling won't 
throw an exception - it means you have three kinds of functions: those that
don't throw, 
those with comments telling you what they throw, and those that you need to fix
the 
comments for.

Experience with this indicates that it is impractical to specify what exceptions a function may throw. The only practical states to specify are: 1) does not throw 2) always throws 3) might throw What is thrown is not reliably computable. For example: import foo; void test() { foo.bar(); } What exceptions does test() throw? That would require knowledge of the import foo, which is not necessarily knowable and can change over time.

And what's the difference with nothrow? foo.bar's nothrow-ness "is not necessarily knowable and can change over time". It's exactly the same, you're just limiting the way you specify exceptions, but you are specifing them after all. This is like limiting C++ exception specification to nothing or an empty throw() qualifier.

Of course, there should be a Nothrow-offense exception. Right?!! Such an exception would be thrown whenever a function that's declared as not throwing an exception actually does throw one.
Mar 03 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Extrawurst wrote:
 yeah but what happend to the express-such-things-via-documention policy 
 to keep syntax simple ?

It looks like the bane of all my Java existence, exception specifications, are back, under the mask of "optimization" this time. But, unlike const, you're not required to use nothrow to make use of libraries which use it, so it's up to you to ignore it or not.
Feb 21 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser escribi:
 Extrawurst wrote:
 yeah but what happend to the express-such-things-via-documention 
 policy to keep syntax simple ?

It looks like the bane of all my Java existence, exception specifications, are back, under the mask of "optimization" this time. But, unlike const, you're not required to use nothrow to make use of libraries which use it, so it's up to you to ignore it or not.

In fact, it's just serves as a hint to the compiler, right? Like "inline" in C?
Feb 21 2008
parent lutger <lutger.blijdestijn gmail.com> writes:
Ary Borenszweig wrote:

 Robert Fraser escribi:
 Extrawurst wrote:
 yeah but what happend to the express-such-things-via-documention
 policy to keep syntax simple ?

It looks like the bane of all my Java existence, exception specifications, are back, under the mask of "optimization" this time. But, unlike const, you're not required to use nothrow to make use of libraries which use it, so it's up to you to ignore it or not.

In fact, it's just serves as a hint to the compiler, right? Like "inline" in C?

In the slides from the conference it is mentioned that nothrow is statically checked by the compiler. I think it's not only about optimization, it's also useful for writing exception-safe code.
Feb 21 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Robert Fraser wrote:
 Extrawurst wrote:
 yeah but what happend to the express-such-things-via-documention 
 policy to keep syntax simple ?

It looks like the bane of all my Java existence, exception specifications, are back, under the mask of "optimization" this time. But, unlike const, you're not required to use nothrow to make use of libraries which use it, so it's up to you to ignore it or not.

The downsides of general exception specifications are not shared by nothrow.
Feb 21 2008
prev sibling parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
 Indicating that a function/method won't throw an exception?

yeah but what happend to the express-such-things-via-documention policy to keep syntax simple ?

The compiler can probably do some optimization if it knows that

It is also very helpful when writing code to know that a function you are calling won't throw an exception - it means you have three kinds of functions: those that don't throw, those with comments telling you what they throw, and those that you need to fix the comments for.
Feb 20 2008
next sibling parent Graham St Jack <graham.stjack internode.on.net> writes:
 It would work just like "nothrow" does for C++.

Just checking - I hope this means that if a nothrow function actually DID try to throw an exception (by calling something that throws), compiler- generated code would trap it and terminate the program with an error message?
Feb 24 2008
prev sibling next sibling parent Graham St Jack <graham.stjack internode.on.net> writes:
On Mon, 25 Feb 2008 01:44:15 -0800, Walter Bright wrote:

 Ary Borenszweig wrote:
 Does this mean this will not compile:
 
 int foo(int[] someArray, int someIndex) nothrow {
     return someArray[someIndex];
 }
 
 but this will:
 
 int foo(int[] someArray, int someIndex) nothrow {
     if (someIndex < someArray.length) {
         return someArray[someIndex];
     } else {
         return -1;
     }
 }

I don't know yet. But the idea is to do static checking of what can throw.

It will be a good trick if you can pull it off. I don't see how it can be done without examining the source code of all the called functions, leaving us back where we started with throw specs. The C++ approach of a runtime check isn't perfect, but at least it can be done, and provides a more definite form of documentation than comments. If the static checks aren't done well enough and runtime checks aren't done at all, I would prefer to rely on comments.
Feb 25 2008
prev sibling next sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Mon, 25 Feb 2008 08:55:17 -0800, Walter Bright wrote:

 Graham St Jack wrote:
 It will be a good trick if you can pull it off. I don't see how it can
 be done without examining the source code of all the called functions,
 leaving us back where we started with throw specs.
 
 The C++ approach of a runtime check isn't perfect, but at least it can
 be done, and provides a more definite form of documentation than
 comments.

Are you sure it does a runtime check for nothrow?

g++ certainly does runtime checking. I'm sure it does no static checking at all. We use the throw() and throw(list-of-exceptions) specs all the time in our C++ code, relying on the runtime checking to tell us if we get it wrong. This is quite horrible compared to static checking, but it is a lot better than nothing, because we find out what exception was thrown and which throw-spec was violated. The vast majority of functions in our C++ code use an empty throw-spec, so if D had nothrow with some static checking plus a runtime check, I would be better off than I am now with C++. Of course I would be even better off if the static checking was complete, but that seems to be too tricky.
 
 If the static checks aren't done well enough and runtime checks aren't
 done at all, I would prefer to rely on comments.


Feb 26 2008
prev sibling next sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Wed, 27 Feb 2008 00:47:00 +0000, Sean Kelly wrote:

 == Quote from Graham St Jack (Graham.StJack internode.on.net)'s article
 On Mon, 25 Feb 2008 08:55:17 -0800, Walter Bright wrote:
 Graham St Jack wrote:
 It will be a good trick if you can pull it off. I don't see how it
 can be done without examining the source code of all the called
 functions, leaving us back where we started with throw specs.

 The C++ approach of a runtime check isn't perfect, but at least it
 can be done, and provides a more definite form of documentation than
 comments.

Are you sure it does a runtime check for nothrow?

checking at all. We use the throw() and throw(list-of-exceptions) specs all the time in our C++ code, relying on the runtime checking to tell us if we get it wrong. This is quite horrible compared to static checking, but it is a lot better than nothing, because we find out what exception was thrown and which throw-spec was violated. The vast majority of functions in our C++ code use an empty throw-spec, so if D had nothrow with some static checking plus a runtime check, I would be better off than I am now with C++. Of course I would be even better off if the static checking was complete, but that seems to be too tricky.

The nice thing about offering nothrow only is that it implicitly marks any unlabeled routine as one that may throw an exception. The problem in C++ with explicit exception specs is those unlabeled routines--they can throw anything but they're also callable from nothrow routines because they might not actually throw anything. It's a mess. Sean

Agreed.
Feb 26 2008
prev sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Tue, 26 Feb 2008 23:36:34 -0800, Robert Fraser wrote:

 Graham St Jack wrote:
 It will be a good trick if you can pull it off. I don't see how it can
 be done without examining the source code of all the called functions,
 leaving us back where we started with throw specs.

I think the idea would be that nothrow is part of the function signature and a nothrow function can only call other nothrow functions or wrap any function calls or news in a catch(Exception) (since there's no way to know specifically which exceptions could be thrown).

That would work, but my feeling is that it would be so restrictive that hardly any functions could be nothrow.
Feb 27 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 http://www.digitalmars.com/d/2.0/changelog.html
  Now allow static arrays to be lvalues.

Cool, and about time! :) I've just tried it out and it's so much more natural. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Feb 28 2008