Derek Parnell wrote:

> 
> This is a quote from the D documentation on modules ...
> 
> "By convention, package and module names are all lower case. This is
> because those names have a one-to-one correspondence with the operating
> system's directory and file names, and many file systems are not case
> sensitive. All lower case package and module names will minimize problems
> moving projects between dissimilar file systems."
> 
> Good advice to heed.
> 

Well, it may be good advice, but I consider it impractical since it's not at all consistent with the D language itself (where case sensitivity is the norm within source files).  I think it's an ugly and limiting requirement (or convention).

The naming of namespaces should be parallel to any other D convention. If this is a problem, then mapping D namespaces to the filesystem was not such a good idea, because this makes D more dependent on OS filesystem technology and schemes.  That probably is not a future proof approach.

Furthermore, contrary to the statement Walter makes there, I don't know of many file systems that are truly case insensitive, at least pertaining to those OSes that D is available on currently: win32 is the closest that comes to that.  Even windows, though, allows files and directories to be named with uppercase and maintains the case state... Thus, as long as you remember to be consistent with filename casing, using uppercase in module names is not an issue on Windows.

I consider the residual case insensitivity in Win32 a defect and a nasty side effect of the DOS era.  If Windows is the only OS that makes keeping Walter's convention a "good idea", I'm not convinced. :)

-JJR

Derek Parnell wrote:
> On Mon, 03 Jul 2006 03:30:06 +1000, Hasan Aljudy <hasan.aljudy@gmail.com>  wrote:
> 
>> freud wrote:
>>
>>> why do i always get a "xx.d:module xx cannot read file xx.d" when i  compile
>>> xx.d?  i'm just beginning to learn the d language, anyone can help me ?
>>>
>>
>> Could be anything, but ..
>> When it happens to me, it's because I'm using `build` and the module  name doesn't match the file name.
> 
> 
> Well, I still can cause it to happen no matter method I choose. For  example ...
> 
> ---- main.d ----
> module xyzzy;
> void main(){}
> ------------------
> 
> build main.d is successful.
> dmd main.d is successful.
> 

This will compile fine, but try it, for example, with two such modules, where one imports the other.

I'm not saying it's build's fault by the way .. because it's not.
But this has happened to me before, when module names don't correctly match to their file names.

On Sun, 02 Jul 2006 21:31:32 -0600, Hasan Aljudy wrote:

I finally got it to issue the message, and it has nothing to do with any of the suggestions so far.

I create the file "c:\temp\main.d" that contained a single line

   void main(){}

I then set my current directory to C:\

and this is the result I got ...
===================
C:\>type c:\temp\main.d
void main(){}
C:\>dmd main.d
main.d: module main cannot read file 'main.d'

C:\>

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

From this I gather than the first 'main.d' in the message is from the command line, the module name is derived from the 'main.d' on the command line and then the compiler said it could find the file.


When I run this test with Build I get ...

C:\>build main
Path and Version : y:\util\build.exe v3.02(2207)
  built on Sat Jun 24 00:44:57 2006
** File 'main.d' not found.
Error: build:Not all supplied files exist.

C:\>
-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
3/07/2006 2:42:31 PM

Derek Parnell wrote:
> On Sun, 02 Jul 2006 21:31:32 -0600, Hasan Aljudy wrote:
> 
> I finally got it to issue the message, and it has nothing to do with any of
> the suggestions so far.
> 
> I create the file "c:\temp\main.d" that contained a single line 
> 
>    void main(){}
> 
> I then set my current directory to C:\
> 
> and this is the result I got ...
> ===================
> C:\>type c:\temp\main.d
> void main(){}
> C:\>dmd main.d
> main.d: module main cannot read file 'main.d'
> 
> C:\>
> 
> ================

Why create the c:\temp\main.d file? The error happens anywhere, with any module, just by typing "dmd foobar.d" where foobar.d doesn't exist.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

