On 3/14/14, Michel Fortin <michel.fortin@michelf.ca> wrote:
> But before you can consider building such a tool, you'll have to convince Walter that the locations of tokens should be tracked more precisely in the frontend.

Note that if this tool is built-in to the compiler (as a feature) it
will have some big drawbacks:

1) It's only released when the compiler is released. If the feature has regressions you are tied to the DMD release schedule before you can release a fix.

2) The feature will only work with the latest compiler. In other words, if you want to update a 2.070 codebase to 2.072, you will actually need to use two compilers. The porting tool released with DMD 2.071 to port 2.070 to 2.071, and the tool released with 2.072 to port 2.071 to 2.072.

What I mean is, the parser in DMD v2.072 might not be able to parse code written for v2.070. But if the conversion tool was separate from both the compiler and its internal parser then you could make the tool work for an entire range of codebase versions, and e.g. directly port a v2.070 codebase to 2.080.

You could even back-port code. Let's say you've started using 2.070 for over a month, and you hit a major performance regression. You're short on time, you need to release your app to the public (deadlines..), but you have to wait for the fix. With the tool you could potentially be able to port the code back to 2.069 which didn't have the performance regression.

This is all theoretical so far.

Anyway if someone wants to build it in the compiler, I won't stop them.

On 2014-03-14 12:46:33 +0000, Andrej Mitrovic <andrej.mitrovich@gmail.com> said:

> 2) The feature will only work with the latest compiler. In other
> words, if you want to update a 2.070 codebase to 2.072, you will
> actually need to use two compilers. The porting tool released with DMD
> 2.071 to port 2.070 to 2.071, and the tool released with 2.072 to port
> 2.071 to 2.072.

I see what you mean. The moment the parser can't recognize the old thing, you can't migrate.

