On Thursday, July 27, 2017 11:55:21 Ali Çehreli via Digitalmars-d-learn wrote:
> On 07/27/2017 11:47 AM, Adam D. Ruppe wrote:
> > On Thursday, 27 July 2017 at 18:35:02 UTC, FoxyBrown wrote:
> >> But the issue was about missing symbols, not anything "extra". If datatime.d is there but nothing is using it, why should it matter?
> >
> > YOU were using it with an `import std.datetime;` line. With the file still there, it sees it referenced from your code and loads the file... but since it is no longer used upstream, the .lib doesn't contain it and thus missing symbol.
>
> So, the actual problem is that given both
>
>    datetime/package.d and
>    datetime.d,
>
> the import statement prefers the file. It could produce a compilation error.
>
> If we don't want that extra check by the compiler, it would be better to keep datetime.d with a warning in it about the change. The warning could say "please remove this file". :)

I think that this should obviously be a compilation error as should any case where you've basically declared the same module twice. And really, I don't see any reason to support extracting the new zip on the old folder. We've never said that that would work, and if you think it through, it really isn't all that reasonable to expect that it would work. The list of files changes from release to release (even if removals are rare), and the layout of the directories could change. So long as the sc.ini or dmd.conf does ther right thing, then that really isn't a problem. Obviously, it's more of a pain if folks are making manual changes, but we've never promised that the directory structure of each release would be identical or that copying one compiler release on top of another would work.

- Jonathan M Davis

On Thursday, 27 July 2017 at 23:37:41 UTC, Jonathan M Davis wrote:
> On Thursday, July 27, 2017 11:55:21 Ali Çehreli via Digitalmars-d-learn wrote:
>> On 07/27/2017 11:47 AM, Adam D. Ruppe wrote:
>> > On Thursday, 27 July 2017 at 18:35:02 UTC, FoxyBrown wrote:
>> >> But the issue was about missing symbols, not anything "extra". If datatime.d is there but nothing is using it, why should it matter?
>> >
>> > YOU were using it with an `import std.datetime;` line. With the file still there, it sees it referenced from your code and loads the file... but since it is no longer used upstream, the .lib doesn't contain it and thus missing symbol.
>>
>> So, the actual problem is that given both
>>
>>    datetime/package.d and
>>    datetime.d,
>>
>> the import statement prefers the file. It could produce a compilation error.
>>
>> If we don't want that extra check by the compiler, it would be better to keep datetime.d with a warning in it about the change. The warning could say "please remove this file". :)
>
> I think that this should obviously be a compilation error as should any case where you've basically declared the same module twice. And really, I don't see any reason to support extracting the new zip on the old folder. We've never said that that would work, and if you think it through, it really isn't all that reasonable to expect that it would work. The list of files changes from release to release (even if removals are rare), and the layout of the directories could change. So long as the sc.ini or dmd.conf does ther right thing, then that really isn't a problem. Obviously, it's more of a pain if folks are making manual changes, but we've never promised that the directory structure of each release would be identical or that copying one compiler release on top of another would work.
>
> - Jonathan M Davis


You are not being very logical.

The zip file as N files in it. No matter what those files are, it should be a closed system. That is, if I insert or add(not replace) M file to the directory structure it should not break D, period!

Why? Because NO file in the zip should be referencing any file not in the zip unless it is designed to behave that way(e.g., an external lib or whatever).

If an old external program is referencing a file in dmd2 that isn't in the new zip it should err.

Why? Because suppose you have an old program that references some old file in dmd2 dir and you upgrade dmd2 by extracting the zip. The program MAY still work and use broke functionality that will go undetected but be harmful.

Why? Because dmd.exe is reference a file it shouldn't and it should know it shouldn't yet it does so anyways. It really has nothing to do with the file being in the dir but that dmd is being stupid because no one bothered to sanity checks because they are too lazy/think it's irrelevant because it doesn't effect them.

I should be able to put any extra files anywhere in the dmd2 dir structure and it should NOT break dmd.

It's like if I put a text file in some OS directory and the OS decides to use that file and crash the OS and not boot... it could happen, but it shouldn't.

In fact, all of phobos should be versioned. Each module should have a version id embedded in it. Each release all the versions are updated before shipping.

On Friday, 28 July 2017 at 00:28:52 UTC, FoxyBrown wrote:

> You are not being very logical.
>
> The zip file as N files in it. No matter what those files are, it should be a closed system. That is, if I insert or add(not replace) M file to the directory structure it should not break D, period!

That's *not* what happened here. Jonathan explained it quite well. std.datetime was refactored into a package, its contents split into new modules. When you import a module foo, dmd looks for:

1. foo.di
2. foo.d
3. foo/package.d

