www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - It makes me sick!

reply FoxyBrown <Foxy Brown.IPT> writes:
Knowing that every time I upgrade to the latest "official" D 
compiler I run in to trouble:



Win32\Debug DMD\test.obj(test)
  Error 42: Symbol Undefined 
_D3std8datetime7SysTime8toStringMxFNbNfZAya (const(nothrow  safe 
immutable(char)[] function()) std.datetime.SysTime.toString)
Win32\Debug DMD\test.obj(test)
  Error 42: Symbol Undefined 
_D3std8datetime7SysTime6toHashMxFNaNbNiNfZk (const(pure nothrow 
 nogc  safe uint function()) std.datetime.SysTime.toHash)
Win32\Debug DMD\test.obj(test)
  Error 42: Symbol Undefined 
_D3std8datetime7SysTime8opEqualsMxFNaNbNfKxS3std8datetime7SysTimeZb (const(pure
nothrow  safe bool function(ref const(std.datetime.SysTime)))
std.datetime.SysTime.opEquals)
Win32\Debug DMD\test.obj(test)
  Error 42: Symbol Undefined 
_D3std8datetime7SysTime8__xopCmpFKxS3std8datetime7SysTimeKxS3st
8datetime7SysTimeZi (int std.datetime.SysTime.__xopCmp(ref
const(std.datetime.SysTime), ref const(std.datetime.SysTime)))
Win32\Debug DMD\test.obj(test)
  Error 42: Symbol Undefined _D3gtk3All12__ModuleInfoZ 
(gtk.All.__ModuleInfo)
\GtkD\x86\gtkd.lib(AboutDialog)
  Error 42: Symbol Undefined 
_D3std6format64__T14formatIntegralTS3std5array17__T8AppenderTAyaZ8AppenderTmTaZ14formatIntegralFNaNbNfS3std5array17__T8AppenderTAyaZ8AppenderxmKxS3std6format18__T10FormatSpe
TaZ10FormatSpeckmZv (pure nothrow  safe void
std.format.formatIntegral!(std.array.Appender!(immutable(char)[]).Appender,
ulong, char).formatIntegral(std.array.Appender!(immutable(char)[]).Appender,
const(ulong), ref const(std.format.FormatSpec!(char).FormatSpec), uint, ulong))
\GtkD\x86\gtkd.lib(AboutDialog)
  Error 42: Symbol Undefined _D3std5stdio6stderrS3std5stdio4File 
(std.stdio.File std.stdio.stderr)
\GtkD\x86\gtkd.lib(Implement)
  Error 42: Symbol Undefined 
_D3std6format64__T14formatUnsignedTS3std5array17__T8AppenderTAyaZ8AppenderTmTaZ14formatUnsignedFNaNbNfS3std5array17__T8AppenderTAyaZ8AppendermKxS3std6format18__T10FormatSpe
TaZ10FormatSpeckbZv (pure nothrow  safe void
std.format.formatUnsigned!(std.array.Appender!(immutable(char)[]).Appender,
ulong, char).formatUnsigned(std.array.Appender!(immutable(char)[]).Appender,
ulong, ref const(std.format.FormatSpec!(char).FormatSpec), uint, bool))
Error: linker exited with status 8
Building Win32\Debug DMD\test.exe failed!


I recompiled gtkD with the new compiler, same result.  My code 
was working before the upgrade just fine and I did not change 
anything.
Jul 26 2017
next sibling parent FoxyBrown <Foxy Brown.IPT> writes:
And yes, I'm using the correct phobos(the one that came with 
dmd2).
Jul 26 2017
prev sibling next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 07/26/2017 08:34 PM, FoxyBrown wrote:

 Knowing that every time I upgrade to the latest "official" D compiler I
 run in to trouble:



 Win32\Debug DMD\test.obj(test)
  Error 42: Symbol Undefined _D3std8datetime7SysTime8toStringMxFNbNfZAya
 (const(nothrow  safe immutable(char)[] function())
 std.datetime.SysTime.toString)
 Win32\Debug DMD\test.obj(test)


Somebody else had the same problem which they solved by removing "entire 
dmd":

   http://forum.dlang.org/thread/ejybuwermnentslcyajs forum.dlang.org

Ali
Jul 26 2017
parent reply FoxyBrown <Foxy Brown.IPT> writes:
On Thursday, 27 July 2017 at 03:41:06 UTC, Ali Çehreli wrote:

 On 07/26/2017 08:34 PM, FoxyBrown wrote:

 Knowing that every time I upgrade to the latest "official" D 
 compiler I
 run in to trouble:



 Win32\Debug DMD\test.obj(test)
  Error 42: Symbol Undefined 
 _D3std8datetime7SysTime8toStringMxFNbNfZAya
 (const(nothrow  safe immutable(char)[] function())
 std.datetime.SysTime.toString)
 Win32\Debug DMD\test.obj(test)


 Somebody else had the same problem which they solved by 
 removing "entire dmd":

   
 http://forum.dlang.org/thread/ejybuwermnentslcyajs forum.dlang.org

 Ali


