Re: tooling quality and some random rant
On 02/13/2011 07:52 AM, Nick Sabalausky wrote:
- Option description text seems to be left aligned, yet there are 3
exceptions
It all looks left-aligned to me, but I'm using the Win version. Maybe it's
different for OSX. Seems weird that it would be though.
Maybe you did not watch properly, or indeed the win version output differently.
On linux, I get:
spir@d:~$ dmd --help
Digital Mars D Compiler v2.051
Copyright (c) 1999-2010 by Digital Mars written by Walter Bright
Documentation: http://www.digitalmars.com/d/2.0/index.html
Usage:
dmd files.d ... { -switch }
files.dD source files
@cmdfile read arguments from cmdfile
-c do not link
-cov do code coverage analysis
...
-debug=ident compile in debug code identified by ident
-debuglib=nameset symbolic debug library to name
-defaultlib=name set default library to name
-deps=filename write module dependencies to filename
...
-release compile release version
-run srcfile args... run resulting program, passing args
-unittest compile in unit tests
...
Sure, very minor bug. But still... presentation counts.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: inlining or not inlining...
Ok i stop, looks like i fail to make my point to anyone :)
Re: tooling quality and some random rant
On Sun, 13 Feb 2011 08:00:57 +0200, golgeliyele usul...@gmail.com wrote: The error reporting has issues as well. I noticed that the compiler leaks low level errors to the user. If you forget to add a main to your app or misspell it, you get errors like: Undefined symbols: __Dmain, referenced from: _D2rt6dmain24mainUiPPaZi7runMainMFZv in libphobos2.a(dmain2_513_1a5.o) I mean, wow, this should really be handled better. This has been brought up before. Walter insists it's not a problem. Another annoyance, for me anyway, is that the DMD compiler outputs the .o files without the package directory hierarchy. I like to organize my code as 'src/my/package/module.d'. And I want to set my output directory to 'lib' and get 'lib/my/package/module.o'. But DMD generates 'lib/module.o'. I setup my project to build each .d file into a .o file as a separate step. I don't even know if this is the desired setup. But that seems to be the way to make it incremental. I couldn't find any definitive information on this in the DMD compiler web page. It says: dmd can build an executable much faster if as many of the source files as possible are put on the command line. Correctly-working incremental builds are not possible with DMD. This is an old problem that isn't easy to fix, due to the way the compiler was designed and written. Another advantage to putting multiple source files on the same invocation of dmd is that dmd will be able to do some level of cross- module optimizations, such as function inlining across modules. I've been told that DMD will actually do cross-module optimizations even if you don't specify the other modules on its command-line. Unless you use .di files, the point is that unlike C++, the compiler has access to the full source code of all included modules, not just a header file, so it can do inlining and whatnot. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Stupid little iota of an idea
Andrei Alexandrescu Wrote: On 2/11/11 7:07 AM, foobar wrote: Andrei Alexandrescu Wrote: I don't find the name iota stupid. Andrei Of course _you_ don't. However practically all the users _do_ find it poorly named, including other developers in the project.. This is the umpteenth time this comes up in the NG and incidentally this is the only reason I know what the function does. If the users think the name is stupid than it really is. That's how usability works and the fact the you think otherwise or that it might be more accurate mathematically is really not relevant. If you want D/Phobos to be used by other people besides yourself you need to cater for their requirements. Not all users dislike iota, and besides arguments ad populum are fallacious. Iota rocks. But have at it - vote away, and I'll be glad if a better name for iota comes about. Andrei Usability seems to be Achilles' heel of D and is a recurrent theme on the NG. Usability cannot be mathematically deduced even though you seem to try hard to do just that. This reminds me the story of a Google designer that quit the company, being frustrated by the engineering mind-set of the company. He gave many amusing examples of a complete lack of understanding of design principals such as choosing the shade of blue by doing a scientific comparison of a thousand different shades. could we for once put aside otherwise valid implementation concerns such as efficiency and mathematical correctness and treat usability as valid important concern? Could we for once accept that The users' opinion is not fallacious and have a user oriented design is not a bad thing or are we implementing for the sake of boosting ones own ego and nothing else?
Re: tooling quality and some random rant
On 13/02/11 6:52 AM, Nick Sabalausky wrote: D compiles a few orders of magnitude faster than C++ does. Better handling of incremental building might be nice for really large projects, but it's really not a big issue for D, not like it is for C++. The only person I know that's worked on large D projects is Tomasz, and he claimed that he was getting faster compile times in C++ due to being able to do incremental builds. Walter might claim that DMD is fast, but it’s not exactly blazing when you confront it with a few hundred thousand lines of code. With C/C++, you’d split your source into .c and .h files, which mean that a localized change of a .c file only requires the compilation of a single unit. Take an incremental linker as well, and C++ compiles faster than D. With D you often have the situation of having to recompile everything upon the slightest change. (http://h3.gd/devlog/?p=22)
Re: tooling quality and some random rant
On 13/02/11 10:10 AM, Peter Alexander wrote: On 13/02/11 6:52 AM, Nick Sabalausky wrote: D compiles a few orders of magnitude faster than C++ does. Better handling of incremental building might be nice for really large projects, but it's really not a big issue for D, not like it is for C++. The only person I know that's worked on large D projects is Tomasz, and he claimed that he was getting faster compile times in C++ due to being able to do incremental builds. Walter might claim that DMD is fast, but it’s not exactly blazing when you confront it with a few hundred thousand lines of code. With C/C++, you’d split your source into .c and .h files, which mean that a localized change of a .c file only requires the compilation of a single unit. Take an incremental linker as well, and C++ compiles faster than D. With D you often have the situation of having to recompile everything upon the slightest change. (http://h3.gd/devlog/?p=22) Turns out this may have been solved: https://bitbucket.org/h3r3tic/xfbuild/wiki/Home
Re: tooling quality and some random rant
Peter Alexander wrote: On 13/02/11 6:52 AM, Nick Sabalausky wrote: D compiles a few orders of magnitude faster than C++ does. Better handling of incremental building might be nice for really large projects, but it's really not a big issue for D, not like it is for C++. The only person I know that's worked on large D projects is Tomasz, and he claimed that he was getting faster compile times in C++ due to being able to do incremental builds. Walter might claim that DMD is fast, but it’s not exactly blazing when you confront it with a few hundred thousand lines of code. With C/C++, you’d split your source into .c and .h files, which mean that a localized change of a .c file only requires the compilation of a single unit. Take an incremental linker as well, and C++ compiles faster than D. With D you often have the situation of having to recompile everything upon the slightest change. (http://h3.gd/devlog/?p=22) You can do the same in D using .di files.
Re: tooling quality and some random rant
Vladimir Panteleev wrote: On Sun, 13 Feb 2011 08:00:57 +0200, golgeliyele usul...@gmail.com wrote: The error reporting has issues as well. I noticed that the compiler leaks low level errors to the user. If you forget to add a main to your app or misspell it, you get errors like: Undefined symbols: __Dmain, referenced from: _D2rt6dmain24mainUiPPaZi7runMainMFZv in libphobos2.a(dmain2_513_1a5.o) I mean, wow, this should really be handled better. This has been brought up before. Walter insists it's not a problem. In C++, you get essentially the same thing from g++: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status
Re: tooling quality and some random rant
golgeliyele usul...@gmail.com wrote:
- Option description text seems to be left aligned, yet there are 3 exceptions
It's easier to visually associate the command with the description if they are
fairly close. Some (i.e. 3) are too long for that. It's a compromise, but I
don't see a horrendous problem:
H:\cbx\marsdmd
Digital Mars D Compiler v2.052
Copyright (c) 1999-2010 by Digital Mars written by Walter Bright
Documentation: http://www.digitalmars.com/d/2.0/index.html
Usage:
dmd files.d ... { -switch }
files.dD source files
@cmdfile read arguments from cmdfile
-c do not link
-cov do code coverage analysis
-D generate documentation
-Dddocdir write documentation file to docdir directory
-Dffilenamewrite documentation file to filename
-d allow deprecated features
-debug compile in debug code
-debug=level compile in debug code = level
-debug=ident compile in debug code identified by ident
-debuglib=nameset symbolic debug library to name
-defaultlib=name set default library to name
-deps=filename write module dependencies to filename
-g add symbolic debug info
-gcadd symbolic debug info, pretend to be C
-H generate 'header' file
-Hddirectory write 'header' file to directory
-Hffilenamewrite 'header' file to filename
--help print help
-Ipath where to look for imports
-ignoreignore unsupported pragmas
-inlinedo function inlining
-Jpath where to look for string imports
-Llinkerflag pass linkerflag to link
-lib generate library rather than object files
-man open web browser on manual page
-map generate linker .map file
-noboundscheck turns off array bounds checking for all functions
-nofloat do not emit reference to floating point
-O optimize
-o-do not write object file
-odobjdir write object library files to directory objdir
-offilenamename output file to filename
-opdo not strip paths from source file
-profile profile runtime performance of generated code
-quiet suppress unnecessary messages
-release compile release version
-run srcfile args... run resulting program, passing args
-unittest compile in unit tests
-v verbose
-version=level compile in version code = level
-version=ident compile in version code identified by ident
-vtls list all variables going into thread local storage
-w enable warnings
-wienable informational warnings
-X generate JSON file
-Xffilenamewrite JSON file to filename
Re: Stupid little iota of an idea
foobar wrote: Andrei Alexandrescu Wrote: On 2/11/11 7:07 AM, foobar wrote: Andrei Alexandrescu Wrote: I don't find the name iota stupid. Andrei Of course _you_ don't. However practically all the users _do_ find it poorly named, including other developers in the project.. This is the umpteenth time this comes up in the NG and incidentally this is the only reason I know what the function does. If the users think the name is stupid than it really is. That's how usability works and the fact the you think otherwise or that it might be more accurate mathematically is really not relevant. If you want D/Phobos to be used by other people besides yourself you need to cater for their requirements. Not all users dislike iota, and besides arguments ad populum are fallacious. Iota rocks. But have at it - vote away, and I'll be glad if a better name for iota comes about. Andrei Usability seems to be Achilles' heel of D and is a recurrent theme on the NG. Usability cannot be mathematically deduced even though you seem to try hard to do just that. This reminds me the story of a Google designer that quit the company, being frustrated by the engineering mind-set of the company. He gave many amusing examples of a complete lack of understanding of design principals such as choosing the shade of blue by doing a scientific comparison of a thousand different shades. could we for once put aside otherwise valid implementation concerns such as efficiency and mathematical correctness and treat usability as valid important concern? Could we for once accept that The users' opinion is not fallacious and have a user oriented design is not a bad thing or are we implementing for the sake of boosting ones own ego and nothing else? first rule of usability: don't listen to users http://www.useit.com/alertbox/20010805.html
Re: tooling quality and some random rant
On 2011-02-13 07:52, Nick Sabalausky wrote: golgeliyeleusul...@gmail.com wrote in message The error reporting has issues as well. I noticed that the compiler leaks low level errors to the user. If you forget to add a main to your app or misspell it, you get errors like: Undefined symbols: __Dmain, referenced from: _D2rt6dmain24mainUiPPaZi7runMainMFZv in libphobos2.a(dmain2_513_1a5.o) I mean, wow, this should really be handled better. That's not the compiler, that's the linker. I don't know what linker DMD uses on OSX, but on Windows it uses OPTLINK which is written in hand-optimized Asm so it's really hard to change. But Walter's been converting it to C (and maybe then to D once that's done) bit-by-bit (so to speak), so linker improvements are at least on the horizon. AIUI, on Linux, DMD just uses the GCC linker, and GCC unfortunately doesn't know anything about D name mangling, just C/C++. Might be true of OSX as well, I don't know though. As you know, on Windows DMD uses OPTLINK and on all other platforms GCC is used. -- /Jacob Carlborg
Re: tooling quality and some random rant
On 2011-02-13 01:00:57 -0500, golgeliyele usul...@gmail.com said: IMO, despite all the innovations the D project brings, the lack of pretty packaging and presentation is hurting it. I have observed changes for the better lately. Such as the TDPL book, the github move, the new web page (honestly, the digitalmars page was and still is a liability for D), and may be a new web forum interface(?). Since you're on a Mac, perhaps you'd be interested in D for Xcode (which I maintain). It abstracts away many of these complexities. http://michelf.com/projects/d-for-xcode/ -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: tooling quality and some random rant
Nick Sabalausky a@a.a wrote in message news:ij7v76$1q4t$1...@digitalmars.com... ... (cutted) ... That's not the compiler, that's the linker. I don't know what linker DMD uses on OSX, but on Windows it uses OPTLINK which is written in hand-optimized Asm so it's really hard to change. But Walter's been converting it to C (and maybe then to D once that's done) bit-by-bit (so to speak), so linker improvements are at least on the horizon. ... Why C and not directly D? It is really bad adversting for D to know that when its creator came around to rewrite the linker, Walter decided to use C instead of D. -- Paulo
Re: tooling quality and some random rant
Paulo Pinto pj...@progtools.org wrote in message news:ij8he9$2v0o$1...@digitalmars.com... Nick Sabalausky a@a.a wrote in message news:ij7v76$1q4t$1...@digitalmars.com... ... (cutted) ... That's not the compiler, that's the linker. I don't know what linker DMD uses on OSX, but on Windows it uses OPTLINK which is written in hand-optimized Asm so it's really hard to change. But Walter's been converting it to C (and maybe then to D once that's done) bit-by-bit (so to speak), so linker improvements are at least on the horizon. ... Why C and not directly D? It is really bad adversting for D to know that when its creator came around to rewrite the linker, Walter decided to use C instead of D. That's jumping to conclusions. C is little more than a high-level assembler. That's why it's a reasonable first step up from Asm. Once it's in C and cleaned up, that's the time for it to move on to D .
Re: Stupid little iota of an idea
Lutger Blijdestijn Wrote: first rule of usability: don't listen to users http://www.useit.com/alertbox/20010805.html I fail to see how that page ( which talks about website design ) applies to what I've said. It says that you should look at what people _do_ instead of what they _say_. How would you apply this to Phobos' naming conventions? How about this: Show a code sample using iota to users who never programmed in D and ask them what that code does.
Re: tooling quality and some random rant
Peter Alexander peter.alexander...@gmail.com wrote in message news:ij8a8p$2gqv$1...@digitalmars.com... On 13/02/11 10:10 AM, Peter Alexander wrote: On 13/02/11 6:52 AM, Nick Sabalausky wrote: D compiles a few orders of magnitude faster than C++ does. Better handling of incremental building might be nice for really large projects, but it's really not a big issue for D, not like it is for C++. The only person I know that's worked on large D projects is Tomasz, and he claimed that he was getting faster compile times in C++ due to being able to do incremental builds. Walter might claim that DMD is fast, but its not exactly blazing when you confront it with a few hundred thousand lines of code. With C/C++, youd split your source into .c and .h files, which mean that a localized change of a .c file only requires the compilation of a single unit. Take an incremental linker as well, and C++ compiles faster than D. With D you often have the situation of having to recompile everything upon the slightest change. (http://h3.gd/devlog/?p=22) Turns out this may have been solved: https://bitbucket.org/h3r3tic/xfbuild/wiki/Home The problem that xfbuild ended up running into is that DMD puts the generated code for instantiated temples into an unpredictable object file. This leads to situations where certain functions end up being lost from the object files unless you do a full rebuild. Essentialy it breaks incremental compilation. There's a detailed explanation of it somewhere on the xfbuild site.
Re: tooling quality and some random rant
Walter:
In C++, you get essentially the same thing from g++:
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: In function
`_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
Lot of people come here because they want a compiler+language better than C++
:-)
If you compile this:
void main() {
writeln(Hello world);
}
Since some time dmd shows an error fit for D newbies:
test.d(2): Error: 'writeln' is not defined, perhaps you need to import
std.stdio; ?
Probably many Python/JS/Perl/PHP/etc programmers that may want to try D don't
know what a linker is. When they want to develop a large multi-module D program
they must know something about how a linker works. But D has to scale down to
smaller programs too, where there are only one or very few modules, written by
not experts of C-class languages. In this situation more readable error
messages, produced by dmd that catches a basic error before the linker, is
probably useful.
Bye,
bearophile
Re: Stupid little iota of an idea
On 2/13/11 3:15 AM, foobar wrote: Andrei Alexandrescu Wrote: On 2/11/11 7:07 AM, foobar wrote: Andrei Alexandrescu Wrote: I don't find the name iota stupid. Andrei Of course _you_ don't. However practically all the users _do_ find it poorly named, including other developers in the project.. This is the umpteenth time this comes up in the NG and incidentally this is the only reason I know what the function does. If the users think the name is stupid than it really is. That's how usability works and the fact the you think otherwise or that it might be more accurate mathematically is really not relevant. If you want D/Phobos to be used by other people besides yourself you need to cater for their requirements. Not all users dislike iota, and besides arguments ad populum are fallacious. Iota rocks. But have at it - vote away, and I'll be glad if a better name for iota comes about. Andrei Usability seems to be Achilles' heel of D and is a recurrent theme on the NG. Usability cannot be mathematically deduced even though you seem to try hard to do just that. I think it would be a bit of an exaggeration to characterize the choice of name iota as an impediment to usability. I'd agree if it were an endemic problem, but generally I think the choice of names in Phobos is adequate. This reminds me the story of a Google designer that quit the company, being frustrated by the engineering mind-set of the company. He gave many amusing examples of a complete lack of understanding of design principals such as choosing the shade of blue by doing a scientific comparison of a thousand different shades. Principles!!! Principles!!! I hate that typo. could we for once put aside otherwise valid implementation concerns such as efficiency and mathematical correctness and treat usability as valid important concern? Could we for once accept that The users' opinion is not fallacious and have a user oriented design is not a bad thing or are we implementing for the sake of boosting ones own ego and nothing else? I've already mentioned: I'm ready to change this name and others if consensus comes about. Generally efficiency and mathematical correctness don't clash badly with choice of names, so probably you're referring to something beyond that - just let us know. Andrei
Re: tooling quality and some random rant
Nick Sabalausky: Paulo Pinto: Why C and not directly D? That's jumping to conclusions. C is little more than a high-level assembler. That's why it's a reasonable first step up from Asm. Once it's in C and cleaned up, that's the time for it to move on to Dù Paulo Pinto has asked a fair question. The answer is that D is not a perfect system language. If you need to write code for an Arduino (a small CPU), for 16 bit CPUs in general, if you want to convert something from asm like that linker (Walter has said that later it's easy to convert the C linker to D), and in several other situations, C language is better. Programs compiled with the a C compiler are generally smaller than the one compiled with DMD, there are simple ways to produce binaries of 4000 bytes with C. This is not a failure of D, D is designed for larger 32 bit CPUs, for systems that have a heap memory (in D there are ways to avoid heap allocations and to remove the GC, but doing it in C is more natural. I don't know how produce DMD binaries with DMD that don't use the GCC and don't include it, this problem is missing in C). Bye, bearophile
Re: tooling quality and some random rant
On 2/13/11 6:59 AM, bearophile wrote: Walter: In C++, you get essentially the same thing from g++: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status Lot of people come here because they want a compiler+language better than C++ :-) In many ways D looks and feels like a newer language, so I agree that probably we shouldn't use C++ as a yardstick here. It would be a cop out to be relaxed about something because C++ has it too. Andrei
Re: tooling quality and some random rant
Hi, I am sorry, but I don't belive it. Many other systems programming languages that atempted to displace C and C++, have the toolchain built in its languages, after the compilers were bootstrapped, as anyone with enough compiler knowledge will surely tell you. And D's linker must first be written in C, to make it easy to rewrite in D?! A linker is not science fiction, it is just a program that binds object files and libraries together to produce an executable. Any programming language able to manipulate files and binary data, can be used to create a linker. -- Paulo Nick Sabalausky a@a.a wrote in message news:ij8iau$30jr$1...@digitalmars.com... Paulo Pinto pj...@progtools.org wrote in message news:ij8he9$2v0o$1...@digitalmars.com... Nick Sabalausky a@a.a wrote in message news:ij7v76$1q4t$1...@digitalmars.com... ... (cutted) ... That's not the compiler, that's the linker. I don't know what linker DMD uses on OSX, but on Windows it uses OPTLINK which is written in hand-optimized Asm so it's really hard to change. But Walter's been converting it to C (and maybe then to D once that's done) bit-by-bit (so to speak), so linker improvements are at least on the horizon. ... Why C and not directly D? It is really bad adversting for D to know that when its creator came around to rewrite the linker, Walter decided to use C instead of D. That's jumping to conclusions. C is little more than a high-level assembler. That's why it's a reasonable first step up from Asm. Once it's in C and cleaned up, that's the time for it to move on to D .
Re: Stupid little iota of an idea
Sun, 13 Feb 2011 08:32:31 +0200, so wrote: 1. and .1 are very minor improvements mainly for the laziest developers out there. It's getting harder and harder to get rid of them. Avoiding these kind of conflicts between core language features should be priority #1. For lazy developers? i don't think so, how lazy one can get anyways, after all we are not typists. We most of the time think (i can't be the judge here actually), rarely type. I would love to see the reasoning on this one, and how successfully made it into most if not all languages. Sometimes i think designers make this kind of decisions for their depressive times. In those times they remember this and laugh how they fooled the whole world. Might be :-D
Re: tooling quality and some random rant
On 13/02/11 13:36, Paulo Pinto wrote: Hi, I am sorry, but I don't belive it. Many other systems programming languages that atempted to displace C and C++, have the toolchain built in its languages, after the compilers were bootstrapped, as anyone with enough compiler knowledge will surely tell you. And D's linker must first be written in C, to make it easy to rewrite in D?! A linker is not science fiction, it is just a program that binds object files and libraries together to produce an executable. Any programming language able to manipulate files and binary data, can be used to create a linker. -- Paulo I believe the issue is that OPTLINK is written in highly optimised hand-written assembly, and as such a direct port to D is impossible. As the linker is such a delicate tool (even a minor change can have major repucussions), the port needs to be as direct as possible - sure, it could be ported directly to D, but it will more than likely break in the process. See also http://www.drdobbs.com/blog/archives/2009/11/assembler_to_c.html -- Robert http://octarineparrot.com/
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Changing the object module format is not sufficient. The symbolic debug info would have to be changed (and Microsoft's is undocumented) and then there's the dependency on Microsoft's C runtime library if linking with VC generated object files. I found some doc there: http://pierrelib.pagesperso-orange.fr/exec_formats/index.html Microsoft Symbol and Type Information By TIS / Microsoft. Entry added 12/28/2004. Keywords: ms, symbol, type, info File: MS_Symbol_Type_v1.0.pdf « This document describes Microsoft Symbol and Type Information, a debugging information format fromMicrosoft Corporation for the 32-bit Windows environment. » There is also some doc on the MSDN CD that comes with Visual C++ 6.0.
WALK32 - An open source omf linker
I found this: SBS WALK32 Win32 Assembly Language Kit Version 1.00 there: http://www.programmersheaven.com/download/355/download.aspx The file WALK32_1.zip contains the source code (in asm) of a 32 bits OMF linker. May be it can help...
Re: tooling quality and some random rant
Paulo Pinto Wrote: Nick Sabalausky a@a.a wrote in message news:ij7v76$1q4t$1...@digitalmars.com... ... (cutted) ... That's not the compiler, that's the linker. I don't know what linker DMD uses on OSX, but on Windows it uses OPTLINK which is written in hand-optimized Asm so it's really hard to change. But Walter's been converting it to C (and maybe then to D once that's done) bit-by-bit (so to speak), so linker improvements are at least on the horizon. ... Why C and not directly D? It is really bad adversting for D to know that when its creator came around to rewrite the linker, Walter decided to use C instead of D. I'm guessing that Walter feels more familiar and comfortable developing C/C++ instead of D. He's the creator of D, but has written very small amounts of D and probably cannot write idiomatic D very fluently. Another issue is the immature toolchain. This might sound like blasphemy, but I believe the skills and knowledge for developing large scale applications in language XYZ cannot be extrapolated from small code snippets or from experience with projects in other languages. You just need to eat your own dogfood and get your feet wet by doing. People like the Tango's 'kris' and this 'h3r3tic' are the real world D experts. Sadly they've all left D. We need a new generation of experts, because these old guys ranting about every issue are more harmful than good to the community.
Re: tooling quality and some random rant
I guess if you're not writing new templates in your code then incremental compilation is possible? I did collect some information on using DMD here (it's a bit Windows-specific but my guess is it works similar on OSX): http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/CompilingLinkingD If anyone has additions or found erroneous statements I'd invite you to add fix those, please. It's a wiki, after all. :)
Re: tooling quality and some random rant
Paulo Pinto Wrote: Hi, I am sorry, but I don't belive it. Many other systems programming languages that atempted to displace C and C++, have the toolchain built in its languages, after the compilers were bootstrapped, as anyone with enough compiler knowledge will surely tell you. And D's linker must first be written in C, to make it easy to rewrite in D?! A linker is not science fiction, it is just a program that binds object files and libraries together to produce an executable. Any programming language able to manipulate files and binary data, can be used to create a linker. If you want, you can prove this by starting a competive linker project. Probably both Digitalmars and Microsoft have done everything they can to make competition as hard as possible by leaving the object file format undocumented and filled the implementation with weird corner cases to make reverse engineering extremely hard. Microsoft even does minor changes in every version to break compatibility. Even if a 10 man team uses some open source linker as a base and writes the linker in D, you can't beat Walter. The productivity of hardcore domain experts is nearly two orders of magnitude better than that of novices. The toolchain issues will be history by the end of this year. - G.W.
Re: tooling quality and some random rant
Andrej Mitrovic Wrote: I guess if you're not writing new templates in your code then incremental compilation is possible? Exactly. What I did is a simple wrapper module for Phobos with preinstantiated non-templated functions for typical use cases. For example there are few wrappers for the templated collection functions. It's easy to grep for '!' in your code and rewrite it using these wrappers. Problem solved. - G.W.
Re: tooling quality and some random rant
I don't think C++ and gcc set a good bar here.
Re: tooling quality and some random rant
On 2/13/11, Gary Whatmore n...@spam.sp wrote:
Andrej Mitrovic Wrote:
I guess if you're not writing new templates in your code then
incremental compilation is possible?
Exactly. What I did is a simple wrapper module for Phobos with
preinstantiated non-templated functions for typical use cases. For example
there are few wrappers for the templated collection functions. It's easy to
grep for '!' in your code and rewrite it using these wrappers. Problem
solved.
- G.W.
Or one-up DMD and use a templated function in your user code that
automatically finds a pre-instantiated template by using the
import(wrappermodule.d) trick. I wonder if it would be possible to
wrap an entire module as a string (with the q{} trick) to a template
that does exactly that..
Re: Stupid little iota of an idea
Andrei Alexandrescu Wrote: On 2/13/11 3:15 AM, foobar wrote: Andrei Alexandrescu Wrote: On 2/11/11 7:07 AM, foobar wrote: Andrei Alexandrescu Wrote: I don't find the name iota stupid. Andrei Of course _you_ don't. However practically all the users _do_ find it poorly named, including other developers in the project.. This is the umpteenth time this comes up in the NG and incidentally this is the only reason I know what the function does. If the users think the name is stupid than it really is. That's how usability works and the fact the you think otherwise or that it might be more accurate mathematically is really not relevant. If you want D/Phobos to be used by other people besides yourself you need to cater for their requirements. Not all users dislike iota, and besides arguments ad populum are fallacious. Iota rocks. But have at it - vote away, and I'll be glad if a better name for iota comes about. Andrei Usability seems to be Achilles' heel of D and is a recurrent theme on the NG. Usability cannot be mathematically deduced even though you seem to try hard to do just that. I think it would be a bit of an exaggeration to characterize the choice of name iota as an impediment to usability. I'd agree if it were an endemic problem, but generally I think the choice of names in Phobos is adequate. It's not just a one time thing with one function name. There is a reoccurring pattern with function names and other such aspects and it doesn't need to be endemic in order to be looked at and improved. It's not just the naming (which I don't think is adequate), it's other things too such as the organization categorization of the code in Phobos, the web-site (already being worked on), the tool-chain could be improved, etc. I'm mostly complaining about the parts where there is little to no improvements. This reminds me the story of a Google designer that quit the company, being frustrated by the engineering mind-set of the company. He gave many amusing examples of a complete lack of understanding of design principals such as choosing the shade of blue by doing a scientific comparison of a thousand different shades. Principles!!! Principles!!! I hate that typo. Excuse me but I'm not a native English speaker and the spell check missed that. could we for once put aside otherwise valid implementation concerns such as efficiency and mathematical correctness and treat usability as valid important concern? Could we for once accept that The users' opinion is not fallacious and have a user oriented design is not a bad thing or are we implementing for the sake of boosting ones own ego and nothing else? I've already mentioned: I'm ready to change this name and others if consensus comes about. Generally efficiency and mathematical correctness don't clash badly with choice of names, so probably you're referring to something beyond that - just let us know. Andrei
alias this question
I encountered a problem with alias this, when the aliased member is
private. I'm using the latest dmd2. It reports the follwing:
src\main.d(14): Error: struct K.K member s is not accessible
If I change the private modifier on the s member to public it works.
Is this as intended, or a bug?
O.
module AliasThis;
import S;
import K;
void foo(S s)
{
//...
}
void main()
{
const K k;
foo(k);
}module S;
struct S
{
int x;
}module K;
import S;
struct K
{
S s;
public alias s this;
}
Re: tooling quality and some random rant
Hi, still you don't convice me. So what language features has C that are missing from D and prevent a linker to be written in D? The issue is not if I can beat Walter, the issue is that we have a language which on its official home page states lots of reasons for using it instead of C and C++, and its creator decides to use C when porting the linker to an high level language. So doesn't Walter belive in its own language? As for your challenge, actually I am looking for a job currently, how much can I ask for? -- Paulo Gary Whatmore n...@spam.sp wrote in message news:ij8spi$ic0$1...@digitalmars.com... Paulo Pinto Wrote: Hi, I am sorry, but I don't belive it. Many other systems programming languages that atempted to displace C and C++, have the toolchain built in its languages, after the compilers were bootstrapped, as anyone with enough compiler knowledge will surely tell you. And D's linker must first be written in C, to make it easy to rewrite in D?! A linker is not science fiction, it is just a program that binds object files and libraries together to produce an executable. Any programming language able to manipulate files and binary data, can be used to create a linker. If you want, you can prove this by starting a competive linker project. Probably both Digitalmars and Microsoft have done everything they can to make competition as hard as possible by leaving the object file format undocumented and filled the implementation with weird corner cases to make reverse engineering extremely hard. Microsoft even does minor changes in every version to break compatibility. Even if a 10 man team uses some open source linker as a base and writes the linker in D, you can't beat Walter. The productivity of hardcore domain experts is nearly two orders of magnitude better than that of novices. The toolchain issues will be history by the end of this year. - G.W.
Re: tooling quality and some random rant
You can do the same in D using .di files. Except no one really does that because such an approach is insanely error prone. E.g. with classes, you need to copy entire definitions. Change any ordering, forget a field, change a type, and you're having undefined behavior. How about eating your own dog food before making unfounded statements like that? Trivial transliterations of DMDScript or Empire don't count. So far, you've only written silly Bash-like scripts in D.
Re: tooling quality and some random rant
I wonder if we can get something positive out of this discussion. I would like to enumerate a few possibilities for the several things we discussed: 1. Difficult to understand linker errors due to missing main(): Fixing this would be useful for newbies. If there is not already a defect on this, I suggest we file a defect and it gets fixed sometime. I am assuming that this can be caught before going to the linker. Does dmd support creating an executable whose main() comes from a library? If not, the compiler would know if there is a main() or not before doing the linking. I can see how this is a problem with incremental builds though. However, with the compilation model that is being advocated by the documentation (i.e, feed dmd all the .d files at once), the compiler should know if main() is there or not. Yet another reason to clarify the compilation model, IMO. 2. dmd compiler's command line options: This is mostly an esthetic issue. However, it is like the entrance to your house. People who are not sure about entering in care about what it looks like from the outside. If Walter is willing, I can work on a command line options interface proposal that would keep backwards compatibility with the existing options. This would enable a staged transition. Would there be an interest in this? 3. Incremental compilation (or lack of it) First of all there is a documentation problem here. There needs to be clarity about whether incremental compilation is possible or not. I won't count approaches that work partially as anything more than a stopgap solution. IMO, it is acceptable if we can state that dmd compilations are blazingly fast, and as a result, there is no reason to do incremental compilation. The problem is that I get mixed signals on this point: - If this claim is true, then I think it should be asserted strongly and should be backed up by numbers (100K library compilation takes X seconds, etc.) - If this claim is false, then we should look at enhancing the tooling with things like xfBuild. Perhaps that kind of functionality can be built into the compiler itself. Whatever is needed, the following needs to be clearly documented: What is the best way to organize the build of large projects? It is a mistake to consider the language without the tooling that goes along with it. I think there is still time to recover from this error. Large projects are often build as a series of libraries. When the shared library problem is to be attacked, I think the tooling needs to be part of that design. Solving the tooling problem will raise D to one level up and I hope the community will step up to the challenge. One last thing: Personally, I don't like this business with .di files. They are optional, but then they are needed for certain use cases. I believe the information that is contained in .di files should be packed alongside the shared library and I should be able to build/link against a single library package. I haven't used Java for a long time, but I recall you get a .jar file and javadoc documentation when you are handed a library. I like that. p.s.: Does anyone know what the best way to use this newsgroup is? Is there a better web interface? If not, is there a free newsgroup (on a Mac) reader that is easy to use?
Re: tooling quality and some random rant
Alan Smithee Wrote: You can do the same in D using .di files. Except no one really does that because such an approach is insanely error prone. E.g. with classes, you need to copy entire definitions. Change any ordering, forget a field, change a type, and you're having undefined behavior. How about eating your own dog food before making unfounded statements like that? Trivial transliterations of DMDScript or Empire don't count. So far, you've only written silly Bash-like scripts in D. Let's try to act civil here. Walter bashing is already getting old and mostly favored by our famous Reddit trolls, that is retard = uriel = eternium = lurker. I wouldn't be shocked to hear this Alan Smithee is another sockpuppet of yours, dear retard. I already did mention eating your own dog food. On the other hand it's crystal clear that such a task as writing a language and its compiler without any support from anyone is something only a handful of developers can and are willing to pursue on this planet. As a result D is one of the best languages ever built. I honestly wish we wouldn't question Walter's competence. He only has so much time. All this hate talk here pushes release dates farther away. We would already have a 64-bit compiler if you didn't rant so much. - G.W.
Re: tooling quality and some random rant
On 2/13/11, Alan Smithee em...@example.com wrote: You can do the same in D using .di files. Except no one really does that because such an approach is insanely error prone. E.g. with classes, you need to copy entire definitions. Change any ordering, forget a field, change a type, and you're having undefined behavior. Could you elaborate on that? Aren't .di files supposed to be auto-generated by the compiler, and not hand-written?
Re: tooling quality and some random rant
Paulo Pinto wrote: Hi, still you don't convice me. So what language features has C that are missing from D and prevent a linker to be written in D? The issue is not if I can beat Walter, the issue is that we have a language which on its official home page states lots of reasons for using it instead of C and C++, and its creator decides to use C when porting the linker to an high level language. So doesn't Walter belive in its own language? From Walter himself: Why use C instead of the D programming language? Certainly, D is usable for such low level coding and, when programming at this level, there isn't a practical difference between the two. The problem is that the system to build Optlink uses some old tools that only work with an old version of the object file format. The D compiler uses newer obj format features, the C compiler still uses the old ones. It was just easier to use the C compiler rather than modify the D one. Once the source is all in C, it will be trivial to shift it over to D and the modern tools. http://www.drdobbs.com/blog/archives/2009/11/assembler_to_c.html
Re: alias this question
Olli Aalto oaa...@gmail.com wrote: I encountered a problem with alias this, when the aliased member is private. I'm using the latest dmd2. It reports the follwing: src\main.d(14): Error: struct K.K member s is not accessible If I change the private modifier on the s member to public it works. Is this as intended, or a bug? This is intended. alias this (and any other alias) act as simple rewrites to the aliased symbol, and does not change their protection level. I believe there is a bug on this specific issue already, and #4533[1] certainly does describe it in general. http://d.puremagic.com/issues/show_bug.cgi?id=4533 -- Simen
Re: tooling quality and some random rant
Gary Whatmore Wrote (fixed that for you): Let's try to act reasonable here. Walter fanboyism is already getting old and sadly favored by our famous NG trolls, that is pretty much everyone here. I wouldn't be shocked to hear this Gary Whatmore will be bashing D in about 2 years' time when he realizes how naive he has been. The creators haven't even attempted eating their own dog food. On the other hand it's crystal clear that such a task as writing a language and its compiler without any support from anyone is the very definition of Not Invented Here that only a handful of developers are willing to pursue on this planet. As a result D is one of the most broken languages ever built. I honestly wish we would sometimes question Walter's competence. He only has so much time. All this love talk here blinds even more potential users. We would already have a working compiler if they didn't want to reinvent everything.
Re: tooling quality and some random rant
golgeliyele Wrote: It is a mistake to consider the language without the tooling that goes along with it. I think there is still time to recover from this error. Large projects are often build as a series of libraries. When the shared library problem is to be attacked, I think the tooling needs to be part of that design. Solving the tooling problem will raise D to one level up and I hope the community will step up to the challenge. So far D 1.0 development has forced me to study the compiler and library internals much more than I could ever imagine. Had 10 years of Pascal, Delphi, and Java programming under my belt, but never really knew what's the difference between a compiler frontend and compiler. I knew the linker though, but couldn't imagine there could be so many incompatibilities. For example the Delphi community has a large set of commonly used libraries for the casual user. I also ended up learning a great deal of regexps because my editor didn't support D and don't feel awkward reading dmd internals such as cod2.c or mtype.c now. This was all necessary to use D in a simple GUI project and to sidestep common bugs. I really like D. The elegance of the language can be blamed for the most part. In retrospect, I ended up running into more bugs than ever before and spent more time than with any other SDK. However it was so fun that it really wasn't a problem. Basically if you're using D at work, I recommend studying the libraries and finding workaround for bugs at home. This way you won't be spending too much time fighting the tool chain in professional context and get extra points from the voluntarily open source hobby. It also helps our community. This newsgroup's a valuable source of information. Read about tuning of JVM, race cars, rocket science, CRT monitors, and DVCS here. We don't always have to discuss grave business matters.
Re: d-programming-language.org
Can the D logo (as in the github site: https://secure.gravatar.com/avatar/1fe90c0586802aee103ff9ac0b8f3fbe?s=140d=https://github.com%2Fimages%2Fgravatars%2Fgravatar-140.png) located on the left top area where the digital mars logo used to sit? the empty space looks a little strange. -b On 2011-01-30 03:03:08 -0500, Andrei Alexandrescu said: I've had some style updates from David Gileadi rotting in a zip file in my inbox for a good while. It took me the better part of today to manually merge his stale files with the ones in the repository, which have in the meantime undergone many changes. The result is in http://d-programming-language.org. It has (or at least should have) no new content, only style changes. I added a simple site index, see http://d-programming-language.org/siteindex.html. It's not linked from anywhere but gives a good entry point for all pages on the site. One other link of possible interest is http://d-programming-language.org/phobos-prerelease/phobos.html which will contain the latest and greatest Phobos committed to github. I've included build targets to synchronize /phobos-prerelease/ and /phobos/. (Right now both contain the prerelease version; don't let that confuse you.) In agreement with Walter, I removed the Digitalmars reference. The message is simple - D has long become an entity independent from the company that created it. (However, this makes the page header look different and probably less visually appealing.) Anyway, this all is not done in relation or in response to the recent related activity on redesigning the homepage. I just wanted to make sure that we have a clean basis to start from, and am looking with interest at the coming developments. Cheers, Andrei
Re: tooling quality and some random rant
Andrej Mitrovic Wrote: Could you elaborate on that? Aren't .di files supposed to be auto- generated by the compiler, and not hand-written? Yea, aren't they? How come no one uses that feature? Perhaps it's intrinsically broken? *hint hint* This NG assumes a curious stance. Sprouting claims and standing by them until they're shown invalid, and then some. This is not the way to go for a new language. It's YOUR job (not yours in particular, Andrej) to demonstrate the feasibility of a certain feature, ONLY THEN can you claim how it may solve any issues. And it needs to be more than a 10-line Hello World. Because you can concatenate Hello World 1,000,000 times, D can work for multi million line projects, right? But it takes time! ... uh, yea, how's for 11 years? Or at least 4 which D has been past the 1.0 version. How many people gave up on their med/large projects and moved to lesser languages in this span?
Re: tooling quality and some random rant
On 2/13/11, Alan Smithee em...@example.com wrote: Andrej Mitrovic Wrote: Could you elaborate on that? Aren't .di files supposed to be auto- generated by the compiler, and not hand-written? Yea, aren't they? How come no one uses that feature? Perhaps it's intrinsically broken? *hint hint* This NG assumes a curious stance. Sprouting claims and standing by them until they're shown invalid, and then some. This is not the way to go for a new language. It's YOUR job (not yours in particular, Andrej) to demonstrate the feasibility of a certain feature, ONLY THEN can you claim how it may solve any issues. And it needs to be more than a 10-line Hello World. Because you can concatenate Hello World 1,000,000 times, D can work for multi million line projects, right? But it takes time! ... uh, yea, how's for 11 years? Or at least 4 which D has been past the 1.0 version. How many people gave up on their med/large projects and moved to lesser languages in this span? On 2/13/11, em...@example.com em...@example.com wrote: Andrej Mitrovic Wrote: Could you elaborate on that? Aren't .di files supposed to be auto- generated by the compiler, and not hand-written? Yea, aren't they? How come no one uses that feature? Perhaps it's intrinsically broken? *hint hint* This NG assumes a curious stance. Sprouting claims and standing by them until they're shown invalid, and then some. This is not the way to go for a new language. It's YOUR job (not yours in particular, Andrej) to demonstrate the feasibility of a certain feature, ONLY THEN can you claim how it may solve any issues. And it needs to be more than a 10-line Hello World. Because you can concatenate Hello World 1,000,000 times, D can work for multi million line projects, right? But it takes time! ... uh, yea, how's for 11 years? Or at least 4 which D has been past the 1.0 version. How many people gave up on their med/large projects and moved to lesser languages in this span? Heh. :) I'm not claiming that I know that everything works, I only know as much as I've tried. When I've hit a bug in a multi-thousand line project I'll report it to bugzilla. So what's broken about generating import modules, is it already in bugzilla? I've only heard about problems with templates so far, so I don't know. If they're really broken we can push Walter Co. to fix them. I know of a technique, too. I've heard posting a random comment on a D reddit thread about a D bug usually gets Andrei to talk with Walter in private ASAP and fix it right away.
Re: tooling quality and some random rant
golgeliyele wrote: I don't think C++ and gcc set a good bar here. Short of writing our own linker, we're a bit stuck with what ld does.
Re: tooling quality and some random rant
Sun, 13 Feb 2011 19:10:01 +0100, Andrej Mitrovic wrote: On 2/13/11, Alan Smithee em...@example.com wrote: Andrej Mitrovic Wrote: Could you elaborate on that? Aren't .di files supposed to be auto- generated by the compiler, and not hand-written? Yea, aren't they? How come no one uses that feature? Perhaps it's intrinsically broken? *hint hint* This NG assumes a curious stance. Sprouting claims and standing by them until they're shown invalid, and then some. This is not the way to go for a new language. It's YOUR job (not yours in particular, Andrej) to demonstrate the feasibility of a certain feature, ONLY THEN can you claim how it may solve any issues. And it needs to be more than a 10-line Hello World. Because you can concatenate Hello World 1,000,000 times, D can work for multi million line projects, right? But it takes time! ... uh, yea, how's for 11 years? Or at least 4 which D has been past the 1.0 version. How many people gave up on their med/large projects and moved to lesser languages in this span? On 2/13/11, em...@example.com em...@example.com wrote: Andrej Mitrovic Wrote: Could you elaborate on that? Aren't .di files supposed to be auto- generated by the compiler, and not hand-written? Yea, aren't they? How come no one uses that feature? Perhaps it's intrinsically broken? *hint hint* This NG assumes a curious stance. Sprouting claims and standing by them until they're shown invalid, and then some. This is not the way to go for a new language. It's YOUR job (not yours in particular, Andrej) to demonstrate the feasibility of a certain feature, ONLY THEN can you claim how it may solve any issues. And it needs to be more than a 10-line Hello World. Because you can concatenate Hello World 1,000,000 times, D can work for multi million line projects, right? But it takes time! ... uh, yea, how's for 11 years? Or at least 4 which D has been past the 1.0 version. How many people gave up on their med/large projects and moved to lesser languages in this span? Heh. :) I'm not claiming that I know that everything works, I only know as much as I've tried. When I've hit a bug in a multi-thousand line project I'll report it to bugzilla. So what's broken about generating import modules, is it already in bugzilla? I've only heard about problems with templates so far, so I don't know. If they're really broken we can push Walter Co. to fix them. I know of a technique, too. I've heard posting a random comment on a D reddit thread about a D bug usually gets Andrei to talk with Walter in private ASAP and fix it right away. I wish there were more news about D. This would bring us more reddit threads and thus more bug fixes.
Re: tooling quality and some random rant
Andrej Mitrovic wrote: Could you elaborate on that? Aren't .di files supposed to be auto-generated by the compiler, and not hand-written? You can do it either way. In Phobos, you can find examples of both. In no instance are you worse off than with C++ .h/.cpp files.
is there any way to get a list of classes that inherit a class?
Hello, I know you can easily get the base class of some class in D. However is there any way to get a list of classes that inherit a given class? I was reading around the docs, but couldn't find anything :/. But maybe someone knows how to do it?
Re: alias this question
On 13.2.2011 19:40, Simen kjaeraas wrote: Olli Aalto oaa...@gmail.com wrote: I encountered a problem with alias this, when the aliased member is private. I'm using the latest dmd2. It reports the follwing: src\main.d(14): Error: struct K.K member s is not accessible If I change the private modifier on the s member to public it works. Is this as intended, or a bug? This is intended. alias this (and any other alias) act as simple rewrites to the aliased symbol, and does not change their protection level. Pity. Would have been nice, now it's just one pretty useless feature at the end of a list of features for the language. O.
Re: tooling quality and some random rant
On Sun, 13 Feb 2011 20:26:50 +0200, Walter Bright newshou...@digitalmars.com wrote: golgeliyele wrote: I don't think C++ and gcc set a good bar here. Short of writing our own linker, we're a bit stuck with what ld does. That's not true. The compiler has knowledge of what symbols will be passed to the linker, and can display its own, much nicer error messages. I've mentioned this in our previous discussion on this topic. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: tooling quality and some random rant
Paulo Pinto wrote: Why C and not directly D? It is really bad adversting for D to know that when its creator came around to rewrite the linker, Walter decided to use C instead of D. That's a very good question. The answer is in the technical details of transitioning optlink from an all assembler project to a higher level language. I do it function by function, meaning there will be hundreds of hybrid versions that are partly in the high level language, partly in asm. Currently, it's around 5% in C. 1. Optlink has its own runtime system and startup code. With C, and a little knowledge about how things work under the hood, it's easier to create headless functions that require zero runtime and startup support. With D, the D compiler will create ModuleInfo and TypeInfo objects, which more or less rely on some sort of D runtime existing. 2. The group/segment names emitted by the C compiler match what Optlink uses. It matches what dmd does, too, except that dmd emits more such names, requiring more of an understanding of Optlink to get them in the right places. 3. The hybrid intermediate versions require that the asm portions of Optlink be able to call the high level language functions. In order to avoid an error-prone editting of scores of files, it is very convenient to have the function names used by the asm code exactly match the names emitted by the compiler. I accomplished this by tweaking the dmc C compiler. I didn't really want to mess with the D compiler to do the same. 4. Translating asm to a high level language starts with a rote translation, i.e. using goto's, raw pointers, etc., which match 1:1 with the assembler logic. No attempt is made to infer higher level logic. This makes mistakes in the translation easier to find. But it's not the way anyone in their right mind would develop C code. The higher level abstractions in C are not useful here, and neither are the higher level abstractions in D. Once the entire Optlink code base has been converted, then it becomes a simple process to: 1. Dump the Optlink runtime, and switch to the C runtime. 2. Translate the C code to D. And then: 3. Refactor the D code into higher level abstractions. I've converted a massive code base from asm to C++ before (DASH for Data I/O) and I discovered that attempting to refactor the code while translating it is fraught with disaster. Doing the hybrid approach is much faster and more likely to be successful. TL,DR: The C version is there only as a transitional step, as it's somewhat easier to create a hybrid asm/C code base than a hybrid asm/D one. The goal is to create a D version.
Re: tooling quality and some random rant
Walter Bright newshou...@digitalmars.com wrote: golgeliyele wrote: I don't think C++ and gcc set a good bar here. Short of writing our own linker, we're a bit stuck with what ld does. I am not necessarily questioning the use of ld (or a different linker on a different platform). What intrigues me is: Is it possible to avoid leaking ld errors to the end user. For instance, with the compilation model of feeding all the .d files to dmd, we should be able to check if main() is missing or not, before going to the linker. I don't think supporting multiple compilation models is a good thing. I really hope you guys can visit this issue sometime soon.
Re: tooling quality and some random rant
golgeliyele wrote: 1. Difficult to understand linker errors due to missing main(): Fixing this would be useful for newbies. If there is not already a defect on this, I suggest we file a defect and it gets fixed sometime. I am assuming that this can be caught before going to the linker. Does dmd support creating an executable whose main() comes from a library? If not, the compiler would know if there is a main() or not before doing the linking. I can see how this is a problem with incremental builds though. However, with the compilation model that is being advocated by the documentation (i.e, feed dmd all the .d files at once), the compiler should know if main() is there or not. Yet another reason to clarify the compilation model, IMO. The problem is the main() can come from a library, or some other .obj file handed to the compiler that the compiler doesn't look inside. It's a very flexible way to build things, and trying to impose more order on that will surely wind up with complaints from some developers. 2. dmd compiler's command line options: This is mostly an esthetic issue. However, it is like the entrance to your house. People who are not sure about entering in care about what it looks like from the outside. If Walter is willing, I can work on a command line options interface proposal that would keep backwards compatibility with the existing options. This would enable a staged transition. Would there be an interest in this? A proposal would be nice. But please keep in mind that people often view their build systems / makefiles as black boxes, and breaking them with incompatible changes can be extremely annoying. 3. Incremental compilation (or lack of it) First of all there is a documentation problem here. There needs to be clarity about whether incremental compilation is possible or not. I won't count approaches that work partially as anything more than a stopgap solution. IMO, it is acceptable if we can state that dmd compilations are blazingly fast, and as a result, there is no reason to do incremental compilation. The problem is that I get mixed signals on this point: - If this claim is true, then I think it should be asserted strongly and should be backed up by numbers (100K library compilation takes X seconds, etc.) I stopped bothering posting numbers because nobody believed them. I was even once accused of sabotaging my own C++ compiler to make dmd look better. dmc++ is, by far, the fastest C++ compiler available. The people who use it know that and like it a lot. The people who don't use it just assume I'm lying about the speed, and I get tired of being accused of such. - If this claim is false, then we should look at enhancing the tooling with things like xfBuild. Perhaps that kind of functionality can be built into the compiler itself. Whatever is needed, the following needs to be clearly documented: What is the best way to organize the build of large projects? It is a mistake to consider the language without the tooling that goes along with it. I think there is still time to recover from this error. Large projects are often build as a series of libraries. When the shared library problem is to be attacked, I think the tooling needs to be part of that design. Solving the tooling problem will raise D to one level up and I hope the community will step up to the challenge. One last thing: Personally, I don't like this business with .di files. They are optional, but then they are needed for certain use cases. I believe the information that is contained in .di files should be packed alongside the shared library and I should be able to build/link against a single library package. I haven't used Java for a long time, but I recall you get a .jar file and javadoc documentation when you are handed a library. I like that. In the worst case, you are no worse off with .di files than with C++ .h files.
Re: tooling quality and some random rant
Lutger Blijdestijn wrote: Why use C instead of the D programming language? Certainly, D is usable for such low level coding and, when programming at this level, there isn't a practical difference between the two. The problem is that the system to build Optlink uses some old tools that only work with an old version of the object file format. The D compiler uses newer obj format features, the C compiler still uses the old ones. It was just easier to use the C compiler rather than modify the D one. Once the source is all in C, it will be trivial to shift it over to D and the modern tools. http://www.drdobbs.com/blog/archives/2009/11/assembler_to_c.html Yeah, I forgot to mention that Optlink relies on some tools that work only with an obsolete version of the omf.
Re: tooling quality and some random rant
Am 13.02.2011 20:01, schrieb gölgeliyele: I don't think supporting multiple compilation models is a good thing. I think incremental compilation is a very useful feature for large projects so it should be available. Also the possibility to link in .o files that were generated from C code with D programs is a must - so only supporting the model of feeding all .d files to dmd is not an option. But not supporting the model of feeding all .d files to dmd is very useful and should be possible. So *I* /do/ think that supporting multiple compilation models is a good thing :-) I think we can live with having the linker output something like Undefined symbols: __Dmain, referenced from: _D2rt6dmain24mainUiPPaZi7runMainMFZv in libphobos2.a(dmain2_513_1a5.o) It would make sense to have a Troubleshooting section on the homepage that mentions this and other common problems, though. Cheers, - Daniel
Re: tooling quality and some random rant
gölgeliyele wrote: I don't think supporting multiple compilation models is a good thing. I think it's necessary if one is to support both small and large projects, and all the different ways one could use a D compiler as a tool.
Re: tooling quality and some random rant
Vladimir Panteleev wrote: On Sun, 13 Feb 2011 20:26:50 +0200, Walter Bright newshou...@digitalmars.com wrote: golgeliyele wrote: I don't think C++ and gcc set a good bar here. Short of writing our own linker, we're a bit stuck with what ld does. That's not true. The compiler has knowledge of what symbols will be passed to the linker, and can display its own, much nicer error messages. I've mentioned this in our previous discussion on this topic. Not without reading the .o files passed to the linker, and the libraries, and figuring out what would be pulled in from those libraries. In essence, the compiler would have to become a linker. It's not impossible, but is a tremendous amount of work in order to improve one error message, and one error message that generations of C and C++ programmers are comfortable dealing with.
Re: tooling quality and some random rant
retard wrote: I wish there were more news about D. This would bring us more reddit threads and thus more bug fixes. You can write articles about D and post them to reddit. What's holding you back?
Re: Stupid little iota of an idea
On 02/13/2011 01:17 PM, foobar wrote: Lutger Blijdestijn Wrote: first rule of usability: don't listen to users http://www.useit.com/alertbox/20010805.html I fail to see how that page ( which talks about website design ) applies to what I've said. It says that you should look at what people _do_ instead of what they _say_. How would you apply this to Phobos' naming conventions? Agreed. I know a bit this design guru's work. The titles of his articles are often misleading, even more out of context. What he point to is the common practice of design team managers taking decisions based on studies about users just giving an advice after a superficial look on the design's appearance; often without any trial at using the interface, not to say real usability experiments. To re-center on the case of this thread, I'm 99% sure this guy (the guru) would certainly carefully listen to comments from power-user who have past experience on using other interfaces providing similar functionality, and have really tried using the new one for a while. How about this: Show a code sample using iota to users who never programmed in D and ask them what that code does. Agreed. On the other hand, I also agree with people stating good design mirrors some/one/'s vision... Denis -- _ vita es estrany spir.wikidot.com
Re: tooling quality and some random rant
Walter Bright newshou...@digitalmars.com wrote: golgeliyele wrote: 1. Difficult to understand linker errors due to missing main(): ... The problem is the main() can come from a library, or some other .obj file handed to the compiler that the compiler doesn't look inside. It's a very flexible way to build things, and trying to impose more order on that will surely wind up with complaints from some developers. I would like to question this. Is there a D project where the technique of putting main() into a library has proved useful? I used this in a C++ project of mine, but I have regretted that already. I can imagine having a compiler option to avoid the pre-link check for main(), but I would suggest not even having that. Of course unless we get to know what those complaints you mentioned are :) 2. dmd compiler's command line options: This is mostly an esthetic issue. However, it is like the entrance to your house. People who are not sure about entering in care about what it looks like from the outside. If Walter is willing, I can work on a command line options interface proposal that would keep backwards compatibility with the existing options. This would enable a staged transition. Would there be an interest in this? A proposal would be nice. But please keep in mind that people often view their build systems / makefiles as black boxes, and breaking them with incompatible changes can be extremely annoying. Thanks for being open. I'll work on this. 3. Incremental compilation (or lack of it) ... I stopped bothering posting numbers because nobody believed them. I was even once accused of sabotaging my own C++ compiler to make dmd look better. dmc++ is, by far, the fastest C++ compiler available. The people who use it know that and like it a lot. The people who don't use it just assume I'm lying about the speed, and I get tired of being accused of such. I think what we need here is numbers from a project that everyone has access to. What is the largest D project right now? Can we get numbers on that? How much time does it take to compile that project after a change (assuming we are feeding all .d files at once)? - If this claim is false, then we should look at enhancing the tooling with things like xfBuild. Perhaps that kind of ... In the worst case, you are no worse off with .di files than with C++ .h files. :) .h files is something I want to forget forever.
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Akakima wrote: Changing the object module format is not sufficient. The symbolic debug info would have to be changed (and Microsoft's is undocumented) and then there's the dependency on Microsoft's C runtime library if linking with VC generated object files. I found some doc there: http://pierrelib.pagesperso-orange.fr/exec_formats/index.html Microsoft Symbol and Type Information By TIS / Microsoft. Entry added 12/28/2004. Keywords: ms, symbol, type, info File: MS_Symbol_Type_v1.0.pdf « This document describes Microsoft Symbol and Type Information, a debugging information format fromMicrosoft Corporation for the 32-bit Windows environment. » That document describes the Codeview symbol debug format, which Microsoft abandoned 15 years ago in favor of a proprietary format. Dmd generates that older format :-)
Re: tooling quality and some random rant
On 02/13/2011 01:59 PM, bearophile wrote:
Walter:
In C++, you get essentially the same thing from g++:
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o: In function
`_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
Lot of people come here because they want a compiler+language better than C++
:-)
If you compile this:
void main() {
writeln(Hello world);
}
Since some time dmd shows an error fit for D newbies:
test.d(2): Error: 'writeln' is not defined, perhaps you need to import
std.stdio; ?
Probably many Python/JS/Perl/PHP/etc programmers that may want to try D don't
know what a linker is. When they want to develop a large multi-module D program
they must know something about how a linker works. But D has to scale down to
smaller programs too, where there are only one or very few modules, written by
not experts of C-class languages. In this situation more readable error
messages, produced by dmd that catches a basic error before the linker, is
probably useful.
Couldn't have written this one better ;-)
Denis
--
_
vita es estrany
spir.wikidot.com
Re: tooling quality and some random rant
Daniel Gibson metalcae...@gmail.com wrote: Am 13.02.2011 20:01, schrieb gölgeliyele: I don't think supporting multiple compilation models is a good thing. I think incremental compilation is a very useful feature for large projects so it should be available. Also the possibility to link in .o files that were generated from C code with D programs is a must - so only supporting the model of feeding all .d files to dmd is not an option. But not supporting the model of feeding all .d files to dmd is very useful and should be possible. So *I* /do/ think that supporting multiple compilation models is a good thing :-) Ok, I might have misspoken there. I am not against incremental compilation. What the heck, the lack of it is the reason I started the thread. However, I would like to see a coherent compilation model. Feeding all .d files to the compiler does not necessarily mean that it needs to be a from-scratch compilation. Isn't the need for tools like xfBuild an indication that something is wrong here. If you can point me to a write up that describes how to setup an incremental compilation for a large project, without using advanced tools like xfBuild, that would be very helpful.
Re: tooling quality and some random rant
gölgeliyele wrote: Walter Bright newshou...@digitalmars.com wrote: golgeliyele wrote: 1. Difficult to understand linker errors due to missing main(): ... The problem is the main() can come from a library, or some other .obj file handed to the compiler that the compiler doesn't look inside. It's a very flexible way to build things, and trying to impose more order on that will surely wind up with complaints from some developers. I would like to question this. Is there a D project where the technique of putting main() into a library has proved useful? I used this in a C++ project of mine, but I have regretted that already. I can imagine having a compiler option to avoid the pre-link check for main(), but I would suggest not even having that. Of course unless we get to know what those complaints you mentioned are :) I find that people have all kinds of ways they wish to use a compiler. Is it worth restricting all that just for the case of one error message? I also have tried to avoid adding endless command line switches as the solution to every variation people want. These cause: 1. people just check out when they see pages and pages of wacky switches. Has anyone ever actually read all of man gcc? 2. different compiler switches can have unexpected interactions and complications when used together. This is impossible to test for, as the combinations increase as the factorial of the number of switches. 3. people tend to copy/paste makefiles from one project to the next. They copy/paste the switches, too, usually with no idea what those switches do. I.e. they treat those switches as some sort of sacred incantation that they dare not change.
Re: tooling quality and some random rant
bearophile wrote:
Walter:
With D, the D compiler will create ModuleInfo and TypeInfo objects, which
more or less rely on some sort of D runtime existing.
In LDC there are no_typeinfo (and in maybe no_moduleinfo) pragmas to disable
the generation of those for specific types/modules:
http://www.dsource.org/projects/ldc/wiki/Docs#no_typeinfo
pragma(no_typeinfo) { struct Opaque {} }
If it's useful then something similar may be added to DMD too.
I think it's best to avoid such things.
Re: tooling quality and some random rant
On Sun, 13 Feb 2011 22:12:02 +0300, Walter Bright newshou...@digitalmars.com wrote: Vladimir Panteleev wrote: On Sun, 13 Feb 2011 20:26:50 +0200, Walter Bright newshou...@digitalmars.com wrote: golgeliyele wrote: I don't think C++ and gcc set a good bar here. Short of writing our own linker, we're a bit stuck with what ld does. That's not true. The compiler has knowledge of what symbols will be passed to the linker, and can display its own, much nicer error messages. I've mentioned this in our previous discussion on this topic. Not without reading the .o files passed to the linker, and the libraries, and figuring out what would be pulled in from those libraries. In essence, the compiler would have to become a linker. It's not impossible, but is a tremendous amount of work in order to improve one error message, and one error message that generations of C and C++ programmers are comfortable dealing with. What's wrong with parsing low-level linker error messages and output them in human-readable form? E.g. demangle missing symbols.
Re: is there any way to get a list of classes that inherit a class?
I don't know if you can find all of them easily but you can find the
instantiated
ones by adding a line to the Foo constructor as shown here.
Two limits:
1. This doesn't report Bar itself since a Bar object is never created; however
in
a sense a 'Bar' object was created when Baz and Qux are created. Since you know
how to get the parent of a type you should be able to fix this if desired.
2. As mentioned you can't get the non-instantiated classes this way -- it only
detects classes as 'new' is called on them. By the way this wouldn't work in
C++
because in C++ object identity changes as the successive constructors are called
-- it would just report Foo.
3. Of course you could add a pure virtual function to the class...
testrtti.d:
import std.stdio;
int[string] fooTypes;
class Foo {
this() { fooTypes[this.classinfo.name] = 1; }
};
class Bar : Foo {
};
class Baz : Bar {
};
class Qux : Baz {
};
int main()
{
Foo a = new Foo;
Foo b = new Qux;
Bar f = new Baz;
foreach(key, value; fooTypes) {
writefln(foo subtype: %s, key);
}
return 0;
}
foo subtype: testrtti.Foo
foo subtype: testrtti.Baz
foo subtype: testrtti.Qux
Kevin
Re: tooling quality and some random rant
Denis Koroskin wrote: It's not impossible, but is a tremendous amount of work in order to improve one error message, and one error message that generations of C and C++ programmers are comfortable dealing with. What's wrong with parsing low-level linker error messages and output them in human-readable form? E.g. demangle missing symbols. Yes, that can be done. The downside is since dmd does not control what linker the user has, it becomes a constant source of problems trying to keep it working as it constantly breaks with linker changes and an arbitrarily long list of linkers on various distributions.
Re: tooling quality and some random rant
gölgeliyele wrote: ... I think what we need here is numbers from a project that everyone has access to. What is the largest D project right now? Can we get numbers on that? How much time does it take to compile that project after a change (assuming we are feeding all .d files at once)? Well you can take phobos, I believe Andrei used it once to compare against Go. With std.datetime it is now also much bigger :) Tango is another large project, I remember someone posted a compilation speed of a couple of seconds (Tango is huge, perhaps 300KLoC). But projects and settings may vary a lot. For sure, optlink is one hell of a speed monster and you might not get similar speeds with ld on a large project.
Re: tooling quality and some random rant
On 02/13/2011 04:07 PM, Gary Whatmore wrote: his might sound like blasphemy, but I believe the skills and knowledge for developing large scale applications in language XYZ cannot be extrapolated from small code snippets or from experience with projects in other languages. You just need to eat your own dogfood and get your feet wet by doing. Precisely. A common route for the development of a static and compiled language (even more one intended as system programming language) is to eat its own dogfood by becoming its own compiler. From what I've heard, this is a great boost for the language's evolution, precisely because the creators use their language everyday from then --instead of becoming more more experts in another one. Also, I really miss a D for D lexical- syntactic- semantic- analyser that would produce D data structures. This would open the door hoards of projects, including tool chain elements, meta-studies on D, improvements of these basic tools (efficiency, semantis analysis), decelopment of back-ends (including studies on compiler optimisation specific to D's semantics), etc. Even more important, the whole cummunity, which is imo rather high-level, would be able to take part to such challenges, in their favorite language. Isn't is ironic D depends so much on C++, while many programmers come to D fed up with this language, presicely? Denis -- _ vita es estrany spir.wikidot.com
Re: is there any way to get a list of classes that inherit a class?
On Sun, 13 Feb 2011 19:38:23 -, Kevin Bealer
kevindangerbea...@removedanger.gmail.com wrote:
I don't know if you can find all of them easily but you can find the
instantiated
ones by adding a line to the Foo constructor as shown here.
Two limits:
1. This doesn't report Bar itself since a Bar object is never created;
however in
a sense a 'Bar' object was created when Baz and Qux are created. Since
you know
how to get the parent of a type you should be able to fix this if
desired.
2. As mentioned you can't get the non-instantiated classes this way --
it only
detects classes as 'new' is called on them. By the way this wouldn't
work in C++
because in C++ object identity changes as the successive constructors
are called
-- it would just report Foo.
3. Of course you could add a pure virtual function to the class...
testrtti.d:
import std.stdio;
int[string] fooTypes;
class Foo {
this() { fooTypes[this.classinfo.name] = 1; }
};
class Bar : Foo {
};
class Baz : Bar {
};
class Qux : Baz {
};
int main()
{
Foo a = new Foo;
Foo b = new Qux;
Bar f = new Baz;
foreach(key, value; fooTypes) {
writefln(foo subtype: %s, key);
}
return 0;
}
foo subtype: testrtti.Foo
foo subtype: testrtti.Baz
foo subtype: testrtti.Qux
Kevin
Thanks for reply, I'm going to test it out now.
I guess there's no chance of getting the derived classes during the
compile time, so I'll have to use this runtime approach.
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Walter Bright wrote: Akakima wrote: Changing the object module format is not sufficient. The symbolic debug info would have to be changed (and Microsoft's is undocumented) and then there's the dependency on Microsoft's C runtime library if linking with VC generated object files. I found some doc there: http://pierrelib.pagesperso-orange.fr/exec_formats/index.html Microsoft Symbol and Type Information By TIS / Microsoft. Entry added 12/28/2004. Keywords: ms, symbol, type, info File: MS_Symbol_Type_v1.0.pdf « This document describes Microsoft Symbol and Type Information, a debugging information format fromMicrosoft Corporation for the 32-bit Windows environment. » That document describes the Codeview symbol debug format, which Microsoft abandoned 15 years ago in favor of a proprietary format. Dmd generates that older format :-) Are you going to do Elf? With optlink in D? (Does that even make sense?)
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
Lutger Blijdestijn wrote: Walter Bright wrote: Akakima wrote: Changing the object module format is not sufficient. The symbolic debug info would have to be changed (and Microsoft's is undocumented) and then there's the dependency on Microsoft's C runtime library if linking with VC generated object files. I found some doc there: http://pierrelib.pagesperso-orange.fr/exec_formats/index.html Microsoft Symbol and Type Information By TIS / Microsoft. Entry added 12/28/2004. Keywords: ms, symbol, type, info File: MS_Symbol_Type_v1.0.pdf « This document describes Microsoft Symbol and Type Information, a debugging information format fromMicrosoft Corporation for the 32-bit Windows environment. » That document describes the Codeview symbol debug format, which Microsoft abandoned 15 years ago in favor of a proprietary format. Dmd generates that older format :-) Are you going to do Elf? With optlink in D? (Does that even make sense?) Elf is not a symbolic debug format. It is possible to use Codeview with Elf. In any case, such decisions will have to revolve around the availability of things like debuggers.
Re: is there any way to get a list of classes that inherit a class?
hyp nore...@gmail.com wrote:
Hello,
I know you can easily get the base class of some class in D. However is
there any way to get a list of classes that inherit a given class?
I was reading around the docs, but couldn't find anything :/. But maybe
someone knows how to do it?
This question is probably better asked in digitalmars.D.learn.
As for the solution, this works:
TypeInfo_Class[] getSubClasses( Object o ) {
typeof( return ) result;
auto base = o.classinfo;
foreach ( m; ModuleInfo ) {
foreach ( c; m.localClasses ) {
auto a = c;
while ( a a != base ) {
a = a.base;
}
if ( a == base ) {
result ~= c;
}
}
}
return result;
}
class A {}
class B : A {}
void main( ) {
writeln( getSubClasses( new A() ) );
}
Do note however, that templated classes do not show up in this search.
--
Simen
Re: tooling quality and some random rant
On 02/13/2011 07:53 PM, Walter Bright wrote: Paulo Pinto wrote: Why C and not directly D? It is really bad adversting for D to know that when its creator came around to rewrite the linker, Walter decided to use C instead of D. That's a very good question. The answer is in the technical details of transitioning optlink from an all assembler project to a higher level language. I do it function by function, meaning there will be hundreds of hybrid versions that are partly in the high level language, partly in asm. Currently, it's around 5% in C. 1. Optlink has its own runtime system and startup code. With C, and a little knowledge about how things work under the hood, it's easier to create headless functions that require zero runtime and startup support. With D, the D compiler will create ModuleInfo and TypeInfo objects, which more or less rely on some sort of D runtime existing. 2. The group/segment names emitted by the C compiler match what Optlink uses. It matches what dmd does, too, except that dmd emits more such names, requiring more of an understanding of Optlink to get them in the right places. 3. The hybrid intermediate versions require that the asm portions of Optlink be able to call the high level language functions. In order to avoid an error-prone editting of scores of files, it is very convenient to have the function names used by the asm code exactly match the names emitted by the compiler. I accomplished this by tweaking the dmc C compiler. I didn't really want to mess with the D compiler to do the same. 4. Translating asm to a high level language starts with a rote translation, i.e. using goto's, raw pointers, etc., which match 1:1 with the assembler logic. No attempt is made to infer higher level logic. This makes mistakes in the translation easier to find. But it's not the way anyone in their right mind would develop C code. The higher level abstractions in C are not useful here, and neither are the higher level abstractions in D. Once the entire Optlink code base has been converted, then it becomes a simple process to: 1. Dump the Optlink runtime, and switch to the C runtime. 2. Translate the C code to D. And then: 3. Refactor the D code into higher level abstractions. I've converted a massive code base from asm to C++ before (DASH for Data I/O) and I discovered that attempting to refactor the code while translating it is fraught with disaster. Doing the hybrid approach is much faster and more likely to be successful. TL,DR: The C version is there only as a transitional step, as it's somewhat easier to create a hybrid asm/C code base than a hybrid asm/D one. The goal is to create a D version. Great! Thank you very much for this clear comprehensive explanation of the process, Walter. (*) Denis (I can understand what you mean with this 2-stage translation --beeing easier, safer, and finally far more efficient-- having done something similar, but at a smaller-scale, probably, in the field of automation; where languages are often even closer to asm than C, 'cause much memory is in fact binary IO cards, directly accessed as is.) -- _ vita es estrany spir.wikidot.com
Re: tooling quality and some random rant
On 2011-02-13 14:38:20 -0500, Walter Bright newshou...@digitalmars.com said:
Denis Koroskin wrote:
It's not impossible, but is a tremendous amount of work in order to
improve one error message, and one error message that generations of C
and C++ programmers are comfortable dealing with.
What's wrong with parsing low-level linker error messages and output
them in human-readable form? E.g. demangle missing symbols.
Yes, that can be done. The downside is since dmd does not control what
linker the user has, it becomes a constant source of problems trying to
keep it working as it constantly breaks with linker changes and an
arbitrarily long list of linkers on various distributions.
Parsing error messages is a problem indeed. But demangling symbol names
is easy. Try this:
dmd ... 21 | ddemangle
With ddemangle being a compiled version of this program:
import std.stdio;
import core.demangle;
void main()
{
foreach (line; stdin.byLine())
{
size_t beginIdx, endIdx;
enum State { searching_, searchingD, searchingEnd, done }
State state;
foreach (i, char c; line)
{
switch (state)
{
case State.searching_:
if (c == '_')
{
beginIdx = i;
state = State.searchingD;
}
break;
case State.searchingD:
if (c == 'D')
state = State.searchingEnd;
else if (c != '_')
state = State.searching_;
break;
case State.searchingEnd:
if (c == ' ' || c == '' || c == '\'')
{
endIdx = i;
state = State.done;
}
break;
}
if (state == State.done)
break;
}
if (endIdx beginIdx)
writeln(line[0..beginIdx], demangle(line[beginIdx..endIdx]),
line[endIdx..$]);
else
writeln(line);
}
}
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: tooling quality and some random rant
On 02/13/2011 08:30 PM, Walter Bright wrote: 1. people just check out when they see pages and pages of wacky switches. Has anyone ever actually read all of man gcc? + 12_000 /lines/ in my version Denis -- _ vita es estrany spir.wikidot.com
Re: tooling quality and some random rant
Hi, now I am conviced. Thanks for the explanation. -- Paulo Walter Bright newshou...@digitalmars.com wrote in message news:ij99gb$18fm$1...@digitalmars.com... Paulo Pinto wrote: Why C and not directly D? It is really bad adversting for D to know that when its creator came around to rewrite the linker, Walter decided to use C instead of D. That's a very good question. The answer is in the technical details of transitioning optlink from an all assembler project to a higher level language. I do it function by function, meaning there will be hundreds of hybrid versions that are partly in the high level language, partly in asm. Currently, it's around 5% in C. 1. Optlink has its own runtime system and startup code. With C, and a little knowledge about how things work under the hood, it's easier to create headless functions that require zero runtime and startup support. With D, the D compiler will create ModuleInfo and TypeInfo objects, which more or less rely on some sort of D runtime existing. 2. The group/segment names emitted by the C compiler match what Optlink uses. It matches what dmd does, too, except that dmd emits more such names, requiring more of an understanding of Optlink to get them in the right places. 3. The hybrid intermediate versions require that the asm portions of Optlink be able to call the high level language functions. In order to avoid an error-prone editting of scores of files, it is very convenient to have the function names used by the asm code exactly match the names emitted by the compiler. I accomplished this by tweaking the dmc C compiler. I didn't really want to mess with the D compiler to do the same. 4. Translating asm to a high level language starts with a rote translation, i.e. using goto's, raw pointers, etc., which match 1:1 with the assembler logic. No attempt is made to infer higher level logic. This makes mistakes in the translation easier to find. But it's not the way anyone in their right mind would develop C code. The higher level abstractions in C are not useful here, and neither are the higher level abstractions in D. Once the entire Optlink code base has been converted, then it becomes a simple process to: 1. Dump the Optlink runtime, and switch to the C runtime. 2. Translate the C code to D. And then: 3. Refactor the D code into higher level abstractions. I've converted a massive code base from asm to C++ before (DASH for Data I/O) and I discovered that attempting to refactor the code while translating it is fraught with disaster. Doing the hybrid approach is much faster and more likely to be successful. TL,DR: The C version is there only as a transitional step, as it's somewhat easier to create a hybrid asm/C code base than a hybrid asm/D one. The goal is to create a D version.
Re: tooling quality and some random rant
Hi, this is what I miss in D and Go. Most developers that only used C and C++ aren't aware how easy it is to compile applications in more modern languages. It is funny that both D and Go advertise their compilation speed, when I was used to fast compilation since the MS-DOS days with Turbo Pascal. JVM and .Net based languages have editors that do compile on save. Most game studios that have changed from C++ to C# and Java as main development language always cite the productivity gain in the compile-test-debug cycle. I was a bit disappointed to find out that both Go and D still propose a compiler/linker model. -- Paulo charlie char...@yahoo.com wrote in message news:ij95ge$119o$1...@digitalmars.com... golgeliyele Wrote: It is a mistake to consider the language without the tooling that goes along with it. I think there is still time to recover from this error. Large projects are often build as a series of libraries. When the shared library problem is to be attacked, I think the tooling needs to be part of that design. Solving the tooling problem will raise D to one level up and I hope the community will step up to the challenge. So far D 1.0 development has forced me to study the compiler and library internals much more than I could ever imagine. Had 10 years of Pascal, Delphi, and Java programming under my belt, but never really knew what's the difference between a compiler frontend and compiler. I knew the linker though, but couldn't imagine there could be so many incompatibilities. For example the Delphi community has a large set of commonly used libraries for the casual user. I also ended up learning a great deal of regexps because my editor didn't support D and don't feel awkward reading dmd internals such as cod2.c or mtype.c now. This was all necessary to use D in a simple GUI project and to sidestep common bugs. I really like D. The elegance of the language can be blamed for the most part. In retrospect, I ended up running into more bugs than ever before and spent more time than with any other SDK. However it was so fun that it really wasn't a problem. Basically if you're using D at work, I recommend studying the libraries and finding workaround for bugs at home. This way you won't be spending too much time fighting the tool chain in professional context and get extra points from the voluntarily open source hobby. It also helps our community. This newsgroup's a valuable source of information. Read about tuning of JVM, race cars, rocket science, CRT monitors, and DVCS here. We don't always have to discuss grave business matters.
Re: tooling quality and some random rant
Alan Smithee em...@example.com wrote in message news:ij967s$12rb$1...@digitalmars.com... Andrej Mitrovic Wrote: Could you elaborate on that? Aren't .di files supposed to be auto- generated by the compiler, and not hand-written? Yea, aren't they? How come no one uses that feature? Perhaps it's intrinsically broken? *hint hint* Perhaps? Well, is it or isn't it? Are we supposed to just assume that lack of use means it's actually broken and not just unpopular? This NG assumes a curious stance. Sprouting claims and standing by them until they're shown invalid, and then some. Just like you're doing? If you're sure that .di files are broken, then *show us* how. But it takes time! ... uh, yea, how's for 11 years? Or at least 4 which D has been past the 1.0 version. How many people gave up on their med/large projects and moved to lesser languages in this span? Then contribute instead of just flaming.
Re: tooling quality and some random rant
spir denis.s...@gmail.com wrote in message news:mailman.1602.1297626622.4748.digitalmar...@puremagic.com... Also, I really miss a D for D lexical- syntactic- semantic- analyser that would produce D data structures. This would open the door hoards of projects, including tool chain elements, meta-studies on D, improvements of these basic tools (efficiency, semantis analysis), decelopment of back-ends (including studies on compiler optimisation specific to D's semantics), etc. Even more important, the whole cummunity, which is imo rather high-level, would be able to take part to such challenges, in their favorite language. Isn't is ironic D depends so much on C++, while many programmers come to D fed up with this language, presicely? DDMD: http://www.dsource.org/projects/ddmd
Re: tooling quality and some random rant
Michel Fortin wrote: Parsing error messages is a problem indeed. But demangling symbol names is easy. Demangling doesn't get us where golgeliyele wants to go.
'live' testing style
Hello,
Back to the subject of using unittest and assert. I'll try to illustrate a
testing style that seems to be rare in the D community, is not properly
supported by D builtin tools --while this would require only minimal
improvements--, and is imo rather sensible, practicle and efficient. Using an
example of a current project of mine (a toy homoiconic language, kind of
special Lisp).
Below is a copy of part of the parser's test suite. Maybe have a quick look
before reading further [Note: I don't mean the example is a model of any sort,
not even it's good code. It is just illustration of some testing practice.] The
testList func tests the match func for List literal notations. Some comments,
in form of question-answer:
* Why isn't testList a unittest block?
Using named funcs, I can switch on off specific test suites by (un)commenting
their call from the main and unique unittest block. Else, either they all run,
or none. During development, I only keep active the test func(s) relative to
the feature I'm currently working on.
Remedy: named unittests.
* Why those write(f)(ln) in unitests?
For me unittests are not only regression tests, to be used /after/ development
for maintenance purpose. Instead, they are the #1 and necessary source of
information about what the code actually does, how, and why. I constantly run
tests, for feedback, just to check all runs fine, or diagnose what goes wrong.
Thus, the first method I write for a type if often toString; I give it a form
which tells me all I need about an object; commonly, it's just the notation to
re-create it. This, and having test in mind for writing toString, also helps in
properly defining the type itself.
For diagnosis, this information is of primordial value. And, against common
sense maybe, data about what goes right, or seems to, is commonly even more
important than data about what goes wrong, to determine the cause(s). (*)
Remedy: verbose asserts on request.
* What are those '// for diagnose' statement?
Since the test func has a form of loop over a test suite, a failing assert
would fail (!) to tell which case is in cause, instead miserably spitting out a
line number only. To get the proper info, I just need to comment out those few
lines of code, which would output for instance (artificial failure case):
...
`[nil false true]` -- [nil false true]
`[a ab abc]` -- [a ab abc]
`[[3] [3 2] [3 1 2]]` -- [[3] [3 2] [3 1 2]]
*** error *** expected: [[3] [32] [3 1 2]]
Remedy: improved assertion failure message form.
* Why string'ed results?
In this case, like in many others due to various reasons, it's uneasy to write
correct result objects; instead I would spend much stupid time in trying to
construct by hand portions of ASTs. But I have just what I need already: normal
runs of unitests in verbose mode write them out for me. Once I'm convinced, as
much as possible, all works fine, I just copy paste result /strings/ into
assert statements.
Then only I activate said assertions and switch verbose mode off, thus getting
a regression test suite for free. Even better, this test suite holds
information providing code, ready to use in case of failure.
Remedy: assert converts test result to string if needed.
Summary:
1. Named unittests allowing test suites in the form of (just an example):
unittest test1 {
...
}
unittest test2 {
...
}
unittest test3 {
...
}
unittest {
test1;
test2;
test3;
}
/Unnamed/ unittests are run with --unittest. Named ones are intended to be
called from unnamed ones. Backward compatible change.
2. A variant of assert(), or better a distinct check() statement, in the form
of:
check(expression, expectation)
Separating arguments allows writing out messages like (example formats):
* case success (outcome == expectation):
expression -- outcome
bringing valuable feedback during development.
* case failure
*** test failure **
expression : expression
outcome : outcome
expectation : expectation
***
In silent mode, check() writes only in case of failure.
If the expected result is a separated argument, it is trivial for check to call
to!string on the outcome when it's not a string and the expected result is a
string; then only compare.
I guess both changes require compiler support (but may very well be wrong).
As illustrated by the example, D does not prevent one to use such testing
practices; instead, its very nice string and literal features make it far
better suited for that than any other static language I know.
Still, like Walter, I think it's important for (good) testing practices to be
supported by the language, so-to-say officially. 'unittest' itself does not
bring any feature: one could trivially have a 'test' control func intended to
be (un)commented. But the fact it's a builtin feature makes a decisive
difference; if only because it then becomes part of the D community's shared
Re: Stupid little iota of an idea
Andrej Mitrovic: I'm getting more and more convinced to join the iota camp. The new syntax barely saves any characters, and is potentially confusing. Simen kjaeraas: This is also an interesting point. If a..b were to be a separate type, opSlice would no longer need to exist, it could be a simple overload of opIndex. See the last part, about __getitem__ and slice() of Python: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=129228 Bye, bearophile
Re: tooling quality and some random rant
Nick Sabalausky Wrote: Perhaps? Well, is it or isn't it? Are we supposed to just assume that lack of use means it's actually broken and not just unpopular? Assume it's broken or demonstrate large projects written in D to show that it CAN be unpopular because something else makes up for it. Just like you're doing? If you're sure that .di files are broken, then *show us* how. People did - go figure. A swing of Walter's magical wand saying everything is OK! seems to suffice for fanboys. Until they disappear realizing the miasma surrounding D. Like this bloke: http://www.jfbillingsley.com/blog/?p=53 Then contribute instead of just flaming. I'm 12 years old and what is this? Your language is flawed, you don't see it - do not want.
Re: tooling quality and some random rant
On 02/13/2011 10:35 PM, Nick Sabalausky wrote: spirdenis.s...@gmail.com wrote in message news:mailman.1602.1297626622.4748.digitalmar...@puremagic.com... Also, I really miss a D for D lexical- syntactic- semantic- analyser that would produce D data structures. This would open the door hoards of projects, including tool chain elements, meta-studies on D, improvements of these basic tools (efficiency, semantis analysis), decelopment of back-ends (including studies on compiler optimisation specific to D's semantics), etc. Even more important, the whole cummunity, which is imo rather high-level, would be able to take part to such challenges, in their favorite language. Isn't is ironic D depends so much on C++, while many programmers come to D fed up with this language, presicely? DDMD: http://www.dsource.org/projects/ddmd Definitely a good thing, and more! :-) Thank your for the pointer, Nick. I will skim across the project as soon as I have some hours free. And see if --with my very limited competence in the domain-- I can contribute in any way. I have an idea for a side-feature if I can understand the produced AST: generate Types as D data structures on request (--meta), write them into a plain D module to be imported on need. A major aspect, I guess, of the 'meta' namespace discussed on this list. Denis -- _ vita es estrany spir.wikidot.com
Re: tooling quality and some random rant
Agreed. These things might make D appear like less of a joke, thus attracting more hapless users to their subsequent dismay.
Re: tooling quality and some random rant
On Sun, Feb 13, 2011 at 4:35 PM, Alan Smithee em...@example.com wrote: Nick Sabalausky Wrote: Perhaps? Well, is it or isn't it? Are we supposed to just assume that lack of use means it's actually broken and not just unpopular? Assume it's broken or demonstrate large projects written in D to show that it CAN be unpopular because something else makes up for it. How's about all of druntime (at least on my self-build Linux DMD). Then contribute instead of just flaming. I'm 12 years old and what is this? Your language is flawed, you don't see it - do not want. Honestly, I agree with Nick here (which is somewhat rare, actually): You're in the D mailing lists and you don't want to use D. Why, then, are you here?
Re: d-programming-language.org
Gölgeliyele wrote: Can the D logo (as in the github site: https://secure.gravatar.com/avatar/1fe90c0586802aee103ff9ac0b8f3fbe?s=140d=https://github.com%2Fimages%2Fgravatars%2Fgravatar-140.png) located on the left top area where the digital mars logo used to sit? the empty space looks a little strange. I agree it should use the D logo.
Re: tooling quality and some random rant
On 2011-02-13 16:37:19 -0500, Walter Bright newshou...@digitalmars.com said: Michel Fortin wrote: Parsing error messages is a problem indeed. But demangling symbol names is easy. Demangling doesn't get us where golgeliyele wants to go. Correct. But note I was replying to your reply to Denis who asked specifically for demangled names for missing symbols. This by itself would be a useful improvement. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: inlining or not inlining...
so wrote: If you are against this reasoning, i don't have any idea why D has inline assembly, which again targets a very small audience. The inline assembler is s much easier to deal with than the miserable, fugly assemblers found on the various systems. The Linux as assembler is designed to crush all the joy out of writing in asm. The Microsoft assemblers change behavior constantly, breaking everything. The inline assembler can't do everything a standalone assembler can, but what it does it does well enough, and is a pleasure (to me) to use.
Re: tooling quality and some random rant
Michel Fortin wrote: But note I was replying to your reply to Denis who asked specifically for demangled names for missing symbols. This by itself would be a useful improvement. I agree with that, but there's a caveat. I did such a thing years ago for C++ and Optlink. Nobody cared, including the people who asked for that feature. It's a bit demotivating to bother doing that again.
Re: tooling quality and some random rant
On 2/13/2011 3:01 PM, Walter Bright wrote: Michel Fortin wrote: But note I was replying to your reply to Denis who asked specifically for demangled names for missing symbols. This by itself would be a useful improvement. I agree with that, but there's a caveat. I did such a thing years ago for C++ and Optlink. Nobody cared, including the people who asked for that feature. It's a bit demotivating to bother doing that again. No offense, but this argument gets kinda old and it's incredibly weak. Today's tooling expectations are higher. The audience isn't the same. And clearly people are asking for it. Even the past version of it I highly doubt no one cared, you just didn't hear from those that liked it. After all, few people go out of their way to talk about what they like, just what they don't. Later, Brad
Re: tooling quality and some random rant
Sun, 13 Feb 2011 15:06:46 -0800, Brad Roberts wrote: On 2/13/2011 3:01 PM, Walter Bright wrote: Michel Fortin wrote: But note I was replying to your reply to Denis who asked specifically for demangled names for missing symbols. This by itself would be a useful improvement. I agree with that, but there's a caveat. I did such a thing years ago for C++ and Optlink. Nobody cared, including the people who asked for that feature. It's a bit demotivating to bother doing that again. No offense, but this argument gets kinda old and it's incredibly weak. Today's tooling expectations are higher. The audience isn't the same. And clearly people are asking for it. Even the past version of it I highly doubt no one cared, you just didn't hear from those that liked it. After all, few people go out of their way to talk about what they like, just what they don't. Half of the readers have already added me to their killfile, but here goes some on-topic humor: http://www.winandmac.com/wp-content/uploads/2010/03/ipad-hp-fail.jpg Sometimes people don't yet know what they want. For example the reason we write portable C++ in some projects is that it's easier to switch between VC++, ICC, GCC, and LLVM. Whichever produces best performing code. Unfortunately DMC is always out of the question because the performance is 10-20 behind competition, fast compilation won't help it.
Re: inlining or not inlining...
Walter: The inline assembler can't do everything a standalone assembler can, but what it does it does well enough, and is a pleasure (to me) to use. The D inline assembler has another purpose you have not underlined: it's a didactic tool to learn some assembly without nothing but the normal D compiler. Delphi too allows inline asm, and I know some people that have used just that to learn and use assembly. The evolution of species is not a constant flow of changes. After a period of quick change, species often froze in many of their characteristics, and then they adapt only in a small ways, or in alternative ways, while keeping most of their original design. In the meantime new species branch sideways, and most of the actual fundamental changes happen during this side branching. To me something quite similar seems to happen to software technology: people that program in assembly seems furiously attached to ancient ways to use assembly, even if new and new languages and their ecosystems have invented better and better ways to program. There is not much intrinsic in the asm language that forces people to not define and use a good type system on asm instructions to catch programming bugs, to indent asm code well, to use a modern IDE on asm code, and so on. But most asm programmers seem uninterested in those new tools and new possibilities. All this is quite fascinating. Bye, bearophile
Re: inlining or not inlining...
bearophile wrote: There is not much intrinsic in the asm language that forces people to not define and use a good type system on asm instructions to catch programming bugs, to indent asm code well, to use a modern IDE on asm code, and so on. All of this has been done, and caught on to a huge degree. They called that asm+types language C (especially Digital Mars C, which has an excellent inline asm; I can't imagine I would have gotten anything done back in the day using the shitty gcc asm). Of course, we've improved upon that even more, and called it D. If you're writing any large amount assembly today, it is often because you specifically don't want those kind of things because they either get in the way or are just useless for the task at hand. For the parts when such things are desirable, you write it in C and friends.
Qt C++ GUI library is now set to die, as a result of the MS takeover
Here is a comment by Jeff_S, near the bottom of the comments re Microsoft taking over Nokia. I now worry that the wonderful Qt C++ GUI library, that Nokia now owns with it's acquisition of Trolltech a few years ago, will now founder in stagnation. The optimist in me hopes that it will ported to Win Phone 7. But the realist in me says fat chance. With this huge deal with MS, and Qt being cross platform, and MS being all about MS platforms and dev tools, Qt is now likely toast. Sad. Good thing it's open source. It will still have life as a separate open source entity, but without the paid developers at Nokia working on it, it's progress will slow dramatically. There is only so much slack the community is capable of taking up. I'm also scratching my head on this, in terms of what Nokia gets out of this. They are essentially trading a larger, more successful, more established, platform and ecosystem (Symbian) and large developer mind share, for a much smaller, much less successful, much less developer mind share platform and ecosystem (Win Phone 7 and Silverlight). original URL here see: http://www.betanews.com/joewilcox/article/Nokia-swaps-one-burning-platform-for-another-in-Microsofts-silent-takeover-of-the-Finnish-phone-maker/1297438206?awesm=betane.ws_yJutm_content=apiutm_medium=betane.ws-twitterutm_source=twitter.com cheers Nick
Qt C++ GUI library is now set to die, as a result of the MS takeover
Here is a comment by Jeff_S, near the bottom of the comments re Microsoft taking over Nokia. I now worry that the wonderful Qt C++ GUI library, that Nokia now owns with it's acquisition of Trolltech a few years ago, will now founder in stagnation. The optimist in me hopes that it will ported to Win Phone 7. But the realist in me says fat chance. With this huge deal with MS, and Qt being cross platform, and MS being all about MS platforms and dev tools, Qt is now likely toast. Sad. Good thing it's open source. It will still have life as a separate open source entity, but without the paid developers at Nokia working on it, it's progress will slow dramatically. There is only so much slack the community is capable of taking up. I'm also scratching my head on this, in terms of what Nokia gets out of this. They are essentially trading a larger, more successful, more established, platform and ecosystem (Symbian) and large developer mind share, for a much smaller, much less successful, much less developer mind share platform and ecosystem (Win Phone 7 and Silverlight). original URL here see: http://www.betanews.com/joewilcox/article/Nokia-swaps-one-burning-platform-for-another-in-Microsofts-silent-takeover-of-the-Finnish-phone-maker/1297438206?awesm=betane.ws_yJutm_content=apiutm_medium=betane.ws-twitterutm_source=twitter.com cheers Nick
Re: inlining or not inlining...
Adam D. Ruppe: All of this has been done, and caught on to a huge degree. They called that asm+types language C This is part of what I was referring to: http://www.cs.cornell.edu/talc/ Bye, bearophile
