February 13, 2012
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
February 13, 2012
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
February 13, 2012
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/src/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.


February 13, 2012
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.
February 13, 2012
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
February 13, 2012
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


February 13, 2012
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
February 13, 2012
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
February 13, 2012
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


February 13, 2012
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';
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home