Thanks, that was it. So I guess I have to delete the original 
dmd2 dir before I install each time... didn't use to have to do 
that.
Jul 26 2017
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 07/26/2017 09:20 PM, FoxyBrown wrote:


 Somebody else had the same problem which they solved by removing
 "entire dmd":

   http://forum.dlang.org/thread/ejybuwermnentslcyajs forum.dlang.org

 Ali


 Thanks, that was it. So I guess I have to delete the original dmd2 dir
 before I install each time... didn't use to have to do that.


Normally, it shouldn't be necessary. The splitting of the datetime 
package[1] had this effect but I'm not sure why the installation process 
can't take care of it.

Ali

[1] http://dlang.org/changelog/2.075.0.html#split-std-datetime
Jul 26 2017
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via Digitalmars-d-learn 
wrote:

 On 07/26/2017 09:20 PM, FoxyBrown wrote:
  >> Somebody else had the same problem which they solved by removing
  >>
  >> "entire dmd":
  >>   http://forum.dlang.org/thread/ejybuwermnentslcyajs forum.dlang.org
  >>
  >> Ali
  >
  > Thanks, that was it. So I guess I have to delete the original dmd2 dir
  > before I install each time... didn't use to have to do that.

 Normally, it shouldn't be necessary. The splitting of the datetime
 package[1] had this effect but I'm not sure why the installation process
 can't take care of it.

 Ali

 [1] http://dlang.org/changelog/2.075.0.html#split-std-datetime


It _should_ take care of it. The fact that multiple people have run into
this problem and that the solution was to remove dmd and then reinstall it
implies that there's a bug in the installer.

- Jonathan M Davis
Jul 27 2017
parent reply FoxyBrown <Foxy Brown.IPT> writes:
On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis wrote:

 On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via 
 Digitalmars-d-learn wrote:

 On 07/26/2017 09:20 PM, FoxyBrown wrote:
  >> Somebody else had the same problem which they solved by 
 removing
  >>
  >> "entire dmd":
  >>   
 http://forum.dlang.org/thread/ejybuwermnentslcyajs forum.dlang.org
  >>
  >> Ali
  >
  > Thanks, that was it. So I guess I have to delete the 
 original dmd2 dir
  > before I install each time... didn't use to have to do that.

 Normally, it shouldn't be necessary. The splitting of the 
 datetime package[1] had this effect but I'm not sure why the 
 installation process can't take care of it.

 Ali

 [1] http://dlang.org/changelog/2.075.0.html#split-std-datetime


 It _should_ take care of it. The fact that multiple people have 
 run into this problem and that the solution was to remove dmd 
 and then reinstall it implies that there's a bug in the 
 installer.

 - Jonathan M Davis


I do not use the installer, I use the zip file. I assumed that 
everything would be overwritten and any old stuff would simply go 
unused.. but it seems it doesn't. If the other person used the 
installer then it is a problem with dmd itself not designed 
properly and using files that it shouldn't. I simply unzip the 
zip file in to the dmd2 dir and replace sc.ini... that has been 
my MO for since I've been trying out dmd2 and only recently has 
it had a problem.
Jul 27 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/27/17 1:58 PM, FoxyBrown wrote:

 On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis wrote:

 On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via 
 Digitalmars-d-learn wrote:

 On 07/26/2017 09:20 PM, FoxyBrown wrote:
  >> Somebody else had the same problem which they solved by removing
  >>
  >> "entire dmd":
  >> http://forum.dlang.org/thread/ejybuwermnentslcyajs forum.dlang.org
  >>
  >> Ali
  >
  > Thanks, that was it. So I guess I have to delete the original dmd2 
 dir
  > before I install each time... didn't use to have to do that.

 Normally, it shouldn't be necessary. The splitting of the datetime 
 package[1] had this effect but I'm not sure why the installation 
 process can't take care of it.

 Ali

 [1] http://dlang.org/changelog/2.075.0.html#split-std-datetime


 It _should_ take care of it. The fact that multiple people have run 
 into this problem and that the solution was to remove dmd and then 
 reinstall it implies that there's a bug in the installer.

 - Jonathan M Davis


 
 I do not use the installer, I use the zip file. I assumed that 
 everything would be overwritten and any old stuff would simply go 
 unused.. but it seems it doesn't. If the other person used the installer 
 then it is a problem with dmd itself not designed properly and using 
 files that it shouldn't. I simply unzip the zip file in to the dmd2 dir 
 and replace sc.ini... that has been my MO for since I've been trying out 
 dmd2 and only recently has it had a problem.


