On 04.11.2017 09:30, Walter Bright wrote:
> On 11/3/2017 5:29 AM, Rainer Schuetze wrote:
>>> Note that dmd still runs on Windows XP, though it is not officially supported. You just need to be careful about using TLS variables on it :-(
>> to avoid spreading this false information: TLS in D works in dynamically loaded DLLs on WinXP since 2010.
> 
> The fact that we haven't officially tested that it works for years means be careful about attesting that it does work.

It is working in Visual D since that time.

> 
> Even simple DLL support in Windows keeps breaking because it is not part of the autotester test suite.

Agreed, they haven't been officially tested a lot in the past, but you have merged the PR to do that back in April: https://github.com/dlang/dmd/pull/6709

On Saturday, 4 November 2017 at 08:46:37 UTC, Jonathan M Davis wrote:
> Well, the modules need names. So, either, the compiler is going to have to pick a name for you, or you're going to have to give it one. In general though, D was designed with the idea that modules would match files and packages would match directories - and that the names on disk would match the ones in the file. Overall, things are much simpler that way. On some level, you can get around that by giving module names that don't match the file names, but in general, you're just begging for trouble if you don't make your file names and module names match (at least some stuff is going to be looking for modules by looking at the file system for them with the assumption that the package names match folders and the module names match files). So, in the long run, you'll just have fewer problems if you make your file names and module names match.
>
> - Jonathan M Davis

Yes. All that makes complete sense I guess.

It might also make sense, that if a source code file does not contain a module statement, then it should not be treated as a module, and the compiler should look to the import statements instead of implicitly making in a module.

btw. That bug in gdc, which appear to do just that, is a nice bug ;-)

On Saturday, 4 November 2017 at 09:34:05 UTC, codephantom wrote:
> Yes. All that makes complete sense I guess.
>
> It might also make sense, that if a source code file does not contain a module statement, then it should not be treated as a module, and the compiler should look to the import statements instead of implicitly making in a module.
>
> btw. That bug in gdc, which appear to do just that, is a nice bug ;-)

I should add one more thing.

Both Andrei's book (The D Programming Language), and Ali's book (Programming in D), provide the usual 'hello world' thing, at the beginning. In both cases, the 'module' statement is not part of that example. That is consistent with other 'hello world' I've seen in D. All the other code in both book also consistently leaves out the 'module' statement.

My point being, given that "D is serious about modularity" (as Andrei put it in his book), then I think all 'hello world' examples should include the 'module' specifier as well, and explain why it's there too. I think that would really aid those who are new to the language..

On Saturday, November 04, 2017 09:34:05 codephantom via Digitalmars-d wrote:
> On Saturday, 4 November 2017 at 08:46:37 UTC, Jonathan M Davis
>
> wrote:
> > Well, the modules need names. So, either, the compiler is going to have to pick a name for you, or you're going to have to give it one. In general though, D was designed with the idea that modules would match files and packages would match directories - and that the names on disk would match the ones in the file. Overall, things are much simpler that way. On some level, you can get around that by giving module names that don't match the file names, but in general, you're just begging for trouble if you don't make your file names and module names match (at least some stuff is going to be looking for modules by looking at the file system for them with the assumption that the package names match folders and the module names match files). So, in the long run, you'll just have fewer problems if you make your file names and module names match.
> >
> > - Jonathan M Davis
>
> Yes. All that makes complete sense I guess.
>
> It might also make sense, that if a source code file does not contain a module statement, then it should not be treated as a module, and the compiler should look to the import statements instead of implicitly making in a module.

