On Friday, 3 November 2017 at 19:36:51 UTC, Jonathan M Davis wrote:
> Well, I won't deny that most of the core devs don't use FreeBSD, and the auto-tester situation with FreeBSD needs to be improved, but that code compiles just fine on my TrueOS system with dmd master, and that code is not the sort of thing that I would expect to have issues that depended on the OS it was on. What version of dmd are you running?
>
> - Jonathan M Davis

That is strange, that it compiles ok on TrueOS.

I don't think it's a FreeBSD issue as such, maybe more a posix issue??

I **cannot** compile that code that I mentioned on FreeBSD-11/12, Debian 8.5.0, or Centos 7.3.1611. In all those cases, DMD gives the same strange message. The only way I got it to work (on both Debian and Centos) was to compile with GDC instead.

On FreeBSD-11/12, it just won't compile whether I use DMD or LDC (and of course i don't have GDC on FreeBSD so don't know would happen if I did).

But: auto i = to!string(55);

Gee...that's a pretty simply piece of code, and shouldn't be failing at all, anywhere.

On Friday, 3 November 2017 at 19:36:51 UTC, Jonathan M Davis wrote:
> What version of dmd are you running?
>
> - Jonathan M Davis

========================================================
DMD (installed on..)
----
FreeBSD: DMD64 D Compiler v2.076.1
Debian: dmd_2.076.1-0_amd64.deb
Centos: 2.076.1/dmd-2.076.1-0.fedora.x86_64.rpm
Windows: dmd-2.076.1.exe

GDC (installed on Debian and Centos)
---
..(gdcproject.org 20161225-v2.068.2_gcc6) 6.3.0


LDC (installed on FreeBSD-11/12)
---
..LDC - the LLVM D compiler (1.3.0):
  based on DMD v2.073.2 and LLVM 3.9.1

========================================================

On Saturday, November 04, 2017 01:28:24 codephantom via Digitalmars-d wrote:
> On Friday, 3 November 2017 at 19:36:51 UTC, Jonathan M Davis
>
> wrote:
> > What version of dmd are you running?
> >
> > - Jonathan M Davis
>
> ========================================================
> DMD (installed on..)
> ----
> FreeBSD: DMD64 D Compiler v2.076.1
> Debian: dmd_2.076.1-0_amd64.deb
> Centos: 2.076.1/dmd-2.076.1-0.fedora.x86_64.rpm
> Windows: dmd-2.076.1.exe
>
> GDC (installed on Debian and Centos)
> ---
> ..(gdcproject.org 20161225-v2.068.2_gcc6) 6.3.0
>
>
> LDC (installed on FreeBSD-11/12)
> ---
> ..LDC - the LLVM D compiler (1.3.0):
>    based on DMD v2.073.2 and LLVM 3.9.1
>
> ========================================================

I don't know what to tell you. I just tested your example with

dmd 2.073.2
dmd 2.074.1
dmd 2.075.1
dmd 2.076.1
dmd master

on both TrueOS stable and Arch Linux, and it compiled just fine with all of them. And that example is so basic that something is seriously wrong if it doesn't work. So, that implies that you're doing something funny, but if you're installing dmd with an installer or package manager, then I would think that it would at least be set up correctly.

You might want to try

dmd --version

to make sure that you're running the
version you think you are and

which dmd

to make sure you're running the binary that you think you're running - e.g. maybe you did something previously with dmd that resulted in a borked install that has precedence in the path over the properly installed one - though I wouldn't think that you'd manage that on multiple systems like that. So, I don't know, but it's a thought.

- Jonathan M Davis

On Saturday, 4 November 2017 at 03:19:00 UTC, Jonathan M Davis wrote:
> maybe you did something previously with dmd that resulted in a borked install that has precedence in the path over the properly installed one - though I wouldn't think that you'd manage that on multiple systems like that. So, I don't know, but it's a thought.
>
> - Jonathan M Davis

nope. it cannot be any easier to install dmd

I also verified all the versions using dmd --version. They are all the same version, straight off the dlang website.

My TrueOS download just completed, so I'll give that a go later today.

btw. I discovered that a small change to the code, and it will compile ok:

--------------------------------------------------
import std.stdio;
//import std.conv; // this will *not* compile.
import std.conv : to; // this will compile ok.

void main()
{
    auto i = to!string(55);
    writeln("i is a ", typeof(i).stringof);
}
-----------------------------------------------

On Saturday, 4 November 2017 at 03:19:00 UTC, Jonathan M Davis wrote:
> So, that implies that you're doing something funny, but if you're installing dmd with an installer or package manager, then I would think that it would at least be set up correctly.

ok. I worked it out.

my file was named: to.d

so that caused dmd some confusion it seems.

change the name to something else, then dmd is ok with that code.

There's some real 'gotchas' when it comes to file names and dmd... I'm not sure I like it.

Interestingly, gdc didn't care that my file was named to.d, it did what I wanted the code to do. Would like dmd to do the same ;-)

But ldc does the same thing as dmd...neither likes a file named to.d when you're calling a template with the same name.