If you extracted the zip file over the original install, then it didn't 
get rid of std/datetime.d (as extracting a zipfile doesn't remove items 
that exist on the current filesystem but aren't in the zipfile). So I 
can totally see this happening.

I don't know of a good way to solve this except to tell people, don't do 
that.

-Steve
Jul 27 2017
next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Thursday, July 27, 2017 14:14:52 Steven Schveighoffer via Digitalmars-d-
learn wrote:

 On 7/27/17 1:58 PM, FoxyBrown wrote:

 I do not use the installer, I use the zip file. I assumed that
 everything would be overwritten and any old stuff would simply go
 unused.. but it seems it doesn't. If the other person used the installer
 then it is a problem with dmd itself not designed properly and using
 files that it shouldn't. I simply unzip the zip file in to the dmd2 dir
 and replace sc.ini... that has been my MO for since I've been trying out
 dmd2 and only recently has it had a problem.


 If you extracted the zip file over the original install, then it didn't
 get rid of std/datetime.d (as extracting a zipfile doesn't remove items
 that exist on the current filesystem but aren't in the zipfile). So I
 can totally see this happening.

 I don't know of a good way to solve this except to tell people, don't do
 that.


Yeah, there are plenty of releases where nothing gets removed, but files do
get removed from time to time, so simply extracting the zip on top of the
old directory will cause problems at least occasionally. Also, in the case
of Linux, an .so is generated with a specific version number in it, so every
release has different files. I don't think that Windows currently has
anything like that, but it could in the future. So, if you want to use the
zip, then you should always remove the old version and not simply overwrite
it.

- Jonathan M Davis
Jul 27 2017
prev sibling parent reply FoxyBrown <Foxy Brown.IPT> writes:
On Thursday, 27 July 2017 at 18:14:52 UTC, Steven Schveighoffer 
wrote:

 On 7/27/17 1:58 PM, FoxyBrown wrote:

 On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis 
 wrote:

 On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via 
 Digitalmars-d-learn wrote:

 On 07/26/2017 09:20 PM, FoxyBrown wrote:
  >> Somebody else had the same problem which they solved by 
 removing
  >>
  >> "entire dmd":
  >> 
 http://forum.dlang.org/thread/ejybuwermnentslcyajs forum.dlang.org
  >>
  >> Ali
  >
  > Thanks, that was it. So I guess I have to delete the 
 original dmd2 dir
  > before I install each time... didn't use to have to do 
 that.

 Normally, it shouldn't be necessary. The splitting of the 
 datetime package[1] had this effect but I'm not sure why the 
 installation process can't take care of it.

 Ali

 [1] 
 http://dlang.org/changelog/2.075.0.html#split-std-datetime


 It _should_ take care of it. The fact that multiple people 
 have run into this problem and that the solution was to 
 remove dmd and then reinstall it implies that there's a bug 
 in the installer.

 - Jonathan M Davis


 
 I do not use the installer, I use the zip file. I assumed that 
 everything would be overwritten and any old stuff would simply 
 go unused.. but it seems it doesn't. If the other person used 
 the installer then it is a problem with dmd itself not 
 designed properly and using files that it shouldn't. I simply 
 unzip the zip file in to the dmd2 dir and replace sc.ini... 
 that has been my MO for since I've been trying out dmd2 and 
 only recently has it had a problem.


 If you extracted the zip file over the original install, then 
 it didn't get rid of std/datetime.d (as extracting a zipfile 
 doesn't remove items that exist on the current filesystem but 
 aren't in the zipfile). So I can totally see this happening.

 I don't know of a good way to solve this except to tell people, 
 don't do that.

 -Steve


But the issue was about missing symbols, not anything "extra". If 
datatime.d is there but nothing is using it, why should it 
matter? Why would it have any effect on the compilation process 
and create errors with D telling me something is being used that 
isn't?

dmd shouldn't be picking up extraneous and non-connected files 
just for the fun of it.

Basically, if no "references" escape out side of the D ecosystem, 
then there shouldn't be a problem.
Jul 27 2017
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jul 27 2017
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 27 July 2017 at 18:47:57 UTC, Adam D. Ruppe wrote:

 YOU were using it with an `import std.datetime;` line


Of course, it is also possible that import was through a 
dependency of something you used, possibly including the standard 
library.
Jul 27 2017
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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". :)

Ali
Jul 27 2017
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
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
Jul 27 2017
parent reply FoxyBrown <Foxy Brown.IPT> writes:
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.
Jul 27 2017
parent reply Mike Parker <aldacron gmail.com> writes:
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.
Jul 27 2017
next sibling parent reply FoxyBrown <Foxy Brown.IPT> writes:
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.
Jul 27 2017
next sibling parent reply rjframe <dlang ryanjframe.com> writes:
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.
Jul 28 2017
parent reply Grander <grander grander.grander> writes:
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.
Jul 28 2017
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
Jul 28 2017
parent reply Arafel <er.krali gmail.com> writes:
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
Jul 28 2017
parent Mike Parker <aldacron gmail.com> writes:
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.
Jul 28 2017
prev sibling parent bachmeier <no spam.net> writes:
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.
Jul 28 2017
prev sibling next sibling parent Grander <grander grander.grander> writes:
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 ...
Jul 28 2017
prev sibling parent reply Anonymouse <asdf asdf.net> writes:
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.
Jul 28 2017
parent reply FoxyBrown <Foxy Brown.IPT> writes:
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.
Jul 28 2017
parent reply Anonymouse <asdf asdf.net> writes:
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.
Jul 28 2017
parent reply FoxyBrown <Foxy Brown.IPT> writes:
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.
Jul 28 2017
next sibling parent Grander <grander grander.grander> writes:
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."
Jul 29 2017
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
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.
Jul 29 2017
parent reply FoxyBrown <Foxy Brown.IPT> writes:
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.
Jul 29 2017
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jul 29 2017
next sibling parent FoxyBrown <Foxy Brown.IPT> writes:
On Saturday, 29 July 2017 at 19:51:30 UTC, Adam D. Ruppe wrote:

 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.


I don't mind the issue as long as it is stated clearly what must 
be done(e.g., simply add "requires cleaned installed directory"). 
What pisses me off more more than anything is the asinine people 
defending the behavior as if it is acceptable and that it is the 
users fault to know that the behavior.

Many programs I use can be upgraded without issue by copying over 
the data files. Dmd did not have this program until recently and 
so, because it isn't stated it is a problem, how the hell is the 
user suppose to know that? Specially when it worked correct the 
first time, the second time, the third time, etc.
Jul 29 2017
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/29/17 3:51 PM, Adam D. Ruppe wrote:


 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.


How should it be fixed?

-Steve
Aug 01 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 1 August 2017 at 14:20:00 UTC, Steven Schveighoffer 
wrote:

 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.


 How should it be fixed?


Well, my preference would be to treat it just like any other 
module: the compiler has a search path, but if it opens a file, 
the module name is definitive.

So we can keep the search path: `datetime.di`, then `datetime.d`, 
then `datetime/package.d`, and any one of them, as long as it has 
`module std.datetime;` at the top, can count equally as the 
package.d.

BTW I kinda want to put `datetime/package.d` first on the search 
path, but I fear that'd hurt the speed of the normal case (every 
import would mean 2 file not found queries until it actually 
finds the common `file.d`)... but it might be worth investigating 
if we do want to prefer it.


Anyway, if package.d is just like any other module, if we want to 
break up a module, then you can keep the existing file, with the 
existing module declaration, and just start moving stuff out. You 
wouldn't have to literally create a package.d file, you can just 
keep using your existing module.d file.
Aug 01 2017
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 8/1/17 10:29 AM, Adam D. Ruppe wrote:

 On Tuesday, 1 August 2017 at 14:20:00 UTC, Steven Schveighoffer wrote:

 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.


 How should it be fixed?


 
 Well, my preference would be to treat it just like any other module: the 
 compiler has a search path, but if it opens a file, the module name is 
 definitive.
 
 So we can keep the search path: `datetime.di`, then `datetime.d`, then 
 `datetime/package.d`, and any one of them, as long as it has `module 
 std.datetime;` at the top, can count equally as the package.d.


I don't remember the reason why we can't just have foo/... and foo.d and 
needed to use foo/package.d to do this.

It does fail to compile though if I use foo.d instead of package.d:

foo/bar.d(1): Error: package name 'foo' conflicts with usage as a module 
name in file foo.d


 BTW I kinda want to put `datetime/package.d` first on the search path, 
 but I fear that'd hurt the speed of the normal case (every import would 
 mean 2 file not found queries until it actually finds the common 
 `file.d`)... but it might be worth investigating if we do want to prefer 
 it.