When it finds one, it stops looking. It's not an error for all three to exist. Your error came because it found std/datetime.d, but you linked to a library that included symbols for std/datatetime/package.d. It's not the compiler's responsibility to error in that case. It's your responsibility to properly install.

>
> Why? Because NO file in the zip should be referencing any file not in the zip unless it is designed to behave that way(e.g., an external lib or whatever).
>
> If an old external program is referencing a file in dmd2 that isn't in the new zip it should err.
>
> Why? Because suppose you have an old program that references some old file in dmd2 dir and you upgrade dmd2 by extracting the zip. The program MAY still work and use broke functionality that will go undetected but be harmful.
>
> Why? Because dmd.exe is reference a file it shouldn't and it should know it shouldn't yet it does so anyways. It really has nothing to do with the file being in the dir but that dmd is being stupid because no one bothered to sanity checks because they are too lazy/think it's irrelevant because it doesn't effect them.

That's unreasonable.

>
> I should be able to put any extra files anywhere in the dmd2 dir structure and it should NOT break dmd.

There are numerous applications out there that can break if you simply overwrite a directory with a newer version of the app. DMD is not alone with this. You should always delete the directory first. It's precisely why the compiler does so.

On Friday, 28 July 2017 at 01:10:03 UTC, Mike Parker wrote:
> On Friday, 28 July 2017 at 00:28:52 UTC, FoxyBrown wrote:
>
>> You are not being very logical.
>>
>> The zip file as N files in it. No matter what those files are, it should be a closed system. That is, if I insert or add(not replace) M file to the directory structure it should not break D, period!
>
> That's *not* what happened here. Jonathan explained it quite well. std.datetime was refactored into a package, its contents split into new modules. When you import a module foo, dmd looks for:
>
> 1. foo.di
> 2. foo.d
> 3. foo/package.d
>
> When it finds one, it stops looking. It's not an error for all three to exist. Your error came because it found std/datetime.d, but you linked to a library that included symbols for std/datatetime/package.d. It's not the compiler's responsibility to error in that case. It's your responsibility to properly install.
>

Sorry, wrong.

>>
>> Why? Because NO file in the zip should be referencing any file not in the zip unless it is designed to behave that way(e.g., an external lib or whatever).
>>
>> If an old external program is referencing a file in dmd2 that isn't in the new zip it should err.
>>
>> Why? Because suppose you have an old program that references some old file in dmd2 dir and you upgrade dmd2 by extracting the zip. The program MAY still work and use broke functionality that will go undetected but be harmful.
>>
>> Why? Because dmd.exe is reference a file it shouldn't and it should know it shouldn't yet it does so anyways. It really has nothing to do with the file being in the dir but that dmd is being stupid because no one bothered to sanity checks because they are too lazy/think it's irrelevant because it doesn't effect them.
>
> That's unreasonable.

Nope, your unreasonable expecting the end user to clean up the mess "you" leave.

>>
>> I should be able to put any extra files anywhere in the dmd2 dir structure and it should NOT break dmd.
>
> There are numerous applications out there that can break if you simply overwrite a directory with a newer version of the app. DMD is not alone with this. You should always delete the directory first. It's precisely why the compiler does so.

Nope. Virtually all apps, at least on windows, work fine if you replace their contents with new versions. Generally, only generated files such as settings and such could break the apps... but this is not the problem here.


If dmd breaks in strange and unpredictable ways IT IS DMD's fault! No exceptions, no matter what you believe, what you say, what lawyer you pay to create a law for you to make you think you are legally correct! You can make any claim you want like: "The end user should install in to a clean dir so that DMD doesn't get confused and load a module that doesn't actually have any implementation" but that's just your opinion. At the end of the day it only makes you and dmd look bad when it doesn't work because of some lame minor issue that could be easily fixed. It suggests laziness["Oh, there's a fix but I'm too lazy to add it"], arrogance["Oh, it's the end users fault, let them deal with it"], and a bit of ignorance.

In the long run, mentalities like yours are hurting D rather than helping it. Sure, you might contribute significantly to D's infrastructure, but if no one uses because there are so many "insignificant" issues then you've just wasted an significant portion of your life for absolutely nothing.

So, I'd suggest you rethink your position and the nearsighted rhetoric that you use. You can keep the mentality of kicking the can down the road and blaming the end user but it will ultimately get you no where.

On Fri, 28 Jul 2017 05:14:16 +0000, FoxyBrown wrote:
> 
> You can make any claim you want like: "The end user should install in to a clean dir so that DMD doesn't get confused and load a module that doesn't actually have any implementation" but that's just your opinion.

I have never seen extracting into the directory as a supported upgrade path for anything except the simplest of applications and a few PHP projects that supply a migration script.

