www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - newbie -- how to build module?

reply "Alf P. Steinbach" <alf.p.steinbach+usenet gmail.com> writes:
I first started with a Windows message box program and installing an 
IDE. I'm now using the VisualD plug-in with the Visual Studio 10 Shell, 
after battling a bit with installation of service pack 1 for Visual 
Studio. VisualD works, sort of, except the devs forgot that the resource 
compiler needs an INCLUDE variable so that it finds <windows.h>, so, 
silly as it is, the VisualD plugin can't be used directly as-is to 
create a modern look and feel Windows program. I solved it by running 
Visual Studio from the command line.

Anyway, I haven't yet started delving into the language documentation or 
any tutorials, just used gut-feeling, so I'd appreciate discussion of 
how to make this my first D console program less non-idiomatic <g>:


<code>
import std.stdio;
import std.ascii;
import std.string;            // chop

//import core.sys.windows.unicode_based_api;    <-- DOES NOT WORK.

char lastCh( string s )
{
     return (s.length == 0? '\0' : s[s.length - 1]);
}

void main()
{
     char[]    buf;

     writeln( "module core.sys.windows.unicode_api;" );
     writeln( "import core.sys.windows.windows;" );
     while( stdin.readln( buf ) )
     {
         string    identifier;
         bool    inIdentifier    = false;

         foreach( char c; buf )
         {
             if( isAlpha( c ) )
             {
                 if( !inIdentifier ) { identifier = ""; }
                 identifier ~= c;
                 inIdentifier = true;
             }
             else if( c == '_' || isDigit( c ) )
             {
                 if( inIdentifier )
                 {
                     identifier ~= c;
                 }
             }
             else
             {
                 inIdentifier = false;
                 if( isWhite( c ) )
                 {
                     // Ignore.
                 }
                 else
                 {
                     if( c == '(' && lastCh( identifier ) == 'W' )
                     {
                         immutable string name = chop( identifier ); 
     // removes last char
                         writeln( "alias ", identifier, " ", name, ";" );
                     }
                     identifier = "";
                 }
             }
         }
     }
}
</code>

The problem is, I can't manage to build the generated module.

The compiler is protesting something about the module being in a source 
code file that it can't read.

E.g. with "import unicode_based_api;" it exclaims,

<eror>
Error	1	Error: module unicode_based_api is in file 'unicode_based_api.d' 
which cannot be read	d:\winfolders\alf\my documents\visual studio 
2010\Projects\GenWinFuncAliases\GenWinFuncAliases\main.d	5	
</eror>

?


Cheers,

- Alf
Feb 12 2012
next sibling parent Mantis <mail.mantis.88 gmail.com> writes:
13.02.2012 9:45, Alf P. Steinbach пишет:

 I first started with a Windows message box program and installing an 
 IDE. I'm now using the VisualD plug-in with the Visual Studio 10 
 Shell, after battling a bit with installation of service pack 1 for 
 Visual Studio. VisualD works, sort of, except the devs forgot that the 
 resource compiler needs an INCLUDE variable so that it finds 
 <windows.h>, so, silly as it is, the VisualD plugin can't be used 
 directly as-is to create a modern look and feel Windows program. I 
 solved it by running Visual Studio from the command line.

 Anyway, I haven't yet started delving into the language documentation 
 or any tutorials, just used gut-feeling, so I'd appreciate discussion 
 of how to make this my first D console program less non-idiomatic <g>:


 <code>
 import std.stdio;
 import std.ascii;
 import std.string; // chop

 //import core.sys.windows.unicode_based_api; <-- DOES NOT WORK.

 char lastCh( string s )
 {
 return (s.length == 0? '\0' : s[s.length - 1]);
 }

 void main()
 {
 char[] buf;

 writeln( "module core.sys.windows.unicode_api;" );
 writeln( "import core.sys.windows.windows;" );
 while( stdin.readln( buf ) )
 {
 string identifier;
 bool inIdentifier = false;

 foreach( char c; buf )
 {
 if( isAlpha( c ) )
 {
 if( !inIdentifier ) { identifier = ""; }
 identifier ~= c;
 inIdentifier = true;
 }
 else if( c == '_' || isDigit( c ) )
 {
 if( inIdentifier )
 {
 identifier ~= c;
 }
 }
 else
 {
 inIdentifier = false;
 if( isWhite( c ) )
 {
 // Ignore.
 }
 else
 {
 if( c == '(' && lastCh( identifier ) == 'W' )
 {
 immutable string name = chop( identifier ); // removes last char
 writeln( "alias ", identifier, " ", name, ";" );
 }
 identifier = "";
 }
 }
 }
 }
 }
 </code>

 The problem is, I can't manage to build the generated module.

 The compiler is protesting something about the module being in a 
 source code file that it can't read.

 E.g. with "import unicode_based_api;" it exclaims,

 <eror>
 Error 1 Error: module unicode_based_api is in file 
 'unicode_based_api.d' which cannot be read d:\winfolders\alf\my 
 documents\visual studio 
 2010\Projects\GenWinFuncAliases\GenWinFuncAliases\main.d 5
 </eror>

 ?


 Cheers,

 - Alf