Either way, you now have a file that is completely ignored, which is 
going to confuse someone.

I actually think the only "fix" at the moment is to error when both are 
present, since the compiler can't be sure which one is correct. So we 
are stuck with at least trying to find a package file. I don't see the 
speed of opening two files being a huge issue for compilation.


 Anyway, if package.d is just like any other module, if we want to break 
 up a module, then you can keep the existing file, with the existing 
 module declaration, and just start moving stuff out. You wouldn't have 
 to literally create a package.d file, you can just keep using your 
 existing module.d file.


I'm sure there's a reason why it's this way, but I don't know what it 
is. Anyone remember?

-Steve
Aug 01 2017
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 1 August 2017 at 14:29:28 UTC, Adam D. Ruppe wrote:

 So we can keep the search path: `datetime.di`, then 
 `datetime.d`, then `datetime/package.d`, and any one of them, 
 as long as it has `module std.datetime;` at the top, can count 
 equally as the package.d.


Sorry, isn't that how things work now? The problem here is that 
the compiler picks up the OLD datetime.d, and then things fail at 
the linking stage because symbols in the old datetime.d are not 
present in the new phobos.lib.
Aug 01 2017
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 1 August 2017 at 15:16:44 UTC, Vladimir Panteleev 
wrote:

 Sorry, isn't that how things work now?


For modules, yes. For packages, no. That inconsistency is what I 
want to change.

So since we have a package here and the compiler doesn't allow 
you to define a package in the existing datetime.d, we have to 
move the file. And unzipping doesn't pick up that the file was 
moved and leaves old stuff behind.

b.d(1): Error: package name 'aa' conflicts with usage as a module 
name in file

That error shouldn't exist.


 The problem here is that the compiler picks up the OLD 
 datetime.d


If we could just use datetime.d as the package file, there would 
be no old datetime.d anymore.
Aug 01 2017
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 29 July 2017 at 19:26:03 UTC, FoxyBrown wrote:

 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?


