Re: dmd 1.069 and 2.054 release
Walter Bright wrote: On 7/20/2011 2:29 PM, Don wrote: The new CTFE docs got left out somehow. Not sure what you're referring to? Sorry, it seems something went wrong with my repository. When I pushed, it didn't push to anything... I'll redo it.
Re: dmd 1.069 and 2.054 release
On 7/20/2011 2:29 PM, Don wrote: The new CTFE docs got left out somehow. Not sure what you're referring to?
Re: dmd 1.069 and 2.054 release
2011-07-14
Thread
#1052; #1080; #1093; #1072; #1080; #1083; #1057; #1090; #1088; #1072; #1096; #1091; #1085;
Is there any reason for linux.mak to still exist there then? http://www.digitalmars.com/d/2.0/dmd-linux.html#compiling_dmd seems outdated then and I really would like to get it right - maintaining dmd2 in Arch Linux User Repository is my responsibility ( and I was using linux.mak till now ).
Re: dmd 1.069 and 2.054 release
On Thursday 14 July 2011 12:44:29 #1052; #1080; #1093; #1072; #1080; #1083; #1057; #1090; #1088; #1072; #1096; #1091; #1085; wrote: Is there any reason for linux.mak to still exist there then? http://www.digitalmars.com/d/2.0/dmd-linux.html#compiling_dmd seems outdated then and I really would like to get it right - maintaining dmd2 in Arch Linux User Repository is my responsibility ( and I was using linux.mak till now ). It's not in github. I expect that it's a result of Walter not creating the zip file from scratch every time. So, it was cruft that didn't get cleaned out. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
Walter: I was forgetting, DMD 2.054 has fulfilled this enhancement request too: http://d.puremagic.com/issues/show_bug.cgi?id=5250 Bye, bearophile
Re: dmd 1.069 and 2.054 release
On Tuesday 12 July 2011 19:18:10 Leandro Lucarella wrote: Jonathan M Davis, el 12 de julio a las 21:51 me escribiste: If you want how the language treats deprecated to change, then feel free to create a pull request and try and talk Walter into it. Arguably, warning about deprecation and then only failing to compile when the deprecated stuff is actually removed is the better way to handle things. But that's not how D is designed (probably at least in part because Walter doesn't really believe in warnings). So, feel free to try and talk Walter into it, but unless the default behavior is changed, deprecating something is going to silently break people's code unless you tell them about it first (which is the point of scheduling something for deprecation). So, your solution is issuing warnings behind the compiler and Walter's back. Great! I love this! Now I remember why I loved D so much =P Nothing is being done behind anyone's back. It was Walter who pushed for stuff to be scheduled for deprecation before being actually deprecated, because he didn't want code breaking on people without any warning. We decided to use pragmas to present messages to the user informing them of the impending deprecation, because the language doesn't currently have anything built in with the concept of scheduled for deprecation. It was either that or not warn about the impending deprecation except in the changelog and documentation, in which case, anyone who doesn't pay enough attention to those would still end up with their code being broken without warning when the symbols are actually deprecated. So, we went for the messages. If the majority of people would prefer not to have the messages and risk having their code break when something is deprecated, because they missed the notice in the changelog or documentation, then the messages will go away. But we thought that they were a good idea, so we put them in there. None of this is trying to circumvent Walter or the compiler. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
It occured for the mixin method to generate the different exception classes. Specifically the toCamelCase method was not working there. Ok. Do you have any idea how to solve the problem I described in D.learn? (template instance cannot use local.)
Re: dmd 1.069 and 2.054 release
Looks like it fails to build under Linux using linux.mak makefile due to missing intrange.c / intrange.o in file lists. Linking stage errors. When I add them manually, everything works like a charm. I think compiling it worked just fine for me.
Re: dmd 1.069 and 2.054 release
On 7/13/2011 9:58 AM, #1052 wrote: Looks like it fails to build under Linux using linux.mak makefile due to missing intrange.c / intrange.o in file lists. Linking stage errors. When I add them manually, everything works like a charm. Could this one be fixed? Use posix.mak for the linux builds now.
Re: dmd 1.069 and 2.054 release
Damn, I am getting some impressive results comparing VC C++ builds and
DMD D builds. I'm using the PortAudio library and a stress-test that
comes with the project. It tries to generate as many sinewaves as
possible until some maximum is reached. The PortAudio C DLL library is
built in release mode, and is then implicitly linked with a C or D
project. Here's the results:
Stops on 500 max sines, or 0.80 max cpu.
C debug:
numSines = 229, CPU load = 0.802464 // cpu max reached
C release:
numSines = 500, CPU load = 0.793717 // max sines reached
D debug:
numSines = 258, CPU load = 0.800412 // cpu max reached
D release:
numSines = 500, CPU load = 0.629622 // max sines reached
Notice how the C version barely made it to 500 sines in release mode
(almost hit 0.80 CPU), but the D version had plenty of free CPU left
(this is all done on a single core).
I've enabled debug symbols and explicitly enabled floating-point
exceptions in debug builds in the realtime-priority callback function,
via:
version (Debug)
{
import std.math;
FloatingPointControl fpc;
fpc.enableExceptions(FloatingPointControl.severeExceptions);
}
and that still beats C's debug build by a small margin. There were 3
function macros which I've converted to auto templates, I think those
got inlined in release mode. I'm using exceptions in the D version
compared to C's use of goto's.
Here's the C version code: http://codepad.org/4ERFVcSS
And the D version: http://codepad.org/a7XL8wNW
D debug switches (I had to use Debug instead of debug due to a
critical bug): -g -version=Debug
D release switches: -release -inline -O -noboundscheck
Anyway if you want to try it yourself (Windows only for now), do:
git clone https://github.com/AndrejMitrovic/DPortAudio
cd and run \portaudio\build.bat
cd and run \samples\build.bat
The C examples are in the PortAudio project and if you want to compare
with those you'll have to build them yourself.
Re: dmd 1.069 and 2.054 release
Is this really that much impressive considering the fact that you
compare results where the most work is done in the linked DLL itself no
matter what code calls it, whether it is D or C, Debug or Release ??
On 14.07.2011 00:26, Andrej Mitrovic wrote:
Damn, I am getting some impressive results comparing VC C++ builds and
DMD D builds. I'm using the PortAudio library and a stress-test that
comes with the project. It tries to generate as many sinewaves as
possible until some maximum is reached. The PortAudio C DLL library is
built in release mode, and is then implicitly linked with a C or D
project. Here's the results:
Stops on 500 max sines, or 0.80 max cpu.
C debug:
numSines = 229, CPU load = 0.802464 // cpu max reached
C release:
numSines = 500, CPU load = 0.793717 // max sines reached
D debug:
numSines = 258, CPU load = 0.800412 // cpu max reached
D release:
numSines = 500, CPU load = 0.629622 // max sines reached
Notice how the C version barely made it to 500 sines in release mode
(almost hit 0.80 CPU), but the D version had plenty of free CPU left
(this is all done on a single core).
I've enabled debug symbols and explicitly enabled floating-point
exceptions in debug builds in the realtime-priority callback function,
via:
version (Debug)
{
import std.math;
FloatingPointControl fpc;
fpc.enableExceptions(FloatingPointControl.severeExceptions);
}
and that still beats C's debug build by a small margin. There were 3
function macros which I've converted to auto templates, I think those
got inlined in release mode. I'm using exceptions in the D version
compared to C's use of goto's.
Here's the C version code: http://codepad.org/4ERFVcSS
And the D version: http://codepad.org/a7XL8wNW
D debug switches (I had to use Debug instead of debug due to a
critical bug): -g -version=Debug
D release switches: -release -inline -O -noboundscheck
Anyway if you want to try it yourself (Windows only for now), do:
git clone https://github.com/AndrejMitrovic/DPortAudio
cd and run \portaudio\build.bat
cd and run \samples\build.bat
The C examples are in the PortAudio project and if you want to compare
with those you'll have to build them yourself.
Re: dmd 1.069 and 2.054 release
It's a simplistic test, I agree. The work done in PortAudio is initalization and release of hardware, and conversion of different sample rates and buffer sizes, and buffer types, when necessary. The Pa_GetStreamCpuLoad() call measures how long it takes for patestCallback() to finish and based on that calculates the CPU usage.
Re: dmd 1.069 and 2.054 release
In general good work!
But again phobos makes a simple std.string function unCTFEable.
Now I have to use an ugly hack to achieve something as simple as toUpper:
mixin( (){char[] tmp = dup; toUpperInPlace(tmp); return tmp;}() );
Re: dmd 1.069 and 2.054 release
Now I have to use an ugly hack to achieve something as simple as
toUpper:
mixin( (){char[] tmp = dup; toUpperInPlace(tmp); return tmp;}() );
Damn i found that too and wanted to mention it in the dmd-beta list b4
release. But the workaround is simple. At least this one was fixed:
http://lists.puremagic.com/pipermail/dmd-beta/2011-July/000773.html
Cause that was making cl4d with all its string mixins pretty much
unbuildable at all.
Yeah I've done some crazy shit in the cl4d code :D
But in the end that was just another workaround cause template mixins
couldn't mixin constructors.
Good news: this seems to have been fixed.
Bad news: there still is another problem. I asked about it in D.learn.
btw, that problem you reported, where did it occur in cl4d?
Re: dmd 1.069 and 2.054 release
Jonathan M Davis, el 11 de julio a las 22:21 me escribiste: On Tuesday 12 July 2011 01:28:11 Leandro Lucarella wrote: Jonathan M Davis, el 11 de julio a las 18:15 me escribiste: Despite the confusing non-standard descriptions in --help, -w is the Treat warnings as errors setting, so it *should* stop compilation - that's the whole point of -w. The proper Turn warnings on setting is -wi, not -w. True. But when we're dealing with messages for something which is scheduled for deprecation What's the point of scheduled for deprecation anyway? Things are deprecated, or aren't, anything else should be in the documentation. You can always use deprecated features using a compiler, so again... what's the point of scheduled for deprectation? I can't really understand that concept. The idea is to have 3 stages while deprecating something. 1. Scheduled for Deprecation. 2. Deprecated. 3. Removed. When a symbol has been deprecated, -d is required to compile any code using that symbol. So, deprecation breaks code. You either have to change your code so that it doesn't use the deprecated symbol, or you have to change your build scripts to use -d. In either case, deprecating a symbol without warning is going to cause problems for anyone maintaining code which uses that symbol. If you don't want your code to break when something is deprecated, you should *always* compile with -d, so no, you don't have to change the build system if you always have -d. Maybe all needed is just a -di (as in -wi), where deprecation are informed but not treated as errors. Scheduled for deprecation makes no sense, it's a user decision to use deprecated code or not, and if should be a user decision if he/she wants a warning about deprecated stuff or not. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- No tengo alas, como un planeador. No tengo luces, como un plato volador. Perdi mi rumbo soy un auto chocador.
Re: dmd 1.069 and 2.054 release
On 2011-07-12 10:07, Leandro Lucarella wrote: Jonathan M Davis, el 11 de julio a las 22:21 me escribiste: On Tuesday 12 July 2011 01:28:11 Leandro Lucarella wrote: Jonathan M Davis, el 11 de julio a las 18:15 me escribiste: Despite the confusing non-standard descriptions in --help, -w is the Treat warnings as errors setting, so it *should* stop compilation - that's the whole point of -w. The proper Turn warnings on setting is -wi, not -w. True. But when we're dealing with messages for something which is scheduled for deprecation What's the point of scheduled for deprecation anyway? Things are deprecated, or aren't, anything else should be in the documentation. You can always use deprecated features using a compiler, so again... what's the point of scheduled for deprectation? I can't really understand that concept. The idea is to have 3 stages while deprecating something. 1. Scheduled for Deprecation. 2. Deprecated. 3. Removed. When a symbol has been deprecated, -d is required to compile any code using that symbol. So, deprecation breaks code. You either have to change your code so that it doesn't use the deprecated symbol, or you have to change your build scripts to use -d. In either case, deprecating a symbol without warning is going to cause problems for anyone maintaining code which uses that symbol. If you don't want your code to break when something is deprecated, you should *always* compile with -d, so no, you don't have to change the build system if you always have -d. Maybe all needed is just a -di (as in -wi), where deprecation are informed but not treated as errors. Scheduled for deprecation makes no sense, it's a user decision to use deprecated code or not, and if should be a user decision if he/she wants a warning about deprecated stuff or not. Except, of course, that good cood generally won't use anything that's deprecated, since the deprecated item is going to go away. The user can decide to use -d and use deprecated code if it makes sense for them, but that really should be decided on a case-by-case basis. Most programmers won't want to use -d. So, they're not going to compile with -d by default. So, deprecating something will break their code. By saying that you're scheduling something for deprecation, you're giving the user time to deal with the change before it breaks their code. Now, I could see an argument for changing how deprecation works so that deprecated has no effect unless a flag turns it on, in which case, the user is deciding whether they want to warned about using deprecated code. In such a case, scheduled for deprecation isn't quite as necessary, but then you're just going to break everyone's code when you remove the function (at least everyone who didn't use the flag to be warned about using deprecated symbols). And rather than being able to then change their build scripts to use -d while they fix the problem, they then _have_ to go change their code (or not upgrade their libraries) in order for their code to compile. But that's not how deprecated works in D. When a symbol is deprecated, it's an error to use it unless you compile with - d. So, there is no warning about using deprecated stuff. It's an outright error. It just so happens that you can turn it off if you need to (hopefully as a quick fix). And given that deprecating a symbol introduces errors into the code of anyone who uses that symbol, informing people ahead of time gives them the opportunity to change their code before it breaks. The result is a much smoother process. 1. Something is scheduled for deprecation, so programmers then have the time to figure out what they're going to do to change their code, and they have time to make the changes. Nothing breaks. No one is forced to make immediate changes. 2. The symbol is then deprecated. Anyone who did not take the time to make changes as they were told that they were going to have to do then has broken code, but they have the quick fix of compiling with -d if they need to. They're still going to have to figure out what they're going to do about changing their code, and they're forced to look at the problem at least far enough to enable -d, but their code can still work with some changes to their build scripts. 3. The symbol is outright removed. Programmers have had ample time to change their code, and if they haven't, they now have to. But they were told that the symbol was going away and had to have made changes to their build scripts to even use it this long, so the developer of the library hasn't just screwed them over. The idea is to provide a smooth path for necessary changes. And just deprecating something out of the blue does _not_ do that. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
On 2011-07-12 13:52, Leandro Lucarella wrote: Jonathan M Davis, el 12 de julio a las 18:12 me escribiste: When a symbol has been deprecated, -d is required to compile any code using that symbol. So, deprecation breaks code. You either have to change your code so that it doesn't use the deprecated symbol, or you have to change your build scripts to use -d. In either case, deprecating a symbol without warning is going to cause problems for anyone maintaining code which uses that symbol. If you don't want your code to break when something is deprecated, you should *always* compile with -d, so no, you don't have to change the build system if you always have -d. Maybe all needed is just a -di (as in -wi), where deprecation are informed but not treated as errors. Scheduled for deprecation makes no sense, it's a user decision to use deprecated code or not, and if should be a user decision if he/she wants a warning about deprecated stuff or not. Except, of course, that good cood generally won't use anything that's deprecated, since the deprecated item is going to go away. The user can decide to use -d and use deprecated code if it makes sense for them, but that really should be decided on a case-by-case basis. Most programmers won't want to use -d. So, they're not going to compile with -d by default. So, deprecating something will break their code. By saying that you're scheduling something for deprecation, you're giving the user time to deal with the change before it breaks their code. Now, I could see an argument for changing how deprecation works so that deprecated has no effect unless a flag turns it on, in which case, the user is deciding whether they want to warned about using deprecated code. In such a case, scheduled for deprecation isn't quite as necessary, but then you're just going to break everyone's code when you remove the function (at least everyone who didn't use the flag to be warned about using deprecated symbols). And rather than being able to then change their build scripts to use -d while they fix the problem, they then _have_ to go change their code (or not upgrade their libraries) in order for their code to compile. But that's not how deprecated works in D. So then, why don't we fix it (patch attached, you can apply it with 'git am file'). I think -di is the real solution to the problem. Things are deprecated or not, and people want to be informed if they are using something deprecated or not. Scheduled for deprecation seems to be a way to say show me a deprecation message, not a real state. When a symbol is deprecated, it's an error to use it unless you compile with - d. So, there is no warning about using deprecated stuff. It's an outright error. It just so happens that you can turn it off if you need to (hopefully as a quick fix). And given that deprecating a symbol introduces errors into the code of anyone who uses that symbol, informing people ahead of time gives them the opportunity to change their code before it breaks. The result is a much smoother process. OK, then we should fix the compiler (again, patch attached). -di is the solution. My patch doesn't change the defaults, but if people think is better to show deprecation errors by default, it can be trivially changed. 1. Something is scheduled for deprecation, so programmers then have the time to figure out what they're going to do to change their code, and they have time to make the changes. Nothing breaks. No one is forced to make immediate changes. This is what deprecated is for! Removing stuff breaks code, not deprecating stuff! Deprecated really is scheduled for removal, so scheduled for deprecation is scheduled for scheduled for removal, it makes no sense. Fix the compiler! 2. The symbol is then deprecated. Anyone who did not take the time to make changes as they were told that they were going to have to do then has broken code, but they have the quick fix of compiling with -d if they need to. They're still going to have to figure out what they're going to do about changing their code, and they're forced to look at the problem at least far enough to enable -d, but their code can still work with some changes to their build scripts. 3. The symbol is outright removed. Programmers have had ample time to change their code, and if they haven't, they now have to. But they were told that the symbol was going away and had to have made changes to their build scripts to even use it this long, so the developer of the library hasn't just screwed them over. The idea is to provide a smooth path for necessary changes. And just deprecating something out of the blue does _not_ do that. Unless we fix the compiler :) This doesn't really fix the problem. Deprecating something is still going to break code unless people actively try and avoid it by using -di, so
Re: dmd 1.069 and 2.054 release
Jonathan M Davis wrote: Deprecating something is still going to break code Breaking with deprecated is an entirely different kind of breakage than removing something. deprecated means simply please don't use this specific thing. You can tell it shut up I know better than you and be on your way. It's in your face enough that you can change it right there and then if you want to, but it's easy enough to shut it up too. Here's my preference list for changes: Top preference: don't change stuff. Next: use the deprecated attribute Next: versioned scheduled to be deprecated messages. I don't like being spammed every time I compile. Next: scheduled to be deprecated messages as they are now Last: removing it entirely. (this should be very, very rare especially if we want to be called stable. Nothing has pissed me off more with the last few releases than Phobos losing functionality.)
Re: dmd 1.069 and 2.054 release
On 2011-07-12 16:52:10 -0400, Leandro Lucarella l...@llucax.com.ar said: This is what deprecated is for! Removing stuff breaks code, not deprecating stuff! Deprecated really is scheduled for removal, so scheduled for deprecation is scheduled for scheduled for removal, it makes no sense. Fix the compiler! Actually it sometime makes sense that you'd schedule something to be later scheduled for removal. If there is no replacement for a certain feature, making it deprecated is just a nuisance since the compiler will complain about the problem but you have no alternative yet. Now, I think the argument for scheduling things for deprecation is just an extreme of that: deprecating things is a nuisance because it breaks code, so we'll schedule them to be deprecated later. But then we add a warning for those things scheduled for deprecation because we don't want people to use them, and scheduled for deprecation has just become a synonym for deprecated but not yet breaking your code. Fixing deprecated to not break code by default is a better option, I think. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.069 and 2.054 release
On 2011-07-12 15:09, Adam D. Ruppe wrote: Jonathan M Davis wrote: Deprecating something is still going to break code Breaking with deprecated is an entirely different kind of breakage than removing something. deprecated means simply please don't use this specific thing. You can tell it shut up I know better than you and be on your way. It's in your face enough that you can change it right there and then if you want to, but it's easy enough to shut it up too. True. But Walter has been pretty insistent that things not be deprecated without warning first, because code which compiled perfectly before doesn't anymore, even if all you have to do is change your build scripts. Now, as for the scheduled for deprecation messages, we can stop doing that. But then the documentation is going to be the only thing warning anyone, and then code is going to get broken when stuff is actually deprecated. Given the fact that you can use -d, that's not the end of the world. But it does mean that deprecation is going to tend to come out of nowhere for most people, and Walter has been very adamant about avoiding suddenly breaking people's code - even by requiring them to add -d to their build scripts. So, if most people don't want the messages, then the messages will go away. But that means that people actually need to pay attention to the changelog and documentation. Here's my preference list for changes: Top preference: don't change stuff. Next: use the deprecated attribute Next: versioned scheduled to be deprecated messages. I don't like being spammed every time I compile. Next: scheduled to be deprecated messages as they are now Last: removing it entirely. (this should be very, very rare especially if we want to be called stable. Nothing has pissed me off more with the last few releases than Phobos losing functionality.) The current plan is that _everything_ which gets deprecated will be removed. Stuff which is deprecated is not intended to stick around. Now, it should be pretty rare that deprecated stuff doesn't have a replacement. Outright removing functionality should be very rare indeed. It may happen in a few cases where the functionality just isn't generally useful, but overall, it should be rare. Deprecation is likely to fall primarily in 3 categories at this point: 1. Renaming stuff to follow Phobos' naming conventions. A lot of this was fixed with 2.054, but there's still some left to do. For the most part though, this should be a set of fixes which will be done fairly soon and then we won't have to make those kind of changes again. 2. Small redesigns of older functionality. The prime case that I can think of is that there has been talk of replacing the use of patterns in std.string with uses of std.regex.Regex. 3. Full module redesigns due to the need of serious improvement. std.datetime replacing std.date would be a prime example of this, but there are a few other modules which are supposed to be redesigned (e.g. std.xml and std.stream). The idea at least is that these sort of changes should be taking place fairly soon and that we then won't need to do any of that kind of thing anymore (or at least only very rarely). The review process should catch most of these sort of issues before they actually get into Phobos in the first place. But some code has not aged well as D and Phobos have changed, and Phobos has not always been consistent in naming, and that needs to be fixed sooner rather than later. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
Jonathan M Davis wrote: The current plan is that _everything_ which gets deprecated will be removed. What's the reason for removing things? Surely it's not disk space! Anyway, let's look at the three categories. While I hate change, there are two kinds of change: trivial and painful. Remember, D isn't a useless piece of junk dynamic language - trivial changes are easy to find and easy to change with confidence. Painful changes though, are, well, painful. 1. Renaming stuff to follow Phobos' naming conventions. These are trivial, just change it. It's like ripping off a band-aid. The compiler will tell you what broke and how to fix it (the spell checker ought to catch camelcase changes without keeping the old name). Do it fast, feel the brief pain, and move on. 2. Small redesigns of older functionality. These should be reasonably trivial fixes too, but might warrant deprecating the old on a case by case basis. If it's mindless to change though, just rip that bandage off. Just make sure that the types are different or something, while still super easy to change, so the compiler will point it out to you. 3. Full module redesigns due to the need of serious improvement This is where the pain comes in, since instead of spending 15 minutes running a mindless find/replace when the compiler tells you to, it requires gutting a lot of code and rethinking it, converting databases, etc. These should ideally aim to redesign the internals, but keep the same interface. Maybe adding to it or writing the old as an emulation layer over the new. This is preferred, since then new and old exist together. It avoids actually breaking anybody's code. If that's impossible though, this is the most likely candidate for deprecation. Unlike a name change, it isn't easy to change, so a compile error is more likely to mean reverting dmd versions than actually changing it.
Re: dmd 1.069 and 2.054 release
On 7/11/2011 8:31 AM, Andrej Mitrovic wrote: Walter, could you please add these to the changelog: Done.
Re: dmd 1.069 and 2.054 release
Thanks!
Re: dmd 1.069 and 2.054 release
On Tuesday 12 July 2011 23:38:10 Adam D. Ruppe wrote: Jonathan M Davis wrote: The current plan is that _everything_ which gets deprecated will be removed. What's the reason for removing things? Surely it's not disk space! Anyway, let's look at the three categories. While I hate change, there are two kinds of change: trivial and painful. Remember, D isn't a useless piece of junk dynamic language - trivial changes are easy to find and easy to change with confidence. Painful changes though, are, well, painful. 1. Renaming stuff to follow Phobos' naming conventions. These are trivial, just change it. It's like ripping off a band-aid. The compiler will tell you what broke and how to fix it (the spell checker ought to catch camelcase changes without keeping the old name). Do it fast, feel the brief pain, and move on. Hmm. I don't think that Walter would be very happy about that, since it does immediately break code, but as long as the name change is easily found by the spellchecker, it wouldn't be a big deal to fix. So, under at least some circumstances, that may be acceptable. Regardless, it could be grounds for making the deprecation cycle for renaming relatively short instead of around 1 year as is the current plan for deprecation in general. 2. Small redesigns of older functionality. These should be reasonably trivial fixes too, but might warrant deprecating the old on a case by case basis. If it's mindless to change though, just rip that bandage off. Just make sure that the types are different or something, while still super easy to change, so the compiler will point it out to you. 3. Full module redesigns due to the need of serious improvement This is where the pain comes in, since instead of spending 15 minutes running a mindless find/replace when the compiler tells you to, it requires gutting a lot of code and rethinking it, converting databases, etc. These should ideally aim to redesign the internals, but keep the same interface. Maybe adding to it or writing the old as an emulation layer over the new. This is preferred, since then new and old exist together. It avoids actually breaking anybody's code. If that's impossible though, this is the most likely candidate for deprecation. Unlike a name change, it isn't easy to change, so a compile error is more likely to mean reverting dmd versions than actually changing it. At this point, I expect that the module rewrites are going to generally be full-on, completely incompatible rewrites. Fixing the API is one of the major reasons for the rewrites (particularly when converting a module to being range-based as is going to occur with std.stream), so just changing the implementation isn't going to cut it. It may be that in some cases, it's essentially a rewrite of a broken implementation, but I'm not aware of any such case at the moment. These are definitely cases, however, where the full deprecation cycle is going to be used, so there should be plenty of time to fix code. Hopefully, these changes get done fairly soon, but some of them don't seem to be going anywhere yet in spite of major discussions about them (e.g. std.stream). They're also the most work to do, so while I would expect most of the #1 and #2 types of deprecations to occur fairly soon for the most part, the full module rewrites could take a while, which is unfortunate. Off the top of my head, I know that std.xml, std.stream, std.path, and std.json are going to get rewrites on some level, and std.container could get some major rewrites depending on what Andrei does with memory management in it, though what it needs primarily is new containers. Also, Andrei thinks that std.encoding is a failed experiment which needs to be redone, so that's probably going to need to be rewritten at some point. And as I understand it, all of those except for std.stream and std.encoding have someone actively working on them (though maybe Andrei has been working on std.stream too; I don't know). So, hopefully it won't be too much longer before they're done, but it could also be a while unfortunately. So, anyway, there are some module rewrites to be done, and they're likely to be pretty major for better or worse. But once those are done, with the review process vetting new modules, deprecation issues like these should be far rarer, and Phobos should be heading towards stability. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
On Monday 11 July 2011 01:11:09 Jonathan M Davis wrote: On Monday 11 July 2011 10:01:26 Jacob Carlborg wrote: On 2011-07-11 05:07, Walter Bright wrote: Continuing the trend, more people contributed to this release than any other! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.069.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.054.zip That was no short list, impressive. It definitely is impressive. Probably the longest list ever. I would point out however, that this line shouldn't be in the changelog: * Add warning about calling pure nothrow functions and ignoring the result That change was reverted after it was discovered that it caused too many problems. Oh, and this line should be removed too: * Added inference for purity and safety It's basically listed twice, since there's also this line (which is more accurate): * Automatic inference for @safe, pure, nothrow - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
On 11.07.2011 05:07, Walter Bright wrote: Continuing the trend, more people contributed to this release than any other! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.069.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.054.zip Nice release list. Added std.array.uninitializedArray and std.array.minimallyInitializedArray The online documentation of std.array doesn't seem to be updated. The above isn't present there.
Re: dmd 1.069 and 2.054 release
On Monday 11 July 2011 11:00:15 Stephan wrote: On 11.07.2011 05:07, Walter Bright wrote: Continuing the trend, more people contributed to this release than any other! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.069.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.054.zip Nice release list. Added std.array.uninitializedArray and std.array.minimallyInitializedArray The online documentation of std.array doesn't seem to be updated. The above isn't present there. Give it some time. A new release and the updating of the online documentation aren't automatically linked. Walter is the one putting up the new release, I believe that Andrei is the one who has to update the site. Walter put up the release about 6 hours ago. There's a decent chance that Andrei isn't even aware that the release has been done yet. The site will be probably be updated within the next 24 hours. But regardless, the fact remains that the site update and the release itself aren't done by the same person, so the site update is likely to be somewhat delayed. The docs in the zip file should be properly up-to-date. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
On 11.07.2011 05:07, Walter Bright wrote:
Continuing the trend, more people contributed to this release than any
other!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.069.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.054.zip
I like this one:
Added -property switch
But since phobos does not even build with it (in win32) it is pretty
much useless:
phobos\std\file.d(228): Error: not a property GetLastError:
version(Windows) this(in char[] name,
uint errno = GetLastError,
string file = __FILE__,
size_t line = __LINE__){...}
Re: dmd 1.069 and 2.054 release
On 7/11/2011 2:21 AM, Stephan wrote: But since phobos does not even build with it (in win32) it is pretty much useless: Right, that's why it was not made the default. It is there for people to experiment with.
Re: dmd 1.069 and 2.054 release
On 2011-07-11 05:49:14 -0400, Walter Bright newshou...@digitalmars.com said: On 7/11/2011 2:21 AM, Stephan wrote: But since phobos does not even build with it (in win32) it is pretty much useless: Right, that's why it was not made the default. It is there for people to experiment with. And also so that we can work on that problem. My work in progress: Phobos: https://github.com/michelf/phobos/compare/master...%40property Druntime: https://github.com/michelf/druntime/compare/master...%40property -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.069 and 2.054 release
Michel Fortin And also so that we can work on that problem. My work in progress: Very good. Bye, bearophile
Re: dmd 1.069 and 2.054 release
Jonathan M Davis wrote:
The deprecation messages are pragmas. They _can't_ give a useful
line number.
My solution is to replace the pragma with a static assert(0) so
the compiler gives an error and call trace.
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/string.d(885): Error: static
assert (0) is false
arsd/web.d(575):instantiated from here: tolower!(string)
[snip]
static assert(0) is actually my go-to replacement when things
start to go belly up, especially with templates. The list of
instantiated from here lines is a huge help when figuring it
all out.
Anyway, the pragma is meant to be informative and the assert is
an error. But, there's an easy fix for that too.
In std.string there's a softDeprec template. I think this is new
and it's private to std.string, but it's great because we can
add:
version(scheduled_for_deprecation_is_an_error)
static assert(0);
Thus:
===
private template softDeprec(string vers, string date, string oldFunc, string
newFunc)
{
version(scheduled_for_deprecation_is_an_error)
static assert(0);
enum softDeprec = Format!(Warning: As of Phobos %s, std.string.%s has been
scheduled ~
===
And then you get a full error with details upon request.
(btw I keep putting fix and such in quotes because this is a filthy
hack!)
Re: dmd 1.069 and 2.054 release
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Continuing the trend, more people contributed to this release than any other!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.069.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.054.zip
Great release! I noticed that auto ref function parameters are now implemented,
but only for template functions. Is there a reason for this limitation?
Example:
Works:
void foo()(auto ref int num) {
num++;
}
Doesn't:
void foo(auto ref int num) {
num++;
}
Re: dmd 1.069 and 2.054 release
On 7/11/11 4:11 AM, Jonathan M Davis wrote: On Monday 11 July 2011 11:00:15 Stephan wrote: On 11.07.2011 05:07, Walter Bright wrote: Continuing the trend, more people contributed to this release than any other! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.069.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.054.zip Nice release list. Added std.array.uninitializedArray and std.array.minimallyInitializedArray The online documentation of std.array doesn't seem to be updated. The above isn't present there. Give it some time. A new release and the updating of the online documentation aren't automatically linked. Walter is the one putting up the new release, I believe that Andrei is the one who has to update the site. Walter put up the release about 6 hours ago. There's a decent chance that Andrei isn't even aware that the release has been done yet. The site will be probably be updated within the next 24 hours. But regardless, the fact remains that the site update and the release itself aren't done by the same person, so the site update is likely to be somewhat delayed. The docs in the zip file should be properly up-to-date. - Jonathan M Davis I tried to rebuild the site, the 2.054 tag is not yet present in phobos. Andrei
Re: dmd 1.069 and 2.054 release
Walter, could you please add these to the changelog: http://d.puremagic.com/issues/show_bug.cgi?id=6026 http://d.puremagic.com/issues/show_bug.cgi?id=5869 http://d.puremagic.com/issues/show_bug.cgi?id=5836 http://d.puremagic.com/issues/show_bug.cgi?id=5598 http://d.puremagic.com/issues/show_bug.cgi?id=5458 http://d.puremagic.com/issues/show_bug.cgi?id=5059 http://d.puremagic.com/issues/show_bug.cgi?id=6101 These were all fixed since 2.043, but I didn't touch the changelog so they were left out. Great work everybody on this release!
Re: dmd 1.069 and 2.054 release
Also this is a worksforme fix, not a library fix and it doesn't belong in the changelog: Bugzilla 3564: Rdmd failing to link external C libraries Unless someone changed how rdmd does its argument passing.
Re: dmd 1.069 and 2.054 release
On Monday 11 July 2011 13:16:59 Adam D. Ruppe wrote:
Jonathan M Davis wrote:
The deprecation messages are pragmas. They _can't_ give a useful
line number.
My solution is to replace the pragma with a static assert(0) so
the compiler gives an error and call trace.
/home/me/d/dmd2/linux/bin32/../../src/phobos/std/string.d(885): Error:
static assert (0) is false
arsd/web.d(575):instantiated from here: tolower!(string)
[snip]
static assert(0) is actually my go-to replacement when things
start to go belly up, especially with templates. The list of
instantiated from here lines is a huge help when figuring it
all out.
Anyway, the pragma is meant to be informative and the assert is
an error. But, there's an easy fix for that too.
In std.string there's a softDeprec template. I think this is new
and it's private to std.string, but it's great because we can
add:
version(scheduled_for_deprecation_is_an_error)
static assert(0);
Thus:
===
private template softDeprec(string vers, string date, string oldFunc, string
newFunc) {
version(scheduled_for_deprecation_is_an_error)
static assert(0);
enum softDeprec = Format!(Warning: As of Phobos %s, std.string.%s has
been scheduled ~
===
And then you get a full error with details upon request.
(btw I keep putting fix and such in quotes because this is a filthy
hack!)
I created softDeprec to make it easier to make the pragma messages (and to
ensure that they're consistent). I believe that both std.string and std.file
have one, and the idea is that once they're no longer needed, they'll go away.
The version idea is an interesting one, but I'm not sure if it helps much. The
error message would give the file and line number of the pragma, not where the
function was used. And what you really need to know is where the function was
used so that you can track it down and replace it. If it gives you stack
trace though, I guess that it would help, though it would certainly be ugly.
Fortunately, in the case of something like tolower, _every_ function called
tolower is scheduled for deprecation (unless you created one in your own
code), so simply searching for it in your code will locate the ones that need
to be replaced, but still, the current situation is less than ideal.
What we really need is something like what I was discussing with Daniel - an
improvement to the deprecated attribute so that it can be used in this kind of
situation. Then it can become an actual compiler warning, though it wouldn't
exactly be a normal one, since a function which has only been scheduled for
deprecation should never cause the compilation to fail because it's used.
- Jonathan M Davis
Re: dmd 1.069 and 2.054 release
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
On 7/11/2011 7:04 AM, dsimcha wrote:
Great release! I noticed that auto ref function parameters are now
implemented,
but only for template functions. Is there a reason for this limitation?
Example:
Works:
void foo()(auto ref int num) {
num++;
}
Doesn't:
void foo(auto ref int num) {
num++;
}
auto ref changes the code generated for the function body, so it must be a
template.
So are there multiple instantiations depending on rvalue vs. not rvalue?
Re: dmd 1.069 and 2.054 release
On 7/11/2011 10:02 AM, dsimcha wrote: So are there multiple instantiations depending on rvalue vs. not rvalue? Yes, it has to be that way. It's the difference between passing T* and T.
Re: dmd 1.069 and 2.054 release
On 2011-07-11 09:34, Nick Sabalausky wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1522.1310360091.14074.digitalmars-d-annou...@puremagic.com... On Monday 11 July 2011 14:26:32 Daniel Murphy wrote: Would the following cover all the common use cases? (Phobos seems to be the biggest user of deprecated so far) deprecated(message) int a; deprecated(message, warn) int b; With deprecated(warn) messages only being displayed with warnings enabled. No. That's not quite right. If something is actually deprecated, -d is required to compile using it. Being able to have a message with it - e.g. deprecated(message) - would be very useful, because it could tell you what you're supposed to use instead (or that nothing is replacing it if that's the case). Error vs warning has nothing to do with it. Now, it could be that compiling with -w would result in the message being printed even if you compiled with -d, but that's debatable. In the case of something which is scheduled for deprecation, the code should compile regardless. A message would print if that symbol were used, but beyond that, nothing happens. That _could_ be made so that it only prints when you compile with -w, and if it's classified as a warning, then that would make sense, except that it shouldn't stop compilation even if compiling with -w, so it can't really follow what warnings normally do with -w. So, how it should function with regards to -w is debatable. Despite the confusing non-standard descriptions in --help, -w is the Treat warnings as errors setting, so it *should* stop compilation - that's the whole point of -w. The proper Turn warnings on setting is -wi, not -w. True. But when we're dealing with messages for something which is scheduled for deprecation, they're _not_ warnings. They're messages. They should never cause compilation to fail. What the best way to handle when they print or not is debatable, but they should never cause compilation to fail. So, even if they were printed because -w was used, they still shouldn't be errors. Personally, I'd probably just have them always print (and possibly include a separate flag for turning them off), but even if -w were used for enabling them, they shouldn't be errors. They're just messages. It's stuff that's actually deprecated that affects compilation. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
== Quote from Walter Bright (newshou...@digitalmars.com)'s article On 7/11/2011 10:02 AM, dsimcha wrote: So are there multiple instantiations depending on rvalue vs. not rvalue? Yes, it has to be that way. It's the difference between passing T* and T. Couldn't you just make the calling convention for auto ref functions be to always pass a T* and create a hidden temporary at the call site if passing an rvalue?
Re: dmd 1.069 and 2.054 release
On 7/11/2011 12:16 PM, dsimcha wrote: Couldn't you just make the calling convention for auto ref functions be to always pass a T* and create a hidden temporary at the call site if passing an rvalue? That can produce a lot of hidden overhead, pretty much wrecking the advantages of pass by value.
Re: dmd 1.069 and 2.054 release
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1536.1310408114.14074.digitalmars-d-annou...@puremagic.com... On 2011-07-11 09:34, Nick Sabalausky wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1522.1310360091.14074.digitalmars-d-annou...@puremagic.com... On Monday 11 July 2011 14:26:32 Daniel Murphy wrote: Would the following cover all the common use cases? (Phobos seems to be the biggest user of deprecated so far) deprecated(message) int a; deprecated(message, warn) int b; With deprecated(warn) messages only being displayed with warnings enabled. No. That's not quite right. If something is actually deprecated, -d is required to compile using it. Being able to have a message with it - e.g. deprecated(message) - would be very useful, because it could tell you what you're supposed to use instead (or that nothing is replacing it if that's the case). Error vs warning has nothing to do with it. Now, it could be that compiling with -w would result in the message being printed even if you compiled with -d, but that's debatable. In the case of something which is scheduled for deprecation, the code should compile regardless. A message would print if that symbol were used, but beyond that, nothing happens. That _could_ be made so that it only prints when you compile with -w, and if it's classified as a warning, then that would make sense, except that it shouldn't stop compilation even if compiling with -w, so it can't really follow what warnings normally do with -w. So, how it should function with regards to -w is debatable. Despite the confusing non-standard descriptions in --help, -w is the Treat warnings as errors setting, so it *should* stop compilation - that's the whole point of -w. The proper Turn warnings on setting is -wi, not -w. True. But when we're dealing with messages for something which is scheduled for deprecation, they're _not_ warnings. They're messages. They should never cause compilation to fail. What the best way to handle when they print or not is debatable, but they should never cause compilation to fail. So, even if they were printed because -w was used, they still shouldn't be errors. Personally, I'd probably just have them always print (and possibly include a separate flag for turning them off), but even if -w were used for enabling them, they shouldn't be errors. They're just messages. It's stuff that's actually deprecated that affects compilation. Not that I feel strongly about it, but just like scheduled for deprication, actual warnings are things that *are* valid code, too. Ie, they're just messages, too. The whole point of a warnings as errors setting is that some people want that extra help to ensure their code is perfectly pristine. (Although, personally, I've never seen particularly strong reason for warnings as errors settings anyway.) To be clear, if we did have some deprecated(scheduled) feature and it was non-fatal even with -w, I wouldn't personally have a huge problem with it (I never use -w anyway, just -wi). I just don't think it's so clear-cut that scheduled for deprication doesn't essentially amount to a warning.
Re: dmd 1.069 and 2.054 release
On 2011-07-11 13:09, Nick Sabalausky wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1536.1310408114.14074.digitalmars-d-annou...@puremagic.com... On 2011-07-11 09:34, Nick Sabalausky wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1522.1310360091.14074.digitalmars-d-annou...@puremagic.com. .. On Monday 11 July 2011 14:26:32 Daniel Murphy wrote: Would the following cover all the common use cases? (Phobos seems to be the biggest user of deprecated so far) deprecated(message) int a; deprecated(message, warn) int b; With deprecated(warn) messages only being displayed with warnings enabled. No. That's not quite right. If something is actually deprecated, -d is required to compile using it. Being able to have a message with it - e.g. deprecated(message) - would be very useful, because it could tell you what you're supposed to use instead (or that nothing is replacing it if that's the case). Error vs warning has nothing to do with it. Now, it could be that compiling with -w would result in the message being printed even if you compiled with -d, but that's debatable. In the case of something which is scheduled for deprecation, the code should compile regardless. A message would print if that symbol were used, but beyond that, nothing happens. That _could_ be made so that it only prints when you compile with -w, and if it's classified as a warning, then that would make sense, except that it shouldn't stop compilation even if compiling with -w, so it can't really follow what warnings normally do with -w. So, how it should function with regards to -w is debatable. Despite the confusing non-standard descriptions in --help, -w is the Treat warnings as errors setting, so it *should* stop compilation - that's the whole point of -w. The proper Turn warnings on setting is -wi, not -w. True. But when we're dealing with messages for something which is scheduled for deprecation, they're _not_ warnings. They're messages. They should never cause compilation to fail. What the best way to handle when they print or not is debatable, but they should never cause compilation to fail. So, even if they were printed because -w was used, they still shouldn't be errors. Personally, I'd probably just have them always print (and possibly include a separate flag for turning them off), but even if -w were used for enabling them, they shouldn't be errors. They're just messages. It's stuff that's actually deprecated that affects compilation. Not that I feel strongly about it, but just like scheduled for deprication, actual warnings are things that *are* valid code, too. Ie, they're just messages, too. The whole point of a warnings as errors setting is that some people want that extra help to ensure their code is perfectly pristine. (Although, personally, I've never seen particularly strong reason for warnings as errors settings anyway.) To be clear, if we did have some deprecated(scheduled) feature and it was non-fatal even with -w, I wouldn't personally have a huge problem with it (I never use -w anyway, just -wi). I just don't think it's so clear-cut that scheduled for deprication doesn't essentially amount to a warning. Hmm. The main problem with making the scheduled for deprecation messages being treated as errors with -w is that if you build with -w (as a lot of people do), it breaks your code. And the point of the message is to warn you that your code is _going_ to break and to _avoid_ causing immediate breakage. So, I don't know what the best way to handle to scheduled for deprecation messages is, but they really shouldn't cause code to not compile or force you to use a specific flag to make your code compile. Otherwise, we might as well just fully deprecate them from the get-go. The simplest way is to just always print the messages until you fix your code, but that could be annoying. So, I don't know. But scheduled for deprecation messages must not break code. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1539.1310416341.14074.digitalmars-d-annou...@puremagic.com... On 2011-07-11 13:09, Nick Sabalausky wrote: Not that I feel strongly about it, but just like scheduled for deprication, actual warnings are things that *are* valid code, too. Ie, they're just messages, too. The whole point of a warnings as errors setting is that some people want that extra help to ensure their code is perfectly pristine. (Although, personally, I've never seen particularly strong reason for warnings as errors settings anyway.) To be clear, if we did have some deprecated(scheduled) feature and it was non-fatal even with -w, I wouldn't personally have a huge problem with it (I never use -w anyway, just -wi). I just don't think it's so clear-cut that scheduled for deprication doesn't essentially amount to a warning. Hmm. The main problem with making the scheduled for deprecation messages being treated as errors with -w is that if you build with -w (as a lot of people do), it breaks your code. And the point of the message is to warn you that your code is _going_ to break and to _avoid_ causing immediate breakage. If someone doesn't want warning conditions to break their code, they should be using -wi, not -w.
Re: dmd 1.069 and 2.054 release
On 2011-07-11 13:50, Nick Sabalausky wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1539.1310416341.14074.digitalmars-d-annou...@puremagic.com... On 2011-07-11 13:09, Nick Sabalausky wrote: Not that I feel strongly about it, but just like scheduled for deprication, actual warnings are things that *are* valid code, too. Ie, they're just messages, too. The whole point of a warnings as errors setting is that some people want that extra help to ensure their code is perfectly pristine. (Although, personally, I've never seen particularly strong reason for warnings as errors settings anyway.) To be clear, if we did have some deprecated(scheduled) feature and it was non-fatal even with -w, I wouldn't personally have a huge problem with it (I never use -w anyway, just -wi). I just don't think it's so clear-cut that scheduled for deprication doesn't essentially amount to a warning. Hmm. The main problem with making the scheduled for deprecation messages being treated as errors with -w is that if you build with -w (as a lot of people do), it breaks your code. And the point of the message is to warn you that your code is _going_ to break and to _avoid_ causing immediate breakage. If someone doesn't want warning conditions to break their code, they should be using -wi, not -w. Yes. But the problem is that the scheduled for deprecation messages are not supposed to _ever_ break code. And since warnings aren't normally added very often, compiling with -w shouldn't cause your code to suddenly break. Granted, dmd is still unstable enough that such changes do occur, but once it's fully stable, it wouldn't happen very often. But anyone can schedule something for deprecation in any library, and the whole point of _scheduling_ the deprecation instead of just deprecating it is to avoid breaking code. So, it's unacceptable for scheduling something for deprecation to be an error with -w. It's informational only. Warnings are _not_ only informational. They're telling you that there's actually something wrong with your code. It's just not wrong enough to be against the language spec and therefore always be an error. Scheduling something for deprecation is indicating that the symbol in question will be deprecated in the future and that you should change it before that happens. Your code is still fine, and it should still compile. Bottom line. Marking something as scheduled for deprecation should _never_ break code no matter what flags you use to compile your code. Otherwise, there's no point to it, and we'd just be deprecating stuff immediately. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
On Mon, Jul 11, 2011 at 2:10 PM, Jonathan M Davis jmdavisp...@gmx.comwrote: On 2011-07-11 13:50, Nick Sabalausky wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1539.1310416341.14074.digitalmars-d-annou...@puremagic.com. .. On 2011-07-11 13:09, Nick Sabalausky wrote: Not that I feel strongly about it, but just like scheduled for deprication, actual warnings are things that *are* valid code, too. Ie, they're just messages, too. The whole point of a warnings as errors setting is that some people want that extra help to ensure their code is perfectly pristine. (Although, personally, I've never seen particularly strong reason for warnings as errors settings anyway.) To be clear, if we did have some deprecated(scheduled) feature and it was non-fatal even with -w, I wouldn't personally have a huge problem with it (I never use -w anyway, just -wi). I just don't think it's so clear-cut that scheduled for deprication doesn't essentially amount to a warning. Hmm. The main problem with making the scheduled for deprecation messages being treated as errors with -w is that if you build with -w (as a lot of people do), it breaks your code. And the point of the message is to warn you that your code is _going_ to break and to _avoid_ causing immediate breakage. If someone doesn't want warning conditions to break their code, they should be using -wi, not -w. Yes. But the problem is that the scheduled for deprecation messages are not supposed to _ever_ break code. And since warnings aren't normally added very often, compiling with -w shouldn't cause your code to suddenly break. Granted, dmd is still unstable enough that such changes do occur, but once it's fully stable, it wouldn't happen very often. But anyone can schedule something for deprecation in any library, and the whole point of _scheduling_ the deprecation instead of just deprecating it is to avoid breaking code. So, it's unacceptable for scheduling something for deprecation to be an error with -w. It's informational only. Warnings are _not_ only informational. They're telling you that there's actually something wrong with your code. It's just not wrong enough to be against the language spec and therefore always be an error. Scheduling something for deprecation is indicating that the symbol in question will be deprecated in the future and that you should change it before that happens. Your code is still fine, and it should still compile. Bottom line. Marking something as scheduled for deprecation should _never_ break code no matter what flags you use to compile your code. Otherwise, there's no point to it, and we'd just be deprecating stuff immediately. I would argue that when you compile with -w (and explicitly -w, not -wi), you're explicitly asking the compiler to break your code for warnings, and I believe that should include code scheduled for deprecation. By specifying -w, you're explicitly asking the compiler to check your code more strictly, and I see more aggressive deprecation as an acceptable part of that. To paraphrase your description, there's something that's about to break in your code, but it's not broken yet, so if you drop -w (or switch to -wi), you can still build it. If we're taking the approach that warnings break code when -w is used, I see scheduled deprecations falling into a very similar category. And no, this change doesn't obsolete code deprecation, it simply extends the higher standards that -w holds you to into the library space. If you don't want scheduled for deprecation to break your code, use -wi. You'll get all the same noise you got before, just without the breakage.
Re: dmd 1.069 and 2.054 release
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1542.1310418661.14074.digitalmars-d-annou...@puremagic.com... Yes. But the problem is that the scheduled for deprecation messages are not supposed to _ever_ break code. And since warnings aren't normally added very often, compiling with -w shouldn't cause your code to suddenly break. Granted, dmd is still unstable enough that such changes do occur, but once it's fully stable, it wouldn't happen very often. But anyone can schedule something for deprecation in any library, and the whole point of _scheduling_ the deprecation instead of just deprecating it is to avoid breaking code. So, it's unacceptable for scheduling something for deprecation to be an error with -w. It's informational only. Warnings are _not_ only informational. They're telling you that there's actually something wrong with your code. Something *potentially* wrong. If it actually *knew* that it was wrong it would have been an error in the first place, not a warning. And scheduled for deprecation is literally saying your code *will* be wrong, and you *do* need to address it by X deadline. That's arguably even stronger than certain warnings, because some warnings (by the very nature of warnings) are false positives. I don't really have a problem with the argument that scheduling something for deprecation shouldn't break code. But I think that's really more an argument against indiscriminate use of warnings as errors in general (which, again, isn't something I've ever felt a strong need for anyway - not that I'm advocating getting rid of it, that would probably annoy some people). In any case, the whole point of warnings as errors is that the user (for whatever possibly-questionable reason) *wants* the compiler to bail on anything that isn't guaranteed perfect (to the best of the compiler's ability). It's just not wrong enough to be against the language spec and therefore always be an error. Scheduling something for deprecation is indicating that the symbol in question will be deprecated in the future and that you should change it before that happens. Your code is still fine, and it should still compile. Bottom line. Marking something as scheduled for deprecation should _never_ break code no matter what flags you use to compile your code. Otherwise, there's no point to it, and we'd just be deprecating stuff immediately. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
On 2011-07-11 14:32, Nick Sabalausky wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1542.1310418661.14074.digitalmars-d-annou...@puremagic.com... Yes. But the problem is that the scheduled for deprecation messages are not supposed to _ever_ break code. And since warnings aren't normally added very often, compiling with -w shouldn't cause your code to suddenly break. Granted, dmd is still unstable enough that such changes do occur, but once it's fully stable, it wouldn't happen very often. But anyone can schedule something for deprecation in any library, and the whole point of _scheduling_ the deprecation instead of just deprecating it is to avoid breaking code. So, it's unacceptable for scheduling something for deprecation to be an error with -w. It's informational only. Warnings are _not_ only informational. They're telling you that there's actually something wrong with your code. Something *potentially* wrong. If it actually *knew* that it was wrong it would have been an error in the first place, not a warning. And scheduled for deprecation is literally saying your code *will* be wrong, and you *do* need to address it by X deadline. That's arguably even stronger than certain warnings, because some warnings (by the very nature of warnings) are false positives. I don't really have a problem with the argument that scheduling something for deprecation shouldn't break code. But I think that's really more an argument against indiscriminate use of warnings as errors in general (which, again, isn't something I've ever felt a strong need for anyway - not that I'm advocating getting rid of it, that would probably annoy some people). In any case, the whole point of warnings as errors is that the user (for whatever possibly-questionable reason) *wants* the compiler to bail on anything that isn't guaranteed perfect (to the best of the compiler's ability). Honestly, I would consider it bad practice to leave warnings in code. Leaving them in as you're messing with code is fine, because they're not immediately fatal, but they _are_ problems. If they weren't, then they shouldn't have been warnings in the first place. But I tend to mostly agree with Walter that something should either be an error or not. Warnings are for things which are definitely wrong but not illegal in the language. Certainly, that's how dmd treats them. I know that other compilers love to complain about other stuff that doesn't really matter but _could_ be a bug, but once you do that, people start letting warnings sit there, and _real_ problems get buried in the mess. So, obviously, we have a very different view of warnings. But regardless, it's going to cause problems if scheduling something for deprecation causes code to break. The whole point is to inform programmers that they're going to need to change their code soon and to avoid immediate code breakage. Treating scheduled for deprecation as a warning doesn't do that. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
Jonathan M Davis: If it gives you stack trace though, I guess that it would help, though it would certainly be ugly. It's not too ugly at all, since it's a template stack trace - so in a lot of cases, it isn't a very long list. Regardless though, something is better than nothing. Fortunately, in the case of something like tolower, _every_ function called Indeed, though another one was repeat() with replicate(), which isn't as simple without the compiler's help. While a proper warning is surely better than a filthy hack, if it's not coming, adding a versioned static assert is a low cost alternative we can do immediately.
Re: dmd 1.069 and 2.054 release
On 2011-07-11 17:26:15 -0400, Andrew Wiley wiley.andre...@gmail.com said: To paraphrase your description, there's something that's about to break in your code, but it's not broken yet, so if you drop -w (or switch to -wi), you can still build it. If we're taking the approach that warnings break code when -w is used, I see scheduled deprecations falling into a very similar category. To paraphrase your paraphrase, there's something that's about to break in your code, but it's not broken yet so if you add -d you can still build it... I'm simply side-stepping that discussion about implementation to illustrate that you just described the purpose of the 'deprecated' keyword. Personally, I think adding warnings or even messages for each and every scheduled-for-deprecation function is too much. Just adding it to the documentation and adding a note in the changelog should be enough. Then, one day, it'll be deprecated for real and you'll get an error unless you use -d. I think one deprecation level is enough. The scheduled for deprecation step is still useful so that early adopters can try the new way to do things and report problems. Once it's been stable and adopted by some people you can ask for mass adoption by adding a deprecation message. But nagging users when they're using something that is scheduled for deprecation is pretty much the same as having the feature deprecated immediately in my view. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.069 and 2.054 release
On 2011-07-11 16:09, Michel Fortin wrote: On 2011-07-11 17:26:15 -0400, Andrew Wiley wiley.andre...@gmail.com said: To paraphrase your description, there's something that's about to break in your code, but it's not broken yet, so if you drop -w (or switch to -wi), you can still build it. If we're taking the approach that warnings break code when -w is used, I see scheduled deprecations falling into a very similar category. To paraphrase your paraphrase, there's something that's about to break in your code, but it's not broken yet so if you add -d you can still build it... I'm simply side-stepping that discussion about implementation to illustrate that you just described the purpose of the 'deprecated' keyword. Personally, I think adding warnings or even messages for each and every scheduled-for-deprecation function is too much. Just adding it to the documentation and adding a note in the changelog should be enough. Then, one day, it'll be deprecated for real and you'll get an error unless you use -d. I think one deprecation level is enough. The scheduled for deprecation step is still useful so that early adopters can try the new way to do things and report problems. Once it's been stable and adopted by some people you can ask for mass adoption by adding a deprecation message. But nagging users when they're using something that is scheduled for deprecation is pretty much the same as having the feature deprecated immediately in my view. Well, we've been doing it with pragmas for a while (which was Andrei's idea IIRC). We just haven't been very organized about it, and I've been trying to better organize what we're doing with deprecation. And since it only works with full modules or with templated functions (since otherwise the pragma would bug everyone rather than just those using the symbol in question), it can't be used everywhere anyway. The problem with not having a message is that people aren't likely to look at the documentation unless they aren't all that familiar with the function, so people will continue to happily use the function up to the point that it's actually deprecated, and then they'll be surpised when their code breaks (since suddenly needing -d for your code to compile _is_ breaking your code). Walter in particular doesn't like the idea of people suddenly having to go and change their build scripts to use -d or immediately fix their code without any warning, which is why we don't deprecate immediately. And just putting it in the documentation really isn't much better than deprecating it immediately, because the very people who most need to see the message are the least likely to read the documentation. Now, if most people don't like the idea of messages about stuff being scheduled for deprecation being printed, then we'll likely stop having them. But it kind of defeats the purpose of scheduling it for deprecation rather than immediately deprecating it if we do that. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
On 2011-07-11 19:56:28 -0400, Jonathan M Davis jmdavisp...@gmx.com said: The problem with not having a message is that people aren't likely to look at the documentation unless they aren't all that familiar with the function, so people will continue to happily use the function up to the point that it's actually deprecated, and then they'll be surpised when their code breaks (since suddenly needing -d for your code to compile _is_ breaking your code). Walter in particular doesn't like the idea of people suddenly having to go and change their build scripts to use -d or immediately fix their code without any warning, which is why we don't deprecate immediately. Very true. I take this as an indication that the current implementation of the `deprecated` keyword is too strict by default. If it's bad that using a deprecated function breaks the code by default, then make using a deprecated function non-fatal unless the user asks for it to be fatal. To me, something scheduled for deprecation means that you know it'll be deprecated eventually, but that for now it's still okay using it. For instance, std.xml could be scheduled for deprecation, once we have a replacement we can deprecate it and nag people about using the new one. If you nag people immediately, then it's almost as good as deprecated already. That said, there's also the problem that the implementation of the scheduled for deprecation messages isn't very good. It'll work for modules, it'll work for template functions, but you don't know who imported the module or called the function. Moreover, calling a deprecated function from within a deprecated function yields no error; calling a scheduled-for-deprecation function from a scheduled-for-deprecation one or even a deprecated one will show an annoying message. Does that makes sense? Instead of working on fragile workarounds, better fix the problem, which is that `deprecated` is too strict by default. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 1.069 and 2.054 release
Jonathan M Davis, el 11 de julio a las 18:15 me escribiste: Despite the confusing non-standard descriptions in --help, -w is the Treat warnings as errors setting, so it *should* stop compilation - that's the whole point of -w. The proper Turn warnings on setting is -wi, not -w. True. But when we're dealing with messages for something which is scheduled for deprecation What's the point of scheduled for deprecation anyway? Things are deprecated, or aren't, anything else should be in the documentation. You can always use deprecated features using a compiler, so again... what's the point of scheduled for deprectation? I can't really understand that concept. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- mazzi gmail is down? Luca waiting for mail.google.com mazzi ya vendà todas mis acciones de google en los mercados asiaticos Luca se viene la ecatombe mazzi mal mazzi es como que te corten el porno en una tarde al pedo en tu casa
Re: dmd 1.069 and 2.054 release
On Tuesday 12 July 2011 01:28:11 Leandro Lucarella wrote: Jonathan M Davis, el 11 de julio a las 18:15 me escribiste: Despite the confusing non-standard descriptions in --help, -w is the Treat warnings as errors setting, so it *should* stop compilation - that's the whole point of -w. The proper Turn warnings on setting is -wi, not -w. True. But when we're dealing with messages for something which is scheduled for deprecation What's the point of scheduled for deprecation anyway? Things are deprecated, or aren't, anything else should be in the documentation. You can always use deprecated features using a compiler, so again... what's the point of scheduled for deprectation? I can't really understand that concept. The idea is to have 3 stages while deprecating something. 1. Scheduled for Deprecation. 2. Deprecated. 3. Removed. When a symbol has been deprecated, -d is required to compile any code using that symbol. So, deprecation breaks code. You either have to change your code so that it doesn't use the deprecated symbol, or you have to change your build scripts to use -d. In either case, deprecating a symbol without warning is going to cause problems for anyone maintaining code which uses that symbol. So, in the scheduled for deprecation stage, programmers are warned that a symbol will be deprecated in the near future, but the symbol hasn't been deprecated yet, so no code is broken, and no build scripts need to b changed. Programmers then have time to rework their code to no longer use the soon-to- be deprecated symbol without having their code break or having to change their build scripts. If a programmer has not done anything about the symbol before it's actually deprecated, then they will have to change their code or change their bulid scripts to use -d when the symbol is actually deprecated, but because there was the scheduled for deprecation phase, the programmer at least had fair warning about the impending code breakage and could have avoided it had they wanted to. What it comes down to is that we don't want to suddenly break anyone's code. If breaking changes need to be made, we want to provide a smooth path, giving people time to rework their code rather than suddenly breaking their code. Needing to rework your code can be annoying enough without your code suddenly breaking due to a library update. - Jonathan M Davis
Re: dmd 1.069 and 2.054 release
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1520.1310357559.14074.digitalmars-d-annou...@puremagic.com... Now, if deprecated were improved to take a message (and to allow for soft deprecation, since the messages printing here are about stuff being scheduled for deprecation rather than actually being deprecated yet), then maybe they could give a useful file and line number (at least for the functions), since then the compiler would know that a function was scheduled for deprecation and could warn you about using it. But since the best that we have for that is pragmas, that doesn't work. And actually, without that sort of feature, any function that isn't a template can't even have such a message - at best it can have a note in the documentation. Would the following cover all the common use cases? (Phobos seems to be the biggest user of deprecated so far) deprecated(message) int a; deprecated(message, warn) int b; With deprecated(warn) messages only being displayed with warnings enabled. As in, an implementation of http://d.puremagic.com/issues/show_bug.cgi?id=5481