What is "unicode_based_api" file? I don't see it in core.sys.windows:
http://github.com/D-Programming-Language/druntime/tree/master/src/core/sys/windows
Feb 13 2012
prev sibling next sibling parent Mantis <mail.mantis.88 gmail.com> writes:
13.02.2012 10:16, Mantis ?????:

 ...snip...
 What is "unicode_based_api" file? I don't see it in core.sys.windows:
 http://github.com/D-Programming-Language/druntime/tree/master/
rc/core/sys/windows 


Oh, I guess I understand what you're trying to do. IIRC, druntime source 
files get compiled into phobos.lib, so to make add-on for it you should 
rebuild both druntime and phobos.
Feb 13 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/12/2012 11:45 PM, Alf P. Steinbach wrote:

 Anyway, I haven't yet started delving into the language documentation or any
 tutorials, just used gut-feeling, so I'd appreciate discussion of how to make
 this my first D console program less non-idiomatic <g>:


 <code>
 import std.stdio;
 import std.ascii;
 import std.string; // chop

 //import core.sys.windows.unicode_based_api; <-- DOES NOT WORK.


There is no D import with the name unicode_based_api. Where does that name come 
from?

For a console app that just reads and writes files, there shouldn't be a need
to 
access the Windows API at all. The D runtime library does that for you.
Feb 13 2012
next sibling parent reply James Miller <james aatch.net> writes:
Somewhat off topic, but Alf, I have noticed you posting a few times, I
think newbie questions are better suited to the digitalmars.D.learn
mailing list.

Thanks

James Miller
Feb 13 2012
parent reply "Alf P. Steinbach" <alf.p.steinbach+usenet gmail.com> writes:
On 13.02.2012 12:48, James Miller wrote:

 Somewhat off topic, but Alf, I have noticed you posting a few times,


Uhm, 2 times.



 I think newbie questions are better suited to the digitalmars.D.learn
 mailing list.


I am sure that if but the right mindset was brought to bear, the D 
community and in particular those with some responsibility for the 
toolset and language, could learn as much from my current 2 postings as 
I am learning about the tools and language.

Not to be artificially humble, that's not my style. ;-)


Cheeers & hth.,

- ALf
Feb 13 2012
next sibling parent reply David Nadlinger <see klickverbot.at> writes:
On 2/13/12 1:13 PM, Alf P. Steinbach wrote:

 I am sure that if but the right mindset was brought to bear, the D
 community and in particular those with some responsibility for the
 toolset and language, could learn as much from my current 2 postings as
 I am learning about the tools and language.

 Not to be artificially humble, that's not my style. ;-)


Nobody doubts that feedback, especially from people new to the language, 
is important. And indeed, the first topic you started is perfectly 
appropriate here. However, for beginner questions like your second one, 
we have a separate newsgroup, digitalmars.D.learn. Don't forget that 
some people are subscribed just to dm.D via the mailing list interface 
to keep up to date with D development related things, and basic 
questions would only clutter their inbox.

And not to be artificially restrained, it's not likely that your 
question regarding import search paths will fundamentally affect the D 
module design, is it? :P

Anyway, as far as the compilation model goes, for everything search path 
and linker-related, a useful first-order approximation is just to think 
of it as C++. Each import search path (from dmd.conf/sc.ini or the -I 
command line switches, plus the working directory) is treated as 
possible root, and similar to »#include <foo/bar.h>«, »import foo.bar;« 
looks for a foo/bar.d file in any of the import directories.

So, if you really want to extend druntime's core package (which you 
normally don't, unless you plan on submitting your additions back 
upstream), you would put your generated unicode_api.d in a 
core/sys/windows directory under one of the import search paths.

