Re: DMD 1.039 and 2.023 releases
Denis Koroskin:
void doSomething(T)(int i) {
if (i == 0) {
#if (is(T == A)) {
A.SomeAlias x;
#} else if (is(T == B)) {
B.SubType x;
#} else {
T x;
#}
x = ... whatever
}
else
int y = x;
}
A different possibility is to use {# ... #}
static if (is(T == A)) {#
A.SomeAlias x;
#} else if (is(T == B)) {#
Bye,
bearophile
Re: DMD 1.039 and 2.023 releases
Michel Fortin michel.for...@michelf.com wrote in message news:gksbop$2tt...@digitalmars.com... On 2009-01-16 22:17:57 -0500, Daniel Keep daniel.keep.li...@gmail.com said: The '#' has a nice connotation for anyone who's used to C/C++, given that those statements are handled at compile time. The problem, of course, is that they're really nothing like C preprocessor statements. They have a different syntax, and completely different capabilities. What's more, you can't mix them across statements/expressions, so I suspect it would just cause more confusion. Additionally, there's this: #endif Unless you plan on moving all control structures to BASIC/pascal style, I don't think it's wise to start mixing them all over the place. All good reasons, but there is one more: If you use #if in the standard D language, then it'll make it harder to use a real C preprocessor when you need it. D has support for #line in the language so that the compiler gives you error messages relative to the right included file and line in a preprocessor output. D doesn't have a preprocessor built-in, and doesn't recommand using one either, but it has support for it. Introducing #if in the D language would break that support. I do like the idea of a scopeless block syntax in theory, though it's not something that's really been an issue for me. Me neither. The only time I've had a problem with any scope/scopeless block issue is having gotten bitten once by the inability to use a mixin to declare a scope object (since it only lives within the mixin's own implicit scope and not the scope where the mixin is instantiated (as I would have expected)...which does seem odd now that I think about it, because an int a, for instance, declared inside a mixin still outlives the mixin, even though I don't think that happens with an explicit block). But that doesn't really need a special scopeless block syntax to be fixed.
Re: DMD 1.039 and 2.023 releases
On Sat, Jan 17, 2009 at 6:26 AM, Yigal Chripun yigal...@gmail.com wrote:
bearophile wrote:
Bill Baxter:
To me it's hard to see those variable declarations as being anything
other than scoped to the blocks they're in.
So all I'm saying is if we could have some different delimiters for
non-scope blocks then it might be nice, and make it easier to see when
scopes are ending and when they are not.
*Now* I understand, and I see your point.
It's the usual problem: ASCII doesn't have enough ways to represent
containers and delimiters :-)
So if this is your original code (I have improved your indentations and
improved readability a little):
[...]
I don't think lot of people will appreciate those.
So the lack of different block delimiters may make this problem have no
better solution.
Bye,
bearophile
in C# they use the same syntax as the c pre-processor for conditional
compilation and such even though C# doesn't have a pre-processor and the
syntax is interpreted by the compiler. the above would be something like:
void doSomething(T)(int i) {
if (i == 0) {
#if (is(T == A))
A.SomeAlias x;
#elif (is(T == B))
B.SubType x;
#else
T x;
#endif
x = ... whatever
}
else
int y = x;
}
D can always revert to this kind of syntax for compile time code.
I kinda like that, actually, but I doubt it'll be very popular around here.
--bb
Re: DMD 1.039 and 2.023 releases
Bill Baxter wrote:
[snip]
in C# they use the same syntax as the c pre-processor for conditional
compilation and such even though C# doesn't have a pre-processor and the
syntax is interpreted by the compiler. the above would be something like:
void doSomething(T)(int i) {
if (i == 0) {
#if (is(T == A))
A.SomeAlias x;
#elif (is(T == B))
B.SubType x;
#else
T x;
#endif
x = ... whatever
}
else
int y = x;
}
D can always revert to this kind of syntax for compile time code.
I kinda like that, actually, but I doubt it'll be very popular around here.
--bb
The '#' has a nice connotation for anyone who's used to C/C++, given
that those statements are handled at compile time. The problem, of
course, is that they're really nothing like C preprocessor statements.
They have a different syntax, and completely different capabilities.
What's more, you can't mix them across statements/expressions, so I
suspect it would just cause more confusion.
Additionally, there's this:
#endif
Unless you plan on moving all control structures to BASIC/pascal style,
I don't think it's wise to start mixing them all over the place.
I do like the idea of a scopeless block syntax in theory, though it's
not something that's really been an issue for me.
-- Daniel
Re: DMD 1.039 and 2.023 releases
Walter Bright wrote:
snip
Writing labeled block statements is something more likely to be
generated by an automated D code generator,
I still don't get it.
and it's convenient to be able to control if a scope is generated or not.
To force a block to create a scope:
{{
...
}}
To force a block not to create a scope:
version (all) {
...
}
Stewart.
Re: DMD 1.039 and 2.023 releases
Bill Baxter:
To me it's hard to see those variable declarations as being anything
other than scoped to the blocks they're in.
So all I'm saying is if we could have some different delimiters for
non-scope blocks then it might be nice, and make it easier to see when
scopes are ending and when they are not.
*Now* I understand, and I see your point.
It's the usual problem: ASCII doesn't have enough ways to represent containers
and delimiters :-)
So if this is your original code (I have improved your indentations and
improved readability a little):
void doSomething(T)(int i) {
if (i == 0) {
static if (is(T == A)) {
A.SomeAlias x;
} else static if(is(T == B)) {
B.SubType x;
} else {
T x;
}
x = ... whatever
}
else
int y = x;
}
This can be the new version following your idea:
void doSomething(T)(int i) {
if (i == 0) {
static if (is(T == A)) ::
A.SomeAlias x;
:: else static if(is(T == B)) ::
B.SubType x;
:: else ::
T x;
::
x = ... whatever
}
else
int y = x;
}
But the problem is that :: don't have a head and tail, so the code is even less
easy to read.
This version uses (* ... *), used in Pascal to denote comments:
void doSomething(T)(int i) {
if (i == 0) {
static if (is(T == A)) (*
A.SomeAlias x;
*) else static if(is(T == B)) (*
B.SubType x;
*) else (*
T x;
*)
x = ... whatever
}
else
int y = x;
}
I don't like that too, even if it's a bit better than the version with ::.
Two other possibilities:
void doSomething(T)(int i) {
if (i == 0) {
static if (is(T == A)) {|
A.SomeAlias x;
|} else static if(is(T == B)) {|
B.SubType x;
|} else {|
T x;
|}
x = ... whatever
}
else
int y = x;
}
void doSomething(T)(int i) {
if (i == 0) {
static if (is(T == A)) {#
A.SomeAlias x;
#} else static if(is(T == B)) {#
B.SubType x;
#} else {#
T x;
#}
x = ... whatever
}
else
int y = x;
}
I don't think lot of people will appreciate those.
So the lack of different block delimiters may make this problem have no better
solution.
Bye,
bearophile
Re: DMD 1.039 and 2.023 releases
On Wed, Jan 7, 2009 at 12:31 AM, Walter Bright newshou...@digitalmars.com wrote: Regarding the pure optimizations done by D2, how can the LDC compiler do the same? Are them done by the front-end? I changed nothing with the compiler. I just rewrote the runtime long division function. Can you say non sequitur? He asked about pure optimization, not long division.
Re: DMD 1.039 and 2.023 releases
It appears that you've also fixed http://d.puremagic.com/issues/show_bug.cgi?id=2359 :D /* which might've been the same issue as http://d.puremagic.com/issues/show_bug.cgi?id=2527 */ Perhaps I can finally update from 1.031 : Thanks a bunch! -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Re: DMD 1.039 and 2.023 releases
Denis Koroskin wrote: On Wed, 07 Jan 2009 07:03:27 +0300, Bill Baxter wbax...@gmail.com wrote: 2009/1/7 Walter Bright newshou...@digitalmars.com: Faster long divides! No progress on faster long compiles though? --bb Small statistics on compilation time of my small project: DMD2.021 - 16 seconds DMD2.022 - 46 seconds DMD2.023 - 15 seconds (and an Internal error: ..\ztc\cod4.c 357 on one of source code files) :) Wow this one really sucks. For me this makes nearly every D2 using project unbuildable ;(
Re: DMD 1.039 and 2.023 releases
I'm happy to see Bugzilla 2518(scope(success) not execuate and RAII variable
destructor is not called) has been fixed, Great !
I have some questions when I check dstress suite and Bugzilla.
In Bugzilla 99, according to test case:
int main(){
int i;
label:
{
scope(exit) i++;
i=3;
}
if(i != 4){
assert(0);
}
return 0;
}
You said:
The test case behaves as expected, because labels do not introduce a new scope
when followed by { }.
Then I check the online manual, and found:
labels, scope(), pragma, condition compile(version/debug/static if) would be
followed by NonScopeStatement.
It is easy to understand scope/condition compile followed by a
NonScopeStatement,
but what is the meaning of Labeled Statements + NonScopeStatement ?
If I understand the rule I would make least mistakes, so can you do some
explain for me ? Thanks.
Walter Bright Wrote:
Faster long divides!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.039.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.023.zip
Re: DMD 1.039 and 2.023 releases
torhu wrote: 1.039 hangs while trying to build my DWT app, just like 1.038 did. It just seems to never finish, so I kill it after a while. Don't know if it's related to this issue or not. I need a reproducible example.
Re: DMD 1.039 and 2.023 releases
redsea wrote:
I'm happy to see Bugzilla 2518(scope(success) not execuate and RAII
variable destructor is not called) has been fixed, Great !
I have some questions when I check dstress suite and Bugzilla.
In Bugzilla 99, according to test case:
int main(){ int i; label: { scope(exit) i++; i=3; }
if(i != 4){ assert(0); }
return 0; }
You said:
The test case behaves as expected, because labels do not introduce a
new scope when followed by { }.
Then I check the online manual, and found:
labels, scope(), pragma, condition compile(version/debug/static if)
would be followed by NonScopeStatement.
It is easy to understand scope/condition compile followed by a
NonScopeStatement, but what is the meaning of Labeled Statements
+ NonScopeStatement ?
A NonScopeStatement is a statement that, even if it has { }, does not
introduce a new scope.
If I understand the rule I would make least mistakes, so can you do
some explain for me ? Thanks.
Re: DMD 1.039 and 2.023 releases
Jason House wrote:
Walter Bright Wrote:
redsea wrote:
I'm happy to see Bugzilla 2518(scope(success) not execuate and RAII
variable destructor is not called) has been fixed, Great !
I have some questions when I check dstress suite and Bugzilla.
In Bugzilla 99, according to test case:
int main(){ int i; label: { scope(exit) i++; i=3; }
if(i != 4){ assert(0); }
return 0; }
You said:
The test case behaves as expected, because labels do not introduce a
new scope when followed by { }.
Then I check the online manual, and found:
labels, scope(), pragma, condition compile(version/debug/static if)
would be followed by NonScopeStatement.
It is easy to understand scope/condition compile followed by a
NonScopeStatement, but what is the meaning of Labeled Statements
+ NonScopeStatement ?
A NonScopeStatement is a statement that, even if it has { }, does not
introduce a new scope.
I don't think this answers their question. What curly braces mean
after a label is clearly a design decision that you made when writing
D. It seems that the choice is the opposite of what people expect.
Can you explain why it should be NonScope?
Restating in the form of a question... When would you _ever_ want {...}
to not form a scope?
Later,
Brad
Re: DMD 1.039 and 2.023 releases
On Thu, 08 Jan 2009 06:25:11 +0300, Brad Roberts bra...@puremagic.com wrote:
Jason House wrote:
Walter Bright Wrote:
redsea wrote:
I'm happy to see Bugzilla 2518(scope(success) not execuate and RAII
variable destructor is not called) has been fixed, Great !
I have some questions when I check dstress suite and Bugzilla.
In Bugzilla 99, according to test case:
int main(){ int i; label: { scope(exit) i++; i=3; }
if(i != 4){ assert(0); }
return 0; }
You said:
The test case behaves as expected, because labels do not introduce a
new scope when followed by { }.
Then I check the online manual, and found:
labels, scope(), pragma, condition compile(version/debug/static if)
would be followed by NonScopeStatement.
It is easy to understand scope/condition compile followed by a
NonScopeStatement, but what is the meaning of Labeled Statements
+ NonScopeStatement ?
A NonScopeStatement is a statement that, even if it has { }, does not
introduce a new scope.
I don't think this answers their question. What curly braces mean
after a label is clearly a design decision that you made when writing
D. It seems that the choice is the opposite of what people expect.
Can you explain why it should be NonScope?
Restating in the form of a question... When would you _ever_ want {...}
to not form a scope?
Later,
Brad
The only possible example I can think of is a case inside switch:
switch (i)
{
case 42:
{
}
}
Re: DMD 1.039 and 2.023 releases
Reply to Brad,
Restating in the form of a question... When would you _ever_ want
{...} to not form a scope?
static if(foo)
{
int i;
float x;
}
Re: DMD 1.039 and 2.023 releases
On Thu, 08 Jan 2009 07:22:53 +0300, BCS a...@pathlink.com wrote:
Reply to Brad,
Restating in the form of a question... When would you _ever_ want
{...} to not form a scope?
static if(foo)
{
int i;
float x;
}
Yeah, and version(foo) belongs here, too.
Re: DMD 1.039 and 2.023 releases
On Thu, Jan 8, 2009 at 1:27 PM, Denis Koroskin 2kor...@gmail.com wrote:
On Thu, 08 Jan 2009 07:22:53 +0300, BCS a...@pathlink.com wrote:
Reply to Brad,
Restating in the form of a question... When would you _ever_ want
{...} to not form a scope?
static if(foo)
{
int i;
float x;
}
Yeah, and version(foo) belongs here, too.
I think I said this before, but I do think it would be nice if there
was some kind of alternate non-scope block delimiter syntax in D.
When you have static ifs mixed with regular ifs and versions it starts
to be pretty difficult to see the flow of things.
Something like
static if (x) ::
some stuff
::
--bb
Re: DMD 1.039 and 2.023 releases
BCS wrote:
Reply to Brad,
Restating in the form of a question... When would you _ever_ want
{...} to not form a scope?
static if(foo)
{
int i;
float x;
}
That and the version one are good examples.
However, the case example isn't. It actually already forms a scope, and
that's a good thing. Example:
switch (foo)
{
case 1:
{
int i;
}
case 2:
i = 0; // build error (error: undefined identifier i
}
Later,
Brad
Re: DMD 1.039 and 2.023 releases
Brad Roberts wrote:
Jason House wrote:
I don't think this answers their question. What curly braces mean
after a label is clearly a design decision that you made when writing
D. It seems that the choice is the opposite of what people expect.
Can you explain why it should be NonScope?
Restating in the form of a question... When would you _ever_ want {...}
to not form a scope?
version (foo)
{
int i;
}
...
version (foo)
{
bar(i);
}
Writing labeled block statements is something more likely to be
generated by an automated D code generator, and it's convenient to be
able to control if a scope is generated or not.
Re: DMD 1.039 and 2.023 releases
2009/1/7 Walter Bright newshou...@digitalmars.com: Faster long divides! No progress on faster long compiles though? --bb
Re: DMD 1.039 and 2.023 releases
On Tue, Jan 6, 2009 at 11:03 PM, Bill Baxter wbax...@gmail.com wrote: 2009/1/7 Walter Bright newshou...@digitalmars.com: Faster long divides! No progress on faster long compiles though? --bb The D2 changelog says that he undid the fix to 2500, which might be the cause. But no word on whether it was the cause, or if D1 got the revert as well.
Re: DMD 1.039 and 2.023 releases
On Wed, 07 Jan 2009 06:53:27 +0300, Walter Bright newshou...@digitalmars.com wrote: Faster long divides! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.039.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.023.zip Nice! Before you start closing fixed issues, I'd like to ask you add short fix discription wherever possible, because it is sometimes hard to understand what is fixed and how, especially in ambiguous cases. BTW, D1 is 2 years old by now (DMD1.000 was released on January, 2 in 2007). Congratulations!
Re: DMD 1.039 and 2.023 releases
On Wed, Jan 7, 2009 at 1:09 PM, Denis Koroskin 2kor...@gmail.com wrote: On Wed, 07 Jan 2009 06:53:27 +0300, Walter Bright newshou...@digitalmars.com wrote: Faster long divides! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.039.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.023.zip Nice! Before you start closing fixed issues, I'd like to ask you add short fix discription wherever possible, because it is sometimes hard to understand what is fixed and how, especially in ambiguous cases. BTW, D1 is 2 years old by now (DMD1.000 was released on January, 2 in 2007). Congratulations! Whoa! I would have believed 1 year. Doesn't seem like 2. --bb
Re: DMD 1.039 and 2.023 releases
On Wed, 07 Jan 2009 07:16:38 +0300, Denis Koroskin 2kor...@gmail.com wrote: On Wed, 07 Jan 2009 07:11:52 +0300, Bill Baxter wbax...@gmail.com wrote: On Wed, Jan 7, 2009 at 1:09 PM, Denis Koroskin 2kor...@gmail.com wrote: On Wed, 07 Jan 2009 06:53:27 +0300, Walter Bright newshou...@digitalmars.com wrote: Faster long divides! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.039.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.023.zip Nice! Before you start closing fixed issues, I'd like to ask you add short fix discription wherever possible, because it is sometimes hard to understand what is fixed and how, especially in ambiguous cases. BTW, D1 is 2 years old by now (DMD1.000 was released on January, 2 in 2007). Congratulations! Whoa! I would have believed 1 year. Doesn't seem like 2. --bb It will be a year for D2 in ten days. Ahhhmm.. 2 years as well, sorry for confusion.
Re: DMD 1.039 and 2.023 releases
On Wed, 07 Jan 2009 07:11:52 +0300, Bill Baxter wbax...@gmail.com wrote: On Wed, Jan 7, 2009 at 1:09 PM, Denis Koroskin 2kor...@gmail.com wrote: On Wed, 07 Jan 2009 06:53:27 +0300, Walter Bright newshou...@digitalmars.com wrote: Faster long divides! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.039.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.023.zip Nice! Before you start closing fixed issues, I'd like to ask you add short fix discription wherever possible, because it is sometimes hard to understand what is fixed and how, especially in ambiguous cases. BTW, D1 is 2 years old by now (DMD1.000 was released on January, 2 in 2007). Congratulations! Whoa! I would have believed 1 year. Doesn't seem like 2. --bb It will be a year for D2 in ten days.
Re: DMD 1.039 and 2.023 releases
On Tue, Jan 6, 2009 at 11:51 PM, Walter Bright newshou...@digitalmars.com wrote: Jarrett Billingsley wrote: The D2 changelog says that he undid the fix to 2500, which might be the cause. But no word on whether it was the cause, or if D1 got the revert as well. D1 got the same reversion. Wee!
Re: DMD 1.039 and 2.023 releases
On Wed, 07 Jan 2009 07:03:27 +0300, Bill Baxter wbax...@gmail.com wrote: 2009/1/7 Walter Bright newshou...@digitalmars.com: Faster long divides! No progress on faster long compiles though? --bb Small statistics on compilation time of my small project: DMD2.021 - 16 seconds DMD2.022 - 46 seconds DMD2.023 - 15 seconds (and an Internal error: ..\ztc\cod4.c 357 on one of source code files) :)
Re: DMD 1.039 and 2.023 releases
V 1.039 compiles my dlibs fine, but I have not timed the compilation times yet. The long divides are much faster than before and almost as the ones done by GCC, good work. The timings of the division benchmark I have shown last time: DMD1.038: 63.7 s DMD1.039: 12.2 s GCC4.2.1: 11.1 s Regarding the pure optimizations done by D2, how can the LDC compiler do the same? Are them done by the front-end? Bye, bearophile
Re: DMD 1.039 and 2.023 releases
Denis Koroskin wrote: (and an Internal error: ..\ztc\cod4.c 357 on one of source code files) :) Bugzilla report, pls!
Re: DMD 1.039 and 2.023 releases
On Wed, Jan 7, 2009 at 2:10 PM, bearophile bearophileh...@lycos.com wrote: V 1.039 compiles my dlibs fine, but I have not timed the compilation times yet. The long divides are much faster than before and almost as the ones done by GCC, good work. The timings of the division benchmark I have shown last time: DMD1.038: 63.7 s DMD1.039: 12.2 s GCC4.2.1: 11.1 s Regarding the pure optimizations done by D2, how can the LDC compiler do the same? Are them done by the front-end? Rockin'. Compile times seem unchanged wrt DMD 1.037 here too. Partial IFTI here I come! -- bb