> At the end of the day it only makes you and dmd look bad when it doesn't work because of some lame minor issue that could be easily fixed. It suggests laziness["Oh, there's a fix but I'm too lazy to add it"], arrogance["Oh, it's the end users fault, let them deal with it"], and a bit of ignorance.

The only solution I can think of is never splitting a module in Phobos; the alternative would be to change the way the module system works (which seems to be what you want), and that's going to break everybody's everything.

On Friday, 28 July 2017 at 05:14:16 UTC, FoxyBrown wrote:
> On Friday, 28 July 2017 at 01:10:03 UTC, Mike Parker wrote:
>> [...]
>
> Nope, your unreasonable expecting the end user to clean up the mess "you" leave.
>
>> [...]
>
> Nope. Virtually all apps, at least on windows, work fine if you replace their contents with new versions. Generally, only generated files such as settings and such could break the apps... but this is not the problem here.
>
>
> If dmd breaks in strange and unpredictable ways IT IS DMD's fault! No exceptions, no matter what you believe, what you say, what lawyer you pay to create a law for you to make you think you are legally correct! You can make any claim you want like: "The end user should install in to a clean dir so that DMD doesn't get confused and load a module that doesn't actually have any implementation" but that's just your opinion. At the end of the day it only makes you and dmd look bad when it doesn't work because of some lame minor issue that could be easily fixed. It suggests laziness["Oh, there's a fix but I'm too lazy to add it"], arrogance["Oh, it's the end users fault, let them deal with it"], and a bit of ignorance.
>
> In the long run, mentalities like yours are hurting D rather than helping it. Sure, you might contribute significantly to D's infrastructure, but if no one uses because there are so many "insignificant" issues then you've just wasted an significant portion of your life for absolutely nothing.
>
> So, I'd suggest you rethink your position and the nearsighted rhetoric that you use. You can keep the mentality of kicking the can down the road and blaming the end user but it will ultimately get you no where.

@FoxyBrown
You make the small but crucial mistake of thinking anything in D has been made for the user's sake. In fact, nothing has even been made to be used by a developer. Actually, D is a programming language for tinkerers, people with too much time and botchers.

Should any of my statements above against all expectations not be right, then something in the design of D went, more or less, very terribly wrong ...

On Friday, 28 July 2017 at 12:40:27 UTC, rjframe wrote:
> On Fri, 28 Jul 2017 05:14:16 +0000, FoxyBrown wrote:
>> 
>> You can make any claim you want like: "The end user should install in to a clean dir so that DMD doesn't get confused and load a module that doesn't actually have any implementation" but that's just your opinion.
>
> I have never seen extracting into the directory as a supported upgrade path for anything except the simplest of applications and a few PHP projects that supply a migration script.

Well, any other installer would have done the required cleanup in such a case.

On Friday, 28 July 2017 at 12:48:37 UTC, Grander wrote:
> On Friday, 28 July 2017 at 12:40:27 UTC, rjframe wrote:
>> On Fri, 28 Jul 2017 05:14:16 +0000, FoxyBrown wrote:
>>> 
>>> You can make any claim you want like: "The end user should install in to a clean dir so that DMD doesn't get confused and load a module that doesn't actually have any implementation" but that's just your opinion.
>>
>> I have never seen extracting into the directory as a supported upgrade path for anything except the simplest of applications and a few PHP projects that supply a migration script.
>
> Well, any other installer would have done the required cleanup in such a case.

The D installer completely uninstalls the previous installation. Anyone who chooses to instead manually extract the zip file should manually delete the previous installation to avoid potential problems. As Jonathan said earlier, overwriting works most of the time, but whenever anything is removed, issues like this can crop up.

On 07/28/2017 03:29 PM, Mike Parker wrote:
> 
> The D installer completely uninstalls the previous installation. Anyone who chooses to instead manually extract the zip file should manually delete the previous installation to avoid potential problems. As Jonathan said earlier, overwriting works most of the time, but whenever anything is removed, issues like this can crop up.

To me the only issue would be that (one of) the documentation pages [1] only talks about the zip file. I think it should be made clearer that the installer is the recommended / supported way, and that the zip is only meant for experts (with a recommendation to uncompress to a clean directory to avoid problems).

I know this page is not the MAIN "download" [2] page, but it's both reached from the "About" link, and as the first google hit for "dlang download windows", so it should be kept as up to date as possible.

[1]: https://dlang.org/dmd-windows.html#installation
[2]: https://dlang.org/download.html

On Friday, 28 July 2017 at 13:39:42 UTC, Arafel wrote:

>
> I know this page is not the MAIN "download" [2] page, but it's both reached from the "About" link, and as the first google hit for "dlang download windows", so it should be kept as up to date as possible.
>
> [1]: https://dlang.org/dmd-windows.html#installation

Ugh. Agreed. That page needs an update.