September 17, 2004 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to pragma | 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 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Helmut Leitner | 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 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to J C Calvarese | 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 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Friesen | 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 Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mark T | 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 Win32 was Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Helmut Leitner | 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 Re: Win32 was Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mark T | 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 Re: Win32 was Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mark T | 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 Re: Win32 was Re: Most important issues for D (MIID) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Helmut Leitner | 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. |
Copyright © 1999-2021 by the D Language Foundation