On Mon, 03 Jul 2006 17:58:59 +1000, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:

> Derek Parnell wrote:
>> On Sun, 02 Jul 2006 21:31:32 -0600, Hasan Aljudy wrote:
>>  I finally got it to issue the message, and it has nothing to do with any of
>> the suggestions so far.
>>  I create the file "c:\temp\main.d" that contained a single line     void main(){}
>>  I then set my current directory to C:\
>>  and this is the result I got ...
>> ===================
>> C:\>type c:\temp\main.d
>> void main(){}
>> C:\>dmd main.d
>> main.d: module main cannot read file 'main.d'
>>  C:\>
>>  ================
>
> Why create the c:\temp\main.d file? The error happens anywhere, with any module, just by typing "dmd foobar.d" where foobar.d doesn't exist.

Because I was doing many variations and I want to be complete, okay!? Once one knows what triggers the problem, one doesn't have to do all the dead-ends but I needed to show that the existance of the file SOMEWHERE in the system didn't influence the outcome.

-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:
> On Mon, 03 Jul 2006 17:58:59 +1000, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:
> 
>> Derek Parnell wrote:
>>> On Sun, 02 Jul 2006 21:31:32 -0600, Hasan Aljudy wrote:
>>>  I finally got it to issue the message, and it has nothing to do with any of
>>> the suggestions so far.
>>>  I create the file "c:\temp\main.d" that contained a single line     void main(){}
>>>  I then set my current directory to C:\
>>>  and this is the result I got ...
>>> ===================
>>> C:\>type c:\temp\main.d
>>> void main(){}
>>> C:\>dmd main.d
>>> main.d: module main cannot read file 'main.d'
>>>  C:\>
>>>  ================
>>
>> Why create the c:\temp\main.d file? The error happens anywhere, with any module, just by typing "dmd foobar.d" where foobar.d doesn't exist.
> 
> Because I was doing many variations and I want to be complete, okay!? Once one knows what triggers the problem, one doesn't have to do all the dead-ends but I needed to show that the existance of the file SOMEWHERE in the system didn't influence the outcome.
> 
> --Derek Parnell
> Melbourne, Australia

I'm sorry, I didn't mean to upset. It's just that it seemed clear that a file that is totally unknown to DMD (it's name or variations thereof don't appear on the command line, source code, config files, or anywhere else) couldn't possibly affect DMD's outcome.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

John Reimer wrote:
> Well, it may be good advice, but I consider it impractical since it's not at all consistent with the D language itself (where case sensitivity is the norm within source files).  I think it's an ugly and limiting requirement (or convention).

It's a convention. But one will run into difficulty if doing things like naming one module "foo" and another module "Foo".

> The naming of namespaces should be parallel to any other D convention. If this is a problem, then mapping D namespaces to the filesystem was not such a good idea, because this makes D more dependent on OS filesystem technology and schemes.  That probably is not a future proof approach.

The convention will work with both case sensitive and case insensitive file systems. I don't foresee any other convention ever being used, but even if one is, I expect it can be dealt with.

> Furthermore, contrary to the statement Walter makes there, I don't know of many file systems that are truly case insensitive, at least pertaining to those OSes that D is available on currently: win32 is the closest that comes to that.  Even windows, though, allows files and directories to be named with uppercase and maintains the case state... Thus, as long as you remember to be consistent with filename casing, using uppercase in module names is not an issue on Windows.

That's true, but you still can't have a "Foo" and "foo" coexist.

> I consider the residual case insensitivity in Win32 a defect and a nasty side effect of the DOS era.  If Windows is the only OS that makes keeping Walter's convention a "good idea", I'm not convinced. :)

It's been a while since I've used VMS, but it was also case insensitive. So was OS/2. DOS, VMS, Windows, and OS/2 all trace back to DEC operating systems which were case insensitive. Linux, etc., all trace back to Unix which was case sensitive.