David
Feb 13 2012
parent reply "Alf P. Steinbach" <alf.p.steinbach+usenet gmail.com> writes:
On 13.02.2012 13:50, David Nadlinger wrote:

 On 2/13/12 1:13 PM, Alf P. Steinbach wrote:

 I am sure that if but the right mindset was brought to bear, the D
 community and in particular those with some responsibility for the
 toolset and language, could learn as much from my current 2 postings as
 I am learning about the tools and language.

 Not to be artificially humble, that's not my style. ;-)


 Nobody doubts that feedback, especially from people new to the language,
 is important. And indeed, the first topic you started is perfectly
 appropriate here. However, for beginner questions like your second one,
 we have a separate newsgroup, digitalmars.D.learn. Don't forget that
 some people are subscribed just to dm.D via the mailing list interface
 to keep up to date with D development related things, and basic
 questions would only clutter their inbox.


OK, thanks, I'll try that.

However, by looking at the articles in the two groups I don't see much 
difference or clear trend towards this or that.

Are there group charters?



 And not to be artificially restrained, it's not likely that your
 question regarding import search paths will fundamentally affect the D
 module design, is it? :P


I don't know, but that's the beauty of the newbie perspective.

As a newbie one tries things and asks about things that a person more 
accustomed to The Usual Ways(TM) just discounts immediately without 
further reflection  --  missing out on the opportunities...

For example, I hope that some good nice person will add the enclosed 
module to the standard library, so that people accustomed to clean 
Windows API function names in C++, can have the same in D.



 Anyway, as far as the compilation model goes, for everything search path
 and linker-related, a useful first-order approximation is just to think
 of it as C++. Each import search path (from dmd.conf/sc.ini or the -I
 command line switches, plus the working directory) is treated as
 possible root, and similar to »#include <foo/bar.h>«, »import foo.bar;«
 looks for a foo/bar.d file in any of the import directories.


That's what I did.

I've now additionally added the file to the Visual Studio project, and 
that worked.



 So, if you really want to extend druntime's core package (which you
 normally don't, unless you plan on submitting your additions back
 upstream), you would put your generated unicode_api.d in a
 core/sys/windows directory under one of the import search paths.


OK. So, since I don't know anything about how to "submit additions back 
upstream", I just enclose it here.

Could the right "upstream" person please grab hold of this and Do What 
Needs To Be Done(TM)?

I'm assuming that the need for this module or a module like this, is 
obvious with hindsight (given its existence now). Also, that the ease of 
accessing the OS API on the most common platform, impacts on the usage 
share of D. I'll be happy to explain further if desired.


Cheers, hth., & TIA.,

- Alf
Feb 13 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/13/2012 6:15 AM, Alf P. Steinbach wrote:

 Are there group charters?


Not much beyond the descriptions here:

   http://digitalmars.com/NewsGroup.html

We're pretty informal.


 As a newbie one tries things and asks about things that a person more
accustomed
 to The Usual Ways(TM) just discounts immediately without further reflection --
 missing out on the opportunities...


That's true, we often do not see things the way a new user would.


 OK. So, since I don't know anything about how to "submit additions back
 upstream", I just enclose it here.


The most effective way to contribute code is to fork/pull on github for the 
following project:

   https://github.com/D-Programming-Language

Bug reports go here:

   http://d.puremagic.com/issues/

The trouble with newsgroup postings of code is as time goes by, the posting 
scrolls off the radar.
Feb 13 2012
parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Monday, 13 February 2012 at 19:27:39 UTC, Walter Bright wrote:

 On 2/13/2012 6:15 AM, Alf P. Steinbach wrote:

 Are there group charters?


 Not much beyond the descriptions here:

  http://digitalmars.com/NewsGroup.html

 We're pretty informal.


I read that last word as 'normal' and was about to make an 
objection. :P
Feb 13 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 February 2012 12:13, Alf P. Steinbach
<alf.p.steinbach+usenet gmail.com> wrote:

 On 13.02.2012 12:48, James Miller wrote:

 Somewhat off topic, but Alf, I have noticed you posting a few times,



 Uhm, 2 times.


Right, not a few, but a couple. ;-)



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Feb 13 2012
prev sibling parent reply "Alf P. Steinbach" <alf.p.steinbach+usenet gmail.com> writes:
On 13.02.2012 10:33, Walter Bright wrote:

 On 2/12/2012 11:45 PM, Alf P. Steinbach wrote:

 Anyway, I haven't yet started delving into the language documentation
 or any
 tutorials, just used gut-feeling, so I'd appreciate discussion of how
 to make
 this my first D console program less non-idiomatic <g>:


 <code>
 import std.stdio;
 import std.ascii;
 import std.string; // chop

 //import core.sys.windows.unicode_based_api; <-- DOES NOT WORK.


 There is no D import with the name unicode_based_api. Where does that
 name come from?


It's the name of the module generated by the program, just more clean 
aliases for the Unicode based Windows API functions  --  e.g., in C++ 
one would write `MessageBox`, not `MessageBoxW`, so I alias them.

By the way, I see that the list of functions provided by 
core.sys.windows.windows is rather short, covering a very small fraction 
of the API:

How would one go about extending that?



 For a console app that just reads and writes files, there shouldn't be a
 need to access the Windows API at all. The D runtime library does that
 for you.


Oh, you'd be surprised.

The Windows console is a pretty dirty thing, especially wrt. Unicode for 
the standard streams, so considering that Microsoft's own Visual C++ 
runtime doesn't get it right I doubt that the D runtime does. Yet. :-)

Anyway, testing the generated module involves first of all getting it to 
work as a module. I do not yet have the foggiest idea about how D 
building works, except compiling individual source files. I just thought 
it doesn't matter which program it's used from then, so I put the 
`import` in the generating program.


Cheers &

- Alf
Feb 13 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/13/12, Alf P. Steinbach <alf.p.steinbach+usenet gmail.com> wrote:

 By the way, I see that the list of functions provided by
 core.sys.windows.windows is rather short, covering a very small fraction
 of the API:

 How would one go about extending that?


http://dsource.org/projects/bindings/wiki/WindowsApi

Windows samples which use that library can be found here:
https://github.com/AndrejMitrovic/DWinProgramming
Feb 13 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/13/2012 4:32 AM, Alf P. Steinbach wrote:

 It's the name of the module generated by the program, just more clean aliases
 for the Unicode based Windows API functions -- e.g., in C++ one would write
 `MessageBox`, not `MessageBoxW`, so I alias them.


The Windows .h files are set up so that MessageBox is a macro that resolves to 
MessageBoxW or MessageBoxA depending on another macro setting. I've never liked 
that practice - preferring to call the desired function explicitly (whether
that 
is dirty or clean is not of much import, it is what it is as Microsoft saw fit 
to name it).
Feb 13 2012
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
Hi,

On 13.02.2012 08:45, Alf P. Steinbach wrote:

 I first started with a Windows message box program and installing an
 IDE. I'm now using the VisualD plug-in with the Visual Studio 10 Shell,
 after battling a bit with installation of service pack 1 for Visual
 Studio. VisualD works, sort of, except the devs forgot that the resource
 compiler needs an INCLUDE variable so that it finds <windows.h>, so,
 silly as it is, the VisualD plugin can't be used directly as-is to
 create a modern look and feel Windows program. I solved it by running
 Visual Studio from the command line.


There is the global option "Resource includes" in 
Tools->Options->Projects and Solutions->Visual D Directories.

Rainer
Feb 13 2012
parent "Alf P. Steinbach" <alf.p.steinbach+usenet gmail.com> writes:
On 13.02.2012 19:52, Rainer Schuetze wrote:

 Hi,

 On 13.02.2012 08:45, Alf P. Steinbach wrote:

 I first started with a Windows message box program and installing an
 IDE. I'm now using the VisualD plug-in with the Visual Studio 10 Shell,
 after battling a bit with installation of service pack 1 for Visual
 Studio. VisualD works, sort of, except the devs forgot that the resource
 compiler needs an INCLUDE variable so that it finds <windows.h>, so,
 silly as it is, the VisualD plugin can't be used directly as-is to
 create a modern look and feel Windows program. I solved it by running
 Visual Studio from the command line.


 There is the global option "Resource includes" in
 Tools->Options->Projects and Solutions->Visual D Directories.


Thanks. Checking it out now, I found it, and it was set to

   $(WindowsSdkDir)\include;$(DevEnvDir)..\..\VC\include

where WindowsSdkDir is an environment variable that isn't defined by the 
SDK installation (so isn't present with normal start of Visual Studio), 
but is set by the common environment fix batch file.

However, adding the raw SDK include path to that option did not work, 
while running Visual Studio Shell from the command line (with the 
environment variables set properly) does work.

Cheers,

- Alf
Feb 13 2012