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;}() );
We are looking for a D1 programmer in Berlin, full time position
Good day, our company is looking for a D1 programmer for a full time position at our office in Berlin. See the link for more details http://www.sociomantic.com/careers/software-developer/ Regards, --Mathias -- Mathias Baumann Research and Development sociomantic labs GmbH Münzstraße 19 10178 BERLIN DEUTSCHLAND http://www.sociomantic.com Fon: +49 (0)30 5015 4701 Fax: +49 (0)30 2403 6715 Skype: Mathias Baumann (m4renz) --- sociomantic labs GmbH, Location: Berlin Commercial Register - AG Charlottenburg: HRB 121302 B VAT No. - USt-ID: DE 266262100 Managing Directors: Thomas Nicolai, Thomas Brandhoff
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