But it doesn't have to be as you say. You can keep things working in a deprecated state for longer than one version. As long as the old thing can be parsed, it can be updated.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Friday, 14 March 2014 at 12:23:01 UTC, Manu wrote:
> Because Walter is acutely allergic to the idea of a tool that modifies your
> source code. I might also have uncommitted changes, and not particularly
> feel like stashing them for the moment (less easy in other VCS's).
> I might also not want to apply all the changes, only some of them. Surely
> it's easier to merge the ones I want after visual approval, than reverting
> the ones I don't want after having gone to the effort of stashing my local
> changes to make a clean slate to work with...

It is a problem with your VCS workflow, not the imaginary tool. Having any sort of uncommitted changes other than during active editing goes against idea of DVCS.

On Friday, 14 March 2014 at 05:15:05 UTC, Manu wrote:
> So it comes up fairly regularly that people suggest that the compiler
> should have a mode where it may update user code automatically to assist
> migration to new compiler versions.
>
> I'm personally against the idea, and Walter certainly doesn't like it, but
> it occurred to me that a slight variation on this idea might be awesome.
>
> Imagine instead, an '-update' option which instead of modifying your code,
> would output a .patch file containing suggested amendments wherever it
> encountered deprecated code...
> The user can then take this patch file, inspect it visually using their
> favourite merge tool, and pick and choose the bits that they agree or
> disagree with.
>
> I would say this approach takes a dubious feature and turns it into a
> spectacular feature!
>
> Language changes are probably easy enough to handle, but what about cases
> of 'deprecated' in the library?
> It's conceivable that the deprecated keyword could take an optional
> argument to a CTFE function which would receive the expression as a string,
> and the function could transform and return an amended string which would
> also be added to the output patch file. This way, the feature could
> conceivably also offer upgrade advice for arbitrary library changes.
>
> Considering the advice in the context of a visual diff/merge window would
> be awesome if you ask me.

How difficult would it be to be able to configure the compiler for various updates directly?

What I mean is that suppose a few fixes were made and some breaking changes were made.

Could the compiler itself be configured in such a way(at least for most "breaking changes") that the user could switch the change on and off yet keep the fixes.

Example:

Suppose final by default and several bug fixes are added to version X + 1. If the user could configure the compiler so that he could simply keep the fixes but not have final by default(a sort of version x + 0.5) then he would get the benefit of the fixes without the breaking change.

I think it would probably be a maintenance nightmare and be extremely hard to implement because it is not easy to keep changes.

There are a few ways to think about it though. If the compiler kept every version it had in it's binary and the user could do -version2.063, for example, it would be easy to select the version. One can already download the version one wants so this isn't really a great solution.

But what is the differential between most versions? Just fixes and breaking changes. So is the compiler kept fixes and changes(sort of patches) in the binary that it could apply to itself and a dependency list is created it might be easier to manage.

Possibly with the proper software and methodologies it could be done. It would, at least, solve the problem. If someone didn't want some breaking change they simply could remove it from the compiler: -removechange1435 (maybe change 1435 is final by default) which reverts the compiler back to before that change BUT keeps all the fixes up to the current version that are not dependent on that change.


Another concept,

In windows, for example, you can install updates that "fix" problems. Most of the time you can roll back the changes.

Suppose one can do the same with the compiler. Instead of downloading a new version of a compiler one simply downloads the "fixes" and "changes". If a change is added that one doesn't like they just uninstall it.

This too would be difficult in some ways since compilers are generally not designed in such modular ways but it might be possible. (I guess essentially including the source code in the compiler and giving the compiler the ability to compile itself with the patches would be a way to achieve this)

"Frustrated"  wrote in message news:qkldntailmybifzsnwzn@forum.dlang.org...

> Could the compiler itself be configured in such a way(at least for most "breaking changes") that the user could switch the change on and off yet keep the fixes.

It already is, breaking changes are first introduced as warnings, then as deprecations, then as errors.  While in the first two stages you can switch them on and off.

> Possibly with the proper software and methodologies it could be done. It would, at least, solve the problem. If someone didn't want some breaking change they simply could remove it from the compiler: -removechange1435 (maybe change 1435 is final by default) which reverts the compiler back to before that change BUT keeps all the fixes up to the current version that are not dependent on that change.

Way too hard.  Not gonna happen.

> Suppose one can do the same with the compiler. Instead of downloading a new version of a compiler one simply downloads the "fixes" and "changes". If a change is added that one doesn't like they just uninstall it.

Also way too hard.  The current way works fine. 

On Fri, Mar 14, 2014 at 12:07:24PM +0000, John Colvin wrote:
> On Friday, 14 March 2014 at 11:44:21 UTC, Daniel Murphy wrote:
> >"Manu" <turkeyman@gmail.com> wrote in message news:mailman.105.1394774104.23258.digitalmars-d@puremagic.com...
> >
> >>So it comes up fairly regularly that people suggest that the compiler should have a mode where it may update user code automatically to assist migration to new compiler versions.
> >>
> >>I'm personally against the idea, and Walter certainly doesn't like it, but it occurred to me that a slight variation on this idea might be awesome.
> >>
> >>Imagine instead, an '-update' option which instead of modifying your code, would output a .patch file containing suggested amendments wherever it encountered deprecated code...  The user can then take this patch file, inspect it visually using their favourite merge tool, and pick and choose the bits that they agree or disagree with.
> >>
> >>I would say this approach takes a dubious feature and turns it into a spectacular feature!
> >
> >If you're using version control, these are practically the same thing.
> 
> Yeah, I don't understand why it matters whether it's a change or a patch. Either way, all changes become patches in VCS. Who would let an automated tool make source changes without using VC, or at least having made a manual backup?

I believe the point is to let the user *selectively* apply the diffs. A VCS doesn't help you in that area -- you either apply the entire set of changes, or nothing at all (at least within a single file).


T

-- 
Two wrongs don't make a right; but three rights do make a left...

On Friday, 14 March 2014 at 14:39:37 UTC, H. S. Teoh wrote:
> I believe the point is to let the user *selectively* apply the diffs.
> A VCS doesn't help you in that area -- you either apply the entire set
> of changes, or nothing at all (at least within a single file).
>
>
> T

This is not true. git allows you to add separate changes from a single file into different change sets (git add -i)

On 2014-03-14 13:09, Michel Fortin wrote:

> But before you can consider building such a tool, you'll have to
> convince Walter that the locations of tokens should be tracked more
> precisely in the frontend. Currently the frontend remembers only the
> file and line of any token it finds. You can't implement a refactoring
> with that. Last time that came in in a discussion (about error messages
> showing the exact location of the error), the idea was shut down on the
> ground that storing better location info would slow down the compiler.

This as already been implemented [1]. DMD (git master) now supports the -vcolumns flag to display error message with information about the column.

[1] https://github.com/D-Programming-Language/dmd/pull/3077

-- 
/Jacob Carlborg

Le 14/03/2014 08:10, Rikki Cattermole a écrit :
> On Friday, 14 March 2014 at 05:15:05 UTC, Manu wrote:
>> So it comes up fairly regularly that people suggest that the compiler
>> should have a mode where it may update user code automatically to assist
>> migration to new compiler versions.
>>
>> I'm personally against the idea, and Walter certainly doesn't like it,
>> but
>> it occurred to me that a slight variation on this idea might be awesome.
>>
>> Imagine instead, an '-update' option which instead of modifying your
>> code,
>> would output a .patch file containing suggested amendments wherever it
>> encountered deprecated code...
>> The user can then take this patch file, inspect it visually using their
>> favourite merge tool, and pick and choose the bits that they agree or
>> disagree with.
>>
>> I would say this approach takes a dubious feature and turns it into a
>> spectacular feature!
>>
>> Language changes are probably easy enough to handle, but what about cases
>> of 'deprecated' in the library?
>> It's conceivable that the deprecated keyword could take an optional
>> argument to a CTFE function which would receive the expression as a
>> string,
>> and the function could transform and return an amended string which would
>> also be added to the output patch file. This way, the feature could
>> conceivably also offer upgrade advice for arbitrary library changes.
>>
>> Considering the advice in the context of a visual diff/merge window would
>> be awesome if you ask me.
>
> Sounds like a cool idea. But not as part of the compiler. Its more of a
> use case for compiler as a library ;)
IMO these kind of tool is same as code beautifuler or refactoring helpers (eclipse give you some tips to fix your errors on imports,...)

On 2014-03-14 18:22:19 +0000, Jacob Carlborg <doob@me.com> said:

> On 2014-03-14 13:09, Michel Fortin wrote:
> 
>> But before you can consider building such a tool, you'll have to
>> convince Walter that the locations of tokens should be tracked more
>> precisely in the frontend. Currently the frontend remembers only the
>> file and line of any token it finds. You can't implement a refactoring
>> with that. Last time that came in in a discussion (about error messages
>> showing the exact location of the error), the idea was shut down on the
>> ground that storing better location info would slow down the compiler.
> 
> This as already been implemented [1]. DMD (git master) now supports the -vcolumns flag to display error message with information about the column.
> 
> [1] https://github.com/D-Programming-Language/dmd/pull/3077

Oh, I missed that. Great!

I'm still not entirely sure it retains enough information to perform a refactoring, but it's a start.

-- s
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca