September 17, 2004
pragma wrote:

>>Ummm... would've forgotten. Fixing typeinfos is crucial for D 1.0
> 
> 
> I'll second that.  Especially having full class reflection (methods, members,
> ctors, etc) as a part of typeinfo would be most appreciated.

Same here, but for me it is not a showstopper for 1.0. I could wait until shortly after that ;-) I think support for shared libraries and good debugging info under Linux is more important. What I am actually hoping for is for gdc to catch up...

Bastiaan.
September 17, 2004
And, of course:

   std.c.windows.windows.d

should go from about 10% to at least 95% coverage of the Win32 API.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com
September 17, 2004
Helmut Leitner wrote:
> And, of course:
> 
>    std.c.windows.windows.d
> 
> should go from about 10% to at least 95% coverage of the Win32 API.

All in the same file? ;)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
September 17, 2004

J C Calvarese wrote:
> 
> Helmut Leitner wrote:
> > And, of course:
> >
> >    std.c.windows.windows.d
> >
> > should go from about 10% to at least 95% coverage of the Win32 API.
> 
> All in the same file? ;)
> 

Not necessarily.

But the original API header files are monolithic, so one would have to invent a modularization which will be not intuitive to Win32 users (you can't derive a hint to it from the 5 volume Win32 API reference)

There are still collision problems if a module includes
      windows.d from Phobos   AND
      windows.d from Pavel    (needed for additional functions)

=======================================================
*  identically defined external C functions           *
*  identically defined C structs                      *
*  identically defined C constants and enums          *
*  should not create collisions                       *
=======================================================

If this is not solved, one must ensure that there are
absolutely no intersections of external API declarations
if you include more than one API interface module in one
of your sources.

But this is almost impossible, because you notice the
collision only if you actually use an item. So it may
bite you any time.

The Win32 API is vast, it is impossible to wrap it (and Walter doesn't promote wrapper functions anyway).

It would be impossible to expect programmers
 - to write the external function declarations they need on demand   or
 - copy & paste them from a repository on demand

There must be a foolproof way to access the Win32 API.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com
September 17, 2004
In article <ci01kt$8gj$1@digitaldaemon.com>, Andy Friesen says...
>
>> GUI debugger
>The thing is, neither of these issues are in Walter's hands. :)
>
>Walter is the only one who can make improvements to the compiler itself, so it stands to reason that it be his primary focus.  The auxiliary code monkeys (that's us!) can handle most everything else.

Totally agree, these are just "marketing" issues not language/library issues why bother Walter with this stuff



September 17, 2004
In article <ciep4v$1c1t$1@digitaldaemon.com>, Mark T says...
>
>In article <ci01kt$8gj$1@digitaldaemon.com>, Andy Friesen says...
>>
>>> GUI debugger
>>The thing is, neither of these issues are in Walter's hands. :)
>>
>>Walter is the only one who can make improvements to the compiler itself, so it stands to reason that it be his primary focus.  The auxiliary code monkeys (that's us!) can handle most everything else.
>
>Totally agree, these are just "marketing" issues not language/library issues why bother Walter with this stuff


The debugger issue /IS/ in Walter's hands. It's a compiler problem, and Walter is the only one who can fix it.

Nobody is suggesting that Walter write an IDE. Fact is, there are plenty of existing IDEs around that work fine. I use MS Visual Studio, for example, and this debugger is pretty damn good. I don't have any complaints about it. However, it can't (for instance) step into D template code without getting lost. The reason for this is nothing to do with MS Visual Studio. If I have understood this correctly, the fault lies with the DMD compiler, for failing to insert sufficient debugging code into the executable. That is why we must bother Walter with this stuff.

Arcane Jill


September 17, 2004
In article <414A7C9E.543F83BF@wikiservice.at>, Helmut Leitner says...
>
>And, of course:
>
>   std.c.windows.windows.d
>
>should go from about 10% to at least 95% coverage of the Win32 API.

Why should the standard language have a complete map to the Win32 API? This should really be in its own module.

Maybe a separate win32.d module could contain the complete API. If Billy G has his way Win32 will become obsolete anyways.


September 17, 2004
In article <cies8m$1iqg$1@digitaldaemon.com>, Mark T says...
>
>Maybe a separate win32.d module could contain the complete API. If Billy G has his way Win32 will become obsolete anyways.

As well the .NET windowing API.  Sometimes it seems MS deprecates stuff before it's even shipped ;)


Sean


September 17, 2004

Mark T wrote:
> 
> In article <414A7C9E.543F83BF@wikiservice.at>, Helmut Leitner says...
> >
> >And, of course:
> >
> >   std.c.windows.windows.d
> >
> >should go from about 10% to at least 95% coverage of the Win32 API.
> 
> Why should the standard language have a complete map to the Win32 API? This should really be in its own module.

   (1) because you get thousands of collission problems otherwise
   (2) D will never be a success if it doesn't support Windows out of the box

> Maybe a separate win32.d module could contain the complete API.

   collission problems.

> If Billy G has his way Win32 will become obsolete anyways.

   It won't, for
     (1) it's at the basis of so many application
     (2) the .NET -> Win32 Interface is just as broken and
         slow as the Java native code interface to Windows

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com
September 17, 2004
Helmut Leitner wrote:
> 
> Mark T wrote:
> 
>>In article <414A7C9E.543F83BF@wikiservice.at>, Helmut Leitner says...
>>
>>>And, of course:
>>>
>>>  std.c.windows.windows.d
>>>
>>>should go from about 10% to at least 95% coverage of the Win32 API.
>>
>>Why should the standard language have a complete map to the Win32 API?
>>This should really be in its own module.
> 
> 
>    (1) because you get thousands of collission problems otherwise

?? Huh?  A little more detail please?

>    (2) D will never be a success if it doesn't support Windows out of the box

I suppose there is noone using other operating systems out there
then?  How much of a success does D have to be before it is good to
write software in?

You can support windows without mapping the whole win32 API.  I don't
know about you, but I found writing MFC code bad enough--whenever I even
attempted to look at win32 code it gave me a headache.  As long as there
is a windowing/gui toolkit (several are under development), and standard
libraries to do your I/O work then those libraries can map to whatever
API is available.  The bottom line is to start reasonably then build on
that.  The entire win32 API is quite large and it covers everything from
windowing to threads to socket IO to file IO to driver communications.
Not to mention the hacked POSIX half-support.  Do you really want to
bloat the D API with all that nastiness?

>>Maybe a separate win32.d module could contain the complete API. 
> 
> 
>    collission problems.

Info?  Supporting information would help.  WHat do you mean
"collision problems"?


>>If Billy G has his way Win32 will become obsolete anyways.
> 
> 
>    It won't, for      (1) it's at the basis of so many application
>      (2) the .NET -> Win32 Interface is just as broken and
>          slow as the Java native code interface to Windows

You lost me.  Yes, the first argument is the only one that makes
sense here.  They would be quite foolish to simply remove it and
render the current investment in software null and void.  MS would
lose their shirt because noone would want to upgrade.

When you say Win32 API just what part are you talking about?
If you are merely limiting it to the GUI related API then I would
agree that the Java API (built in and for Java) is slower than
many C++ programs, but if you know how to work with it instead of
against it, then it is fast enough.

Don't be in such tunnel vision to assume that the world is Windows.
To tell the truth, there is a lot of potential for D outside the
world of Windows--if the debugging information can get straightened
out.  If it's a pain to find what's wrong in your programs then
noone will use it.