The language has no concept of any D code not being in a module. Not only would adding such a concept complicate things, but it wouldn't help real world programs. Having the module name infered from the file name was a simple solution to the problem and usually doesn't cause problems (at least as long as you're just dealing with toy programs).

Personally, I think that we would have been better off just requiring the module statements (especially since it doesn't work to have modules in packages without the module statements), but I doubt that that change would be accepted at this point, particularly since it wouldn't matter for much other than toy programs. Mostly all it would do is force folks to use module statements up front when learning the language instead of trying to go without like some do and then inevitably hitting issues when they start to use packages. And that has value, but I doubt that it would be enough of an argument to get such a change made.

- Jonathan M Davis

On Saturday, 4 November 2017 at 08:46:37 UTC, Jonathan M Davis wrote:
> Well, the modules need names. So, either, the compiler is going to have to pick a name for you, or you're going to have to give it one.

ok..just one more ... I can't help myself..

I know that D does not have a 'global namespace', but what if did?

Then, if a file does not declare its own module namespace (like none of my 109 snippets) then what's the big deal with having the compiler just use that (statically known) global name space.

I wonder what the implication would be, if any.

oh..and it would save a few keystrokes...which seems to be a main focus of numerous DIPs ;-)

On Sat, 04 Nov 2017 09:51:12 +0000, codephantom wrote:

>> It might also make sense, that if a source code file does not contain a module statement, then it should not be treated as a module, and the compiler should look to the import statements instead of implicitly making in a module.
>>
> 
> I should add one more thing.
> 
> Both Andrei's book (The D Programming Language), and Ali's book (Programming in D), provide the usual 'hello world' thing, at the beginning. In both cases, the 'module' statement is not part of that example. That is consistent with other 'hello world' I've seen in D. All the other code in both book also consistently leaves out the 'module' statement.
> 
> My point being, given that "D is serious about modularity" (as Andrei put it in his book), then I think all 'hello world' examples should include the 'module' specifier as well, and explain why it's there too. I think that would really aid those who are new to the language..

Many people seem to leave the module statement out of their main.d/app.d files; I think it's a way to say "this is the main thing - don't import it from somewhere else." Basically, it's easier to act like that code isn't in a module than it is to have the compiler support code not in a module.

On Saturday, 4 November 2017 at 11:04:33 UTC, rjframe wrote:
> Many people seem to leave the module statement out of their main.d/app.d files; I think it's a way to say "this is the main thing - don't import it from somewhere else." Basically, it's easier to act like that code isn't in a module than it is to have the compiler support code not in a module.

I think maybe, the compiler should just refuse to compile anything, unless the module namespace is explicitely stated. I don't know what the effects of that would be in total, but it would avoid compilation errors when, for example, you do what I do - which is create 100's of snippets of code, save each snippet with a name corresponding to the thing 'snipped' (so I can easily find them again), and then discovering that they won't compile.

(i.e. D having neither a default global namespace, and then the compiler making implicit assumptions about what namespace to use, based on the file name, seems problematic. Better to just 'refuse to compile' a file, unless it explicitely states a module namespace.

e.g. (the .d files further below, without any module name specified, will not compile - presumably because the compiler is having problems resolving the namespace.

So why is the compiler forced to do that anyway? Why not just refuse to compile simply because no module namespace was provided - then a nice clear message stating that, could be provided back to the user, instead of the cryptic message: "  Error: function expected before (), not module writeln of type void"


-----save this as writeln.d and it will not compile -----------------
import std.stdio;

void main()
{
    writeln("Hello World!");
}
-------------------------------


-----save this as to.d and it will not compile -----------------
import std.stdio;
import std.conv;

void main()
{
    auto i = to!string(55);

}
----------------------------------------

On 11/4/2017 1:54 AM, Rainer Schuetze wrote:
> 
> 
> On 04.11.2017 09:30, Walter Bright wrote:
>> On 11/3/2017 5:29 AM, Rainer Schuetze wrote:
>>>> Note that dmd still runs on Windows XP, though it is not officially supported. You just need to be careful about using TLS variables on it :-(
>>> to avoid spreading this false information: TLS in D works in dynamically loaded DLLs on WinXP since 2010.
>>
>> The fact that we haven't officially tested that it works for years means be careful about attesting that it does work.
> 
> It is working in Visual D since that time.

Ok, but does that mean you're testing the TLS support on XP?

I run dmd regularly on an XP box, but that just means dmd itself runs on XP. (I converted the front end of DMC++ to D, using DMD in -betterC mode, and XP is the last operating system that supports DOS programs. XP has the DOS DMC++ test suite on it.)


>> Even simple DLL support in Windows keeps breaking because it is not part of the autotester test suite.
> 
> Agreed, they haven't been officially tested a lot in the past, but you have merged the PR to do that back in April: https://github.com/dlang/dmd/pull/6709

It's good that the samples work, but there's a bit more to the smoke test suite I had for it. I haven't tried it in a while.

On Sunday, 5 November 2017 at 09:17:37 UTC, Walter Bright wrote:
> On 11/4/2017 1:54 AM, Rainer Schuetze wrote:
>> 
>> 
>> On 04.11.2017 09:30, Walter Bright wrote:
>>> On 11/3/2017 5:29 AM, Rainer Schuetze wrote:
>>>>> Note that dmd still runs on Windows XP, though it is not officially supported. You just need to be careful about using TLS variables on it :-(
>>>> to avoid spreading this false information: TLS in D works in dynamically loaded DLLs on WinXP since 2010.
>>>
>>> The fact that we haven't officially tested that it works for years means be careful about attesting that it does work.
>> 
>> It is working in Visual D since that time.
>
> Ok, but does that mean you're testing the TLS support on XP?
>
> I run dmd regularly on an XP box, but that just means dmd itself runs on XP. (I converted the front end of DMC++ to D, using DMD in -betterC mode, and XP is the last operating system that supports DOS programs. XP has the DOS DMC++ test suite on it.)
>
I don't think that's true. It's a 32bit/64bit division, not a Windows version thing. A 32 bits installation can run 16 bits and 32 bits programs, a 64 bits version can run natively 32 bits and 64 bits programs. None can run all 3 modes natively.
I know with certainty that Windows 8.1 32 bits installation could still run DOS and Windows 16 bits apps. I haven't seen evidence to the contrary for Windows 10.
Windows XP was the last version that was installed massively in 32 bits mode. From Vista on, the proportion of 32 bits installations (and thus losing 16 bits support) dwindeled.

On 11/5/2017 3:13 AM, Patrick Schluter wrote:
> On Sunday, 5 November 2017 at 09:17:37 UTC, Walter Bright wrote:
>> I run dmd regularly on an XP box, but that just means dmd itself runs on XP. (I converted the front end of DMC++ to D, using DMD in -betterC mode, and XP is the last operating system that supports DOS programs. XP has the DOS DMC++ test suite on it.)
>>
> I don't think that's true. It's a 32bit/64bit division, not a Windows version thing. A 32 bits installation can run 16 bits and 32 bits programs, a 64 bits version can run natively 32 bits and 64 bits programs. None can run all 3 modes natively.

Is that an issue with the CPU, or the operating system?

> I know with certainty that Windows 8.1 32 bits installation could still run DOS and Windows 16 bits apps. I haven't seen evidence to the contrary for Windows 10.
> Windows XP was the last version that was installed massively in 32 bits mode.  From Vista on, the proportion of 32 bits installations (and thus losing 16 bits support) dwindeled.

Windows 7  64 bit will not run 16 bit programs. Try it and you get a dialog box "Unsupported 16-Bit Application". I haven't tried Win 7 32, but some googling around shows you are correct.