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.

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.

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

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

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.

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.

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?

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

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.

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