On Saturday, November 04, 2017 08:02:38 codephantom via Digitalmars-d wrote:
> On Saturday, 4 November 2017 at 03:19:00 UTC, Jonathan M Davis
>
> wrote:
> > So, that implies that you're doing something funny, but if you're installing dmd with an installer or package manager, then I would think that it would at least be set up correctly.
>
> ok. I worked it out.
>
> my file was named: to.d
>
> so that caused dmd some confusion it seems.
>
> change the name to something else, then dmd is ok with that code.
>
> There's some real 'gotchas' when it comes to file names and dmd... I'm not sure I like it.
>
> Interestingly, gdc didn't care that my file was named to.d, it did what I wanted the code to do. Would like dmd to do the same ;-)
>
> But ldc does the same thing as dmd...neither likes a file named to.d when you're calling a template with the same name.

Per the spec, if you don't give a module declaration, the name of the module is the name of the file (minus the extension). So, if you just give a module name (which you generally would in any real program rather than a quick test program), then it's not a problem - unless you give the module a name which conflicts with something that you're trying to use. If you'd had

module to;

at the top of the module, then you'd have the same problem regardless of the file name. The module name wins out over the imported name when there's a conflict, because the module name is a local symbol. In practice, that's rarely a problem, though poor module-naming practices could certainly make it a problem.

You can also work around it by using the fully qualified name (std.conv.to in this case) or by aliasing the symbol to a new name (I think that you can also statically import a symbol with a new name, but if so, that's basically the same as statically importing it and then aliasing it).

If gdc doesn't have the same behavior, it's either a bug, and/or it's related to the fact that the last released version of gdc matched dmd 2.068 (IIRC). So, right now, gdc is a terrible compiler to use unless you don't care about using a really old version of D. I think that they're getting close to releasing an update that's much closer to the current version of dmd, but IIUC, the switch of the frontend from C++ to D was a huge roadblock for them, since they had a lot of redesign work to do (they also don't have much manpower). So, it's taken them quite a while to get back up-to-date.

- Jonathan M Davis

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.

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

On Saturday, 4 November 2017 at 08:17:44 UTC, Jonathan M Davis wrote:
> Per the spec, if you don't give a module declaration, the name of the module is the name of the file (minus the extension). So, if you just give a module name (which you generally would in any real program rather than a quick test program), then it's not a problem - unless you give the module a name which conflicts with something that you're trying to use.

Thanks. I had actually read that spec, but forgot all about it.

Having only used D for a month or so, I'm only writing snippets (107 so far), not actual programs.

I actually had to edit the source code of my editor, so that when I create/save a .d file, if I happen to use hypens, then my editor will now automatically replace them with underscores (again, just because the way D deals with files).

I think I'll do some more editing, and have my editor insert a default module name as well.

Still, I don't like the spec. I would prefer that dmd did not implictly do stuff like that. Then I could regain the freedom to name my files however I wanted.

On Saturday, November 04, 2017 08:38:58 codephantom via Digitalmars-d wrote:
> On Saturday, 4 November 2017 at 08:17:44 UTC, Jonathan M Davis
>
> wrote:
> > Per the spec, if you don't give a module declaration, the name of the module is the name of the file (minus the extension). So, if you just give a module name (which you generally would in any real program rather than a quick test program), then it's not a problem - unless you give the module a name which conflicts with something that you're trying to use.
>
> Thanks. I had actually read that spec, but forgot all about it.
>
> Having only used D for a month or so, I'm only writing snippets
> (107 so far), not actual programs.
>
> I actually had to edit the source code of my editor, so that when I create/save a .d file, if I happen to use hypens, then my editor will now automatically replace them with underscores (again, just because the way D deals with files).
>
> I think I'll do some more editing, and have my editor insert a default module name as well.
>
> Still, I don't like the spec. I would prefer that dmd did not implictly do stuff like that. Then I could regain the freedom to name my files however I wanted.

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

On Saturday, November 04, 2017 01:30:12 Walter Bright via Digitalmars-d 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.
>
> Even simple DLL support in Windows keeps breaking because it is not part of the autotester test suite.

Just the other day, a fix for std.experimental.allocator that was supposed to fix FreeBSD 10.x/11.x fixed 32-bit but broke 64-bit - and it had no effect on FreeBSD 8.4 or whatever it is that's running on the main autotester FreeBSD boxes. The problem was caught and fixed, but for any given platform, unless we're running it as part of the autotester, or someone runs the tests locally and reports any breakages that occur, it's trivial for bugs to creep in, as annoying as that is.

As such, I don't think that the odds are good at all that running modern D programs on Windows XP is going to work correctly in general. I don't expect that it's completely broken, but I sure wouldn't trust it without running the complete test suite in XP to verify whatever version of dmd, druntime, and Phobos you're trying to use - and I think that we may even be using some Windows API calls in Phobos which were introduced in Vista, since a lot of improved API calls were added in Vista, and it's certainly the case that _those_ won't work in XP.

I confess that I have little sympathy if D doesn't work in XP though given that the fact that Microsoft doesn't support it anymore makes it completely unsafe to run unless it's not connected to the Internet.

- Jonathan M Davis