The only moron here is the one who simply uncompresses zip files 
on top of old software.  That either shows blatant ignorance of 
what uncompressing does, or sheer stupidity that it would work 
well for a compiler install.  Of course there is trivial software 
that consists of a single binary, for which you could do this.  
But there is nothing "logical" about that, just an exception for 
extremely simple software, which a compiler and its stdlib 
clearly isn't.


 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.


You can name so many, yet you did not name a single one. I guess 
it's not so easy.

Yes, that's hilarious, "portable" has essentially nothing to do 
with this.


 Please take your jack ass arrogant self somewhere else.


The only jackass is the one constantly braying about doing stupid 
things and how we should account for every dumb thing you do.  If 
you want to blame us for your not knowing how to deal with zip 
files, sounds like you're the one who should leave.


 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.


It is not moronic, it's a simple example that illustrates the 
larger principle, which is much more relevant for a compiler and 
its source.  The fact that you rail on the example rather than 
understanding the principle shows how much of an idiot you are.

I'm tired of your constant complaints in this forum, which 
reflect your own stupidity and ignorance more than anything else. 
  I'm amazed people have treated you this nicely in this thread, 
and yet you keep ranting about how the D devs should account for 
the most idiotic things you do.

GTFO, nobody wants you around.
Jul 29 2017
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Saturday, July 29, 2017 21:17:23 Joakim via Digitalmars-d-learn wrote:

 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.


 It is not moronic, it's a simple example that illustrates the
 larger principle, which is much more relevant for a compiler and
 its source.  The fact that you rail on the example rather than
 understanding the principle shows how much of an idiot you are.

 I'm tired of your constant complaints in this forum, which
 reflect your own stupidity and ignorance more than anything else.
   I'm amazed people have treated you this nicely in this thread,
 and yet you keep ranting about how the D devs should account for
 the most idiotic things you do.

 GTFO, nobody wants you around.


While I agree that he's not being reasonable, let's please try to keep this
civil.

We answered his question. He didn't like the answer. I think that at this
point, we can just let him be unhappy about it rather than needing to
continue to argue with him about it and being rude in return.

- Jonathan M Davis
Jul 29 2017
prev sibling parent reply FoxyBrown <Foxy Brown.IPT> writes:
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.
Jul 28 2017
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 28.07.2017 23:30, FoxyBrown wrote:

 
 because you didn't want to spend 10 minutes to fix a program.


You need to realize that the same thing applies to you. There is no "us" 
vs "you". I.e. if you know it to only be 10 minutes of work, why don't 
you just fix it yourself? Mike currently has as many commits in DMD as 
you do, and he is already busy contributing in other ways.

The compiler is here: https://github.com/dlang/dmd

Just implement the check, and commit it with commit message "fix Issue 
17699 - Importing a module that has both modulename.d and 
modulename/package.d should be an error", then create a pull request.

It is very easy to figure out where to add the check:

$ git clone git github.com:dlang/dmd
$ cd dmd/src/ddmd$

access.d:                printf("\ts is in same package.d module as sc\n");
astbase.d:        PKGunknown,     // not yet determined whether it's a 
package.d or not
astbase.d:        PKGmodule,      // already determined that's an actual 
package.d
grep: backend: Is a directory
dimport.d:                            // mod is a package.d, or a normal 
module which conflicts with the package name.
dmodule.d:         * Therefore, the result should be: filename/package.d
dmodule.d:         * iff filename/package.d is a file
dmodule.d:        const(char)* ni = FileName.combine(filename, 
"package.di");
dmodule.d:        const(char)* n = FileName.combine(filename, "package.d");
dmodule.d:            const(char)* n2i = FileName.combine(n, "package.di");
dmodule.d:            const(char)* n2 = FileName.combine(n, "package.d");
dmodule.d:    PKGunknown,     // not yet determined whether it's a 
package.d or not
dmodule.d:    PKGmodule,      // already determined that's an actual 
package.d
dmodule.d:    bool isPackageFile;         // if it is a package.d
dmodule.d:                // if module is not named 'package' but we're 
trying to read 'package.d', we're looking for a package module
dmodule.d:                bool isPackageMod = (strcmp(toChars(), 
"package") != 0) && (strcmp(srcfile.name.name(), "package.d") == 0 || 
(strcmp(srcfile.name.name(), "package.di") == 0));
dmodule.d:                    .error(loc, "importing package '%s' 
requires a 'package.d' file which cannot be found in '%s'", toChars(), 
srcfile.toChars());
dmodule.d:        isPackageFile = (strcmp(srcfile.name.name(), 
"package.d") == 0 ||
dmodule.d:                         strcmp(srcfile.name.name(), 
"package.di") == 0);
dmodule.d:            if (m && (strcmp(m.srcfile.name.name(), 
"package.d") != 0 &&
dmodule.d:                      strcmp(m.srcfile.name.name(), 
"package.di") != 0))
dmodule.d:             *     +- package.d
dmodule.d:             * If both are used in one compilation, 'pkg' as a 
module (== pkg/package.d)
dmodule.d:             *    later package.d loading will change 
Package::isPkgMod to PKGmodule and set Package::mod.
dmodule.d:             * 2. Otherwise, 'package.d' wrapped by 'Package' 
is inserted to the internal tree in here.
dmodule.d:                    /* If the previous inserted Package is not 
yet determined as package.d,
module.h:    PKGunknown, // not yet determined whether it's a package.d 
or not
module.h:    PKGmodule,  // already determined that's an actual package.d
module.h:    bool isPackageFile; // if it is a package.d


I.e., let's check out dmodule.d. We immediately find the following code:

extern (C++) const(char)* lookForSourceFile(const(char)** path, 
const(char)* filename)
{
     *path = null;
     /* Search along global.path for .di file, then .d file.
      */
     const(char)* sdi = FileName.forceExt(filename, global.hdr_ext);
     if (FileName.exists(sdi) == 1)
         return sdi;
     const(char)* sd = FileName.forceExt(filename, global.mars_ext);
     if (FileName.exists(sd) == 1)
         return sd;
     if (FileName.exists(filename) == 2)
     {
         /* The filename exists and it's a directory.
          * Therefore, the result should be: filename/package.d
          * iff filename/package.d is a file
          */
         const(char)* ni = FileName.combine(filename, "package.di");
         if (FileName.exists(ni) == 1)
             return ni;
         FileName.free(ni);
         const(char)* n = FileName.combine(filename, "package.d");
         if (FileName.exists(n) == 1)
             return n;
         FileName.free(n);
     }
     ...


I'll let you (or anyone else who would like to) take it from here.
Jul 29 2017
parent reply FoxyBrown <Foxy Brown.IPT> writes:
On Saturday, 29 July 2017 at 21:48:09 UTC, Timon Gehr wrote:

 On 28.07.2017 23:30, FoxyBrown wrote:

 
 because you didn't want to spend 10 minutes to fix a program.


 You need to realize that the same thing applies to you. There 
 is no "us" vs "you". I.e. if you know it to only be 10 minutes 
 of work, why don't you just fix it yourself? Mike currently has 
 as many commits in DMD as you do, and he is already busy 
 contributing in other ways.


EXACTLY! Your problem is that you are taking the you vs me too 
literal. I am talking about a mentality people have that think 
that them saving 10 minutes by not implementing something that 
will save 10 hours(low estimate) for everyone else is a good 
thing and criticize people when they say there is a better and 
try to condemn them and continue the status quo that wastes more 
time.
Jul 29 2017
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 29.07.2017 23:52, FoxyBrown wrote:

 On Saturday, 29 July 2017 at 21:48:09 UTC, Timon Gehr wrote:

 On 28.07.2017 23:30, FoxyBrown wrote:

 because you didn't want to spend 10 minutes to fix a program.


 You need to realize that the same thing applies to you. There is no 
 "us" vs "you". I.e. if you know it to only be 10 minutes of work, why 
 don't you just fix it yourself? Mike currently has as many commits in 
 DMD as you do, and he is already busy contributing in other ways.


 
 EXACTLY! Your problem is that you are taking the you vs me too literal. 
 I am talking about a mentality people have that think that them saving 
 10 minutes by not implementing something that will save 10 hours(low 
 estimate) for everyone else is a good thing and criticize people when 
 they say there is a better and try to condemn them and continue the 
 status quo that wastes more time.
 


Personally, I expect a minimal amount of consistency. I.e. when someone 
criticizes something, I only take them seriously when they don't go on 
to indulge in the very behavior they criticize.

Also, Mike was not showing this mindset. Mike was saying it is not 
reasonable to expect being able to manually and somewhat carelessly 
juggle around the files of the installation on the file system and only 
get expected behaviour. Everything else is your own interpretation.

Note that there are a lot of things that anyone could work on that saves 
them or someone else a lot of time, and not everyone agrees on 
priorities. I think it is safe to assume that it was not laziness that 
led to the current behaviour, but that it was just an oversight.
Jul 29 2017
prev sibling parent Grander <grander grander.grander> writes:
On Saturday, 29 July 2017 at 21:52:38 UTC, FoxyBrown wrote:

 On Saturday, 29 July 2017 at 21:48:09 UTC, Timon Gehr wrote:

 On 28.07.2017 23:30, FoxyBrown wrote:

 
 because you didn't want to spend 10 minutes to fix a program.


 You need to realize that the same thing applies to you. There 
 is no "us" vs "you". I.e. if you know it to only be 10 minutes 
 of work, why don't you just fix it yourself? Mike currently 
 has as many commits in DMD as you do, and he is already busy 
 contributing in other ways.


 EXACTLY! Your problem is that you are taking the you vs me too 
 literal. I am talking about a mentality people have that think 
 that them saving 10 minutes by not implementing something that 
 will save 10 hours(low estimate) for everyone else is a good 
 thing and criticize people when they say there is a better and 
 try to condemn them and continue the status quo that wastes 
 more time.


You should probably start to think about the real reason behind 
all this.
The thing you complain about is DMD being flexible, like any 
other compiler is too.

Try blundering around with the 'include' folder of your favorite 
C compiler,
but don't blame me if nothing works any any more, because your 
compiler uses that directory as-is as its include directory and 
does not have an internal whitelist of the files to expect there.

The next question is, would like DMD to require a whitelist for 
every single include directory, which means forcing each dev to 
write or generate a file list of his library directories?
Jul 31 2017
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Thursday, July 27, 2017 18:35:02 FoxyBrown via Digitalmars-d-learn wrote:

 On Thursday, 27 July 2017 at 18:14:52 UTC, Steven Schveighoffer

 wrote:

 On 7/27/17 1:58 PM, FoxyBrown wrote:

 On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis

 wrote:

 On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via

 Digitalmars-d-learn wrote:

 On 07/26/2017 09:20 PM, FoxyBrown wrote:
  >> Somebody else had the same problem which they solved by

 removing

  >> "entire dmd":
 http://forum.dlang.org/thread/ejybuwermnentslcyajs forum.dlang.org

  >> Ali
  >
  > Thanks, that was it. So I guess I have to delete the

 original dmd2 dir

  > before I install each time... didn't use to have to do

 that.

 Normally, it shouldn't be necessary. The splitting of the
 datetime package[1] had this effect but I'm not sure why the
 installation process can't take care of it.

 Ali

 [1]
 http://dlang.org/changelog/2.075.0.html#split-std-datetime


 It _should_ take care of it. The fact that multiple people
 have run into this problem and that the solution was to
 remove dmd and then reinstall it implies that there's a bug
 in the installer.

 - Jonathan M Davis


 I do not use the installer, I use the zip file. I assumed that
 everything would be overwritten and any old stuff would simply
 go unused.. but it seems it doesn't. If the other person used
 the installer then it is a problem with dmd itself not
 designed properly and using files that it shouldn't. I simply
 unzip the zip file in to the dmd2 dir and replace sc.ini...
 that has been my MO for since I've been trying out dmd2 and
 only recently has it had a problem.


 If you extracted the zip file over the original install, then
 it didn't get rid of std/datetime.d (as extracting a zipfile
 doesn't remove items that exist on the current filesystem but
 aren't in the zipfile). So I can totally see this happening.

 I don't know of a good way to solve this except to tell people,
 don't do that.

 -Steve


 But the issue was about missing symbols, not anything "extra". If
 datatime.d is there but nothing is using it, why should it
 matter? Why would it have any effect on the compilation process
 and create errors with D telling me something is being used that
 isn't?

 dmd shouldn't be picking up extraneous and non-connected files
 just for the fun of it.

 Basically, if no "references" escape out side of the D ecosystem,
 then there shouldn't be a problem.


You ended up with two versions of std.datetime. One was the module, and the
other was the package. importing std.datetime could have imported either of
them. dmd _should_ generate an error in that case, but I don't know if it
does or not. And depending on what you were doing, if you were dealing with
previously generated object files rather than fully building your project
from scratch, they would have depended on symbols that did not exist
anymore, because they were moved to other modules. And in that case, dmd
would not have generated an error about conflicting symbols, because the
code that was using the symbols had already been compiled. It would have
just complained about the missing symbols - which is what you saw.

If you'd just make sure that you uninstall the previous version before
installing the new one, you wouldn't have to worry about any such problems.
The installer would take care of that for you, but if you want to use the
zip file, then you're going to have to do it manually, and deleting the
directory and then unzipping instead of just unzipping on top of it would
take you less time than you've spent complaining about how it should have
worked.

- Jonathan M Davis
Jul 27 2017
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 07/27/2017 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote:


 You ended up with two versions of std.datetime. One was the module, 


and the

 other was the package.


I don't know how many people install from the zip file but I think the 
zip file should include a datetime.d file with the following statement 
in it:

