On Friday, 28 July 2017 at 05:14:16 UTC, FoxyBrown wrote:
> 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.

But it's not being installed, it's being manually extracted, meaning you can't even have cleanup scripts.

Compare keeping an installation of audio files in mp3 (bird calls), and then getting an upgrade where they are in ogg in a new neat directory hierarchy. There's an installer that properly and cleanly removes the old mp3s before extracting the new files, as well as a bonus archive if you want to unzip it yourself. Manually extracting it onto the old directory puts the oggs next to the mp3s, leaving it with twice the number of original audio files. Meanwhile, the official upgrade path (installer) properly removes the stale ones. You can't reasonably expect your audio player to not list them all there.

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.

One of the reasons to extract a zip instead of using an installer is that you want to replace only certain files. There's nothing reasonable about this argument.

On Friday, 28 July 2017 at 13:55:33 UTC, Anonymouse wrote:
> On Friday, 28 July 2017 at 05:14:16 UTC, FoxyBrown wrote:
>> 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.
>
> But it's not being installed, it's being manually extracted, meaning you can't even have cleanup scripts.
>
> Compare keeping an installation of audio files in mp3 (bird calls), and then getting an upgrade where they are in ogg in a new neat directory hierarchy. There's an installer that properly and cleanly removes the old mp3s before extracting the new files, as well as a bonus archive if you want to unzip it yourself. Manually extracting it onto the old directory puts the oggs next to the mp3s, leaving it with twice the number of original audio files. Meanwhile, the official upgrade path (installer) properly removes the stale ones. You can't reasonably expect your audio player to not list them all there.

So, the program, if it is updated shouldn't use the mp3's then. Why the hell is the program that you say was upgraded to use the ogg still searching and using mp3's? You are trying to make up reasons why it shouldn't work... at least come up with valid reasons.

Yes, there might be "twice" the files and one might waste space BUT that is different from the application crapping out and the end user spending hours trying to figure out what is wrong. TOTALLY different issues.

We are not talking about "listing" files or anything like that, we are talking about the app not working because of "stale" files because it decided to use them, even though it should have been told not too because the whole point of the upgrade was to migrate from one set of files to another... and yet some idiot who programmed the app still had the app use the old files... it's the idiots fault... not the end user. What if the end user does a partial restore from some system issues and those mp4's were restored? Then what? The end users fault when he opens up the app and it crashes?

Some programmers need to start taking responsibility for the crap they spew out. What a programmer is creating is effecting many many end users. It is up to the programmer to do the correct job to prevent a large factor of end user waste. That is what the programmer gets paid for.

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.
>
>>
>> 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.

So, that proves nothing. You are simply ok with wasting the end users time... you should grow up and take responsibility for what you release.

Your logic is not sound mathematically unless you think it's ok to waste end users time:

There is 1 programmer, you and N end users of your app. Ok? got that? Very simple mathematics.

