Re: It makes me sick!
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.
Re: It makes me sick!
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.
Re: It makes me sick!
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
Re: It makes me sick!
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.
Re: It makes me sick!
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
Re: It makes me sick!
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?
Re: It makes me sick!
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.
Re: It makes me sick!
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.
Re: It makes me sick!
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 g...@github.com:dlang/dmd
$ cd dmd/src/ddmd$
$ grep "package.d" * # the obvious string to search for
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.
Re: It makes me sick!
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
Re: It makes me sick!
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.
Re: It makes me sick!
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.
Re: It makes me sick!
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.
Re: It makes me sick!
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.
Re: It makes me sick!
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.
Re: It makes me sick!
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."
Re: It makes me sick!
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.
Re: It makes me sick!
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.
Re: It makes me sick!
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 1 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.
Re: It makes me sick!
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.
Re: It makes me sick!
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 +, 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.
Re: It makes me sick!
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.
Re: It makes me sick!
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.
Re: It makes me sick!
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
Re: It makes me sick!
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 +, 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.
Re: It makes me sick!
On Friday, 28 July 2017 at 12:40:27 UTC, rjframe wrote: On Fri, 28 Jul 2017 05:14:16 +, 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.
Re: It makes me sick!
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 ...
Re: It makes me sick!
On Fri, 28 Jul 2017 05:14:16 +, 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.
Re: It makes me sick!
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.
Re: It makes me sick!
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.
Re: It makes me sick!
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.
Re: It makes me sick!
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
Re: It makes me sick!
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)
Re: It makes me sick!
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
Re: It makes me sick!
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
Re: It makes me sick!
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
Re: It makes me sick!
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
Re: It makes me sick!
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
Re: It makes me sick!
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/ejybuwermnentslcy...@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
Re: It makes me sick!
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/ejybuwermnentslcy...@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
Re: It makes me sick!
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.
Re: It makes me sick!
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.
Re: It makes me sick!
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/ejybuwermnentslcy...@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.
Re: It makes me sick!
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
Re: It makes me sick!
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/ejybuwermnentslcy...@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
Re: It makes me sick!
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/ejybuwermnentslcy...@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.
Re: It makes me sick!
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/ejybuwermnentslcy...@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
Re: It makes me sick!
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/ejybuwermnentslcy...@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
Re: It makes me sick!
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/ejybuwermnentslcy...@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.
Re: It makes me sick!
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/ejybuwermnentslcy...@forum.dlang.org Ali
Re: It makes me sick!
And yes, I'm using the correct phobos(the one that came with dmd2).
It makes me sick!
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__xopCmpFKxS3std8datetime7SysTimeKxS3std8datetime7SysTimeZi (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__T10FormatSpecTaZ10FormatSpeckmZv (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__T10FormatSpecTaZ10FormatSpeckbZv (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.