static assert(false, "std.datetime is now a package; please remove this 
file");

Of course the problem is, the user would have to remove the file every 
time they unzipped potentially a later release. :/ We need more 
prominent information about the change I guess.

Ali
Jul 27 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/27/17 3:00 PM, Ali Çehreli wrote:

 On 07/27/2017 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
 
  > You ended up with two versions of std.datetime. One was the module, 
 and the
  > other was the package.
 
 I don't know how many people install from the zip file but I think the 
 zip file should include a datetime.d file with the following statement 
 in it:
 
 static assert(false, "std.datetime is now a package; please remove this 
 file");


If std/datetime.d is there, how does one import std/datetime/package.d?

-Steve
Jul 27 2017
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 07/27/2017 12:24 PM, Steven Schveighoffer wrote:

 On 7/27/17 3:00 PM, Ali Çehreli wrote:

 On 07/27/2017 11:54 AM, Jonathan M Davis via Digitalmars-d-learn wrote:

  > You ended up with two versions of std.datetime. One was the module,
 and the
  > other was the package.

 I don't know how many people install from the zip file but I think the
 zip file should include a datetime.d file with the following statement
 in it:

 static assert(false, "std.datetime is now a package; please remove
 this file");


 If std/datetime.d is there, how does one import std/datetime/package.d?

 -Steve


Currently not possible. (Thank you for the bug report. :) ) I tried to 
find a band aid to the issue. Otherwise, I agree that the compiler 
should issue an error.

Ali
Jul 27 2017
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/27/17 2:54 PM, Jonathan M Davis via Digitalmars-d-learn wrote:


 You ended up with two versions of std.datetime. One was the module, and the
 other was the package. importing std.datetime could have imported either of
 them. dmd _should_ generate an error in that case, but I don't know if it
 does or not.


It does not (obviously, we are discussing it :)

https://issues.dlang.org/show_bug.cgi?id=17699

-Steve
Jul 27 2017
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/27/17 2:35 PM, FoxyBrown wrote:

 On Thursday, 27 July 2017 at 18:14:52 UTC, Steven Schveighoffer wrote:

 On 7/27/17 1:58 PM, FoxyBrown wrote:

 On Thursday, 27 July 2017 at 12:23:52 UTC, Jonathan M Davis wrote:

 On Wednesday, July 26, 2017 22:29:00 Ali Çehreli via 
 Digitalmars-d-learn wrote:

 On 07/26/2017 09:20 PM, FoxyBrown wrote:
  >> Somebody else had the same problem which they solved by removing
  >>
  >> "entire dmd":
  >> http://forum.dlang.org/thread/ejybuwermnentslcyajs forum.dlang.org
  >>
  >> Ali
  >
  > Thanks, that was it. So I guess I have to delete the original 
 dmd2 dir
  > before I install each time... didn't use to have to do that.

 Normally, it shouldn't be necessary. The splitting of the datetime 
 package[1] had this effect but I'm not sure why the installation 
 process can't take care of it.

 Ali

 [1] http://dlang.org/changelog/2.075.0.html#split-std-datetime


 It _should_ take care of it. The fact that multiple people have run 
 into this problem and that the solution was to remove dmd and then 
 reinstall it implies that there's a bug in the installer.

 - Jonathan M Davis


 I do not use the installer, I use the zip file. I assumed that 
 everything would be overwritten and any old stuff would simply go 
 unused.. but it seems it doesn't. If the other person used the 
 installer then it is a problem with dmd itself not designed properly 
 and using files that it shouldn't. I simply unzip the zip file in to 
 the dmd2 dir and replace sc.ini... that has been my MO for since I've 
 been trying out dmd2 and only recently has it had a problem.


 If you extracted the zip file over the original install, then it 
 didn't get rid of std/datetime.d (as extracting a zipfile doesn't 
 remove items that exist on the current filesystem but aren't in the 
 zipfile). So I can totally see this happening.

 I don't know of a good way to solve this except to tell people, don't 
 do that.


 
 But the issue was about missing symbols, not anything "extra". If 
 datatime.d is there but nothing is using it, why should it matter? Why 
 would it have any effect on the compilation process and create errors 
 with D telling me something is being used that isn't?
 
 dmd shouldn't be picking up extraneous and non-connected files just for 
 the fun of it.


They aren't non-connected. If you import std.datetime, the compiler is 
first going to look for std/datetime.d. Not finding that, it will look 
for std/datetime/package.d.

The latter is what is supported and built into the library for 2.075. 
The former is a ghost of the original installation, but it's what *your* 
code is importing. You might not even import std.datetime, but rather 
something else that imports it. Either way, the compiler generates the 
wrong mangled names, and they don't match up with the ones in the library.

-Steve
Jul 27 2017
prev sibling parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Thursday, 27 July 2017 at 03:34:19 UTC, FoxyBrown wrote:

 Knowing that every time I upgrade to the latest "official" D 
 compiler I run in to trouble:

 I recompiled gtkD with the new compiler, same result.  My code 
 was working before the upgrade just fine and I did not change 
 anything.


I've had to delete my previous install at least 2 times before. 
It is an infrequent headache I hit because I'm not following 
appropriate install steps. I cannot expect upstream to support a 
DMD folder which has additional files from what they have 
provided.

Here is my attempt to explain the problem.

* std/datetime.d has a different mangled name than 
std/datetime/package.d.
* The phobos.lib contains the std.datetime.package module and no 
longer contains the std.datetime module.
* When the compiler is reading your code it sees imports for 
std.datetime and looks at the import location 
/install/directory/dmd2/src/std and it writes a reference to the 
std/datetime.d file.
* The linker takes over, loads up phobos.lib and barfs since the 
referenced symbol was not compiled into your obj file nor the 
released phobos.lib.

More recently the headache I've been hitting with upgrades is 
improvements to  safe and such. The bug fixes around this cause 
libraries I'm using to fail compilation. Even this isn't so bad, 
but the library that files is a dependent of a dub package I'm 
using. This means I have to wait for the dependent package to 
update and release followed by the dub package I'm actually 
referencing. So even if I create the needed patches, I have to 
wait at each step for the author to merge and tag their release. 
(or create a branch of the project and throw it in dub so I can 
control all the updates)
Jul 27 2017