Now, suppose you decide it is not worth your 10 mins to fix a problem or add sanity checks or robustness to your program and it effects 1% of the users of your app(we'll use a low percentage just to give you a fighting chance, which you don't deserve but we'll allow it).

Now, suppose that wastes only 10 mins of the end users time(again, we'll low ball the number because usually it is much greater since the end user is not familiar with out the program works like the creator of that program is).

This means that 10*0.01*N minutes are wasted overall of the human race because you didn't want to spend 10 minutes to fix a program.

If 10000 users use your app, that is 1000 minutes wasted ~= 17 hours.

And that is a low estimate. So, just because you want to save 10 minutes you've wasted 17 hours of human life... what an investment!

That is your mentality. You should run for US President! Your mentality fits right in with how the US handles it's money.

Remember how much of your own life has been wasted on fixing other peoples mess and maybe you might realize how bad it is... probably not though, maybe when your on your death bed you might get a spark of sanity... but then it will be too late and pointless.

On Friday, 28 July 2017 at 21:23:22 UTC, FoxyBrown wrote:
> So, the program, if it is updated shouldn't use the mp3's then. Why the hell is the program that you say was upgraded to use the ogg still searching and using mp3's? You are trying to make up reasons why it shouldn't work... at least come up with valid reasons.

I'm sorry if I'm not expressing it in a way that agrees with you but you're looking at the wrong side of the example. You're pasting one set of files onto another and expect the software to somehow know to ignore some of them.

On Friday, 28 July 2017 at 21:35:01 UTC, Anonymouse wrote:
> On Friday, 28 July 2017 at 21:23:22 UTC, FoxyBrown wrote:
>> So, the program, if it is updated shouldn't use the mp3's then. Why the hell is the program that you say was upgraded to use the ogg still searching and using mp3's? You are trying to make up reasons why it shouldn't work... at least come up with valid reasons.
>
> I'm sorry if I'm not expressing it in a way that agrees with you but you're looking at the wrong side of the example. You're pasting one set of files onto another and expect the software to somehow know to ignore some of them.

YES! EXACTLY! I AM EXPECTING THE SOFTWARE, WHICH IS WHAT THE PROGRAMMER CREATED AND HANDLES THE FILES TO ACTUALLY KNOW WHAT THE HELL IT IS DOING!

I'm sorry if that is too complex to understand.

If the software has some build in design that makes it use arbitrary files in a specific way like it does with std.datetime, then it should have sanity checks.

After all, who the hell knows more about dmd using std.datetime and how it uses it and such, the end user or the programmer of dmd?

You are expecting the end user, who generally knows very little to do the dirty work instead of having the programmer who is suppose to know what the fuck is going on to add sanity checks, useful error messages, etc.

Ali suggested a very reasonable solution that would have solved this problem and you guys are against it and offer no solution to the issue.

It all boils down to laziness. Too lazy to spend the time to add code that makes dmd more robust. Simple as that.

It's not that it can't be done, like you bone-heads are claiming, but that you simply don't want to do it.

Another very simple solution:

Before the zip file is generated, a listing of all the files in the dmd installation that are used(which should be all of them) is taken. This file then is parsed by dmd and only those files in the dmd dir that are in the list are used. This would also have avoided the issue and future issues. Any stale files in the dir would simply be ignored.

But, again, too much work. Keep making the end users deal with these problems instead of doing your due diligence. That we, we have something to waste our time with in these forums instead of real problems.

On Friday, 28 July 2017 at 22:32:27 UTC, FoxyBrown wrote:
> On Friday, 28 July 2017 at 21:35:01 UTC, Anonymouse wrote:
>> [...]
>
> YES! EXACTLY! I AM EXPECTING THE SOFTWARE, WHICH IS WHAT THE PROGRAMMER CREATED AND HANDLES THE FILES TO ACTUALLY KNOW WHAT THE HELL IT IS DOING!
>
> [...]


The software actually knows what it does: loading/including all files from its library directory.

If you place your own pictures into a text processing program's clipart directory, you shouldn't complain about finding them listed as cliparts either.


> I'm sorry if that is too complex to understand.
>
> If the software has some build in design that makes it use arbitrary files in a specific way like it does with std.datetime, then it should have sanity checks.
>
> [...]


Seems like the DMD zip should contain a notice like this: "Extract into an empty directory."

On Friday, 28 July 2017 at 22:32:27 UTC, FoxyBrown wrote:
> On Friday, 28 July 2017 at 21:35:01 UTC, Anonymouse wrote:
>> On Friday, 28 July 2017 at 21:23:22 UTC, FoxyBrown wrote:
>>> [...]
>>
>> I'm sorry if I'm not expressing it in a way that agrees with you but you're looking at the wrong side of the example. You're pasting one set of files onto another and expect the software to somehow know to ignore some of them.
>
> YES! EXACTLY! I AM EXPECTING THE SOFTWARE, WHICH IS WHAT THE PROGRAMMER CREATED AND HANDLES THE FILES TO ACTUALLY KNOW WHAT THE HELL IT IS DOING!
>
> I'm sorry if that is too complex to understand.
>
> If the software has some build in design that makes it use arbitrary files in a specific way like it does with std.datetime, then it should have sanity checks.
>
> After all, who the hell knows more about dmd using std.datetime and how it uses it and such, the end user or the programmer of dmd?
>
> You are expecting the end user, who generally knows very little to do the dirty work instead of having the programmer who is suppose to know what the fuck is going on to add sanity checks, useful error messages, etc.
>
> Ali suggested a very reasonable solution that would have solved this problem and you guys are against it and offer no solution to the issue.
>
> It all boils down to laziness. Too lazy to spend the time to add code that makes dmd more robust. Simple as that.
>
> It's not that it can't be done, like you bone-heads are claiming, but that you simply don't want to do it.
>
> Another very simple solution:
>
> Before the zip file is generated, a listing of all the files in the dmd installation that are used(which should be all of them) is taken. This file then is parsed by dmd and only those files in the dmd dir that are in the list are used. This would also have avoided the issue and future issues. Any stale files in the dir would simply be ignored.
>
> But, again, too much work. Keep making the end users deal with these problems instead of doing your due diligence. That we, we have something to waste our time with in these forums instead of real problems.

What you are suggesting is blatantly idiotic.  No software ever made supports simply installing on top of an old installation from a compressed zip or tar file.  If you need hand-holding, the installer will wipe the old install before unpacking the new install for you.  The zip file is for people who know what they are doing, such as not unpacking on top of the old install.  You should just use the installer from now on, not the zip file, if you can't be bothered to remove the old install first.

On Saturday, 29 July 2017 at 19:17:08 UTC, Joakim wrote:
> On Friday, 28 July 2017 at 22:32:27 UTC, FoxyBrown wrote:
>> [...]
>
> What you are suggesting is blatantly idiotic.  No software ever made supports simply installing on top of an old installation from a compressed zip or tar file.  If you need hand-holding, the installer will wipe the old install before unpacking the new install for you.  The zip file is for people who know what they are doing, such as not unpacking on top of the old install.  You should just use the installer from now on, not the zip file, if you can't be bothered to remove the old install first.

bullshit. Are you a moron? You really think your absolute "No software ever" is logical?

I can name many off the top of my head. Have you ever heard the fucking word "portable"? I guess not, go look it up.

Please take your jack ass arrogant self somewhere else.

Also, equating dmd to an audio program or a clip art program that is designed to load any and all files in it's install dir is moronic too.

On Saturday, 29 July 2017 at 19:26:03 UTC, FoxyBrown wrote:
> Also, equating dmd to an audio program or a clip art program that is designed to load any and all files in it's install dir is moronic too.

I like to add files to the dmd install directory to expand its "just works" library.

I was bitten by this change too. I'm of the opinion that splitting std.datetime was a waste of time and also that the package.d feature is misdesigned. It should ALSO allow any other file to be passed with the module declaration that matches... you know, like every other module in the language. Why it got this bizarre special requirement is beyond me.

If it did, then we could easily enough just leave the old file. But no, it requires the new one, but then prolly on efficiency grounds, doesn't check it first meaning the old one can silently conflict. Ugh.

But the fix here is to fix the bizarre package.d design. Don't break the zip for cases like mine where adding files is a key feature of it.