Re: Accessing Private Fields from Outside
On 5/18/11 5:30 AM, Jacob Carlborg wrote: You can have a look at my serialization library, Orange: http://www.dsource.org/projects/orange I don't think it works with the latest compilers but you have have a look at the source: http://www.dsource.org/projects/orange/browser/orange/util/Reflection.d#L277 This is interesting. The list of limitations seem quite minimal. You mention: 'Due to several bugs in the compiler even the D2 version requires you to register a serializer when serializing through base class references' Is there a list of these bugs? Would resolving these bugs remove the need for registration functions? Would it be possible to have a library like this in Phobos? Are there any performance gotchas?
Re: Derailed (Was: "Code Sandwiches")
On 3/12/11 11:10 PM, Andrej Mitrovic wrote: On 3/13/11, Nick Sabalausky wrote: snip OSX is a nice OS. I gave it a try once or twice. The OS is nice, but man, when I started looking for software on the web I almost got sick. "Top 10 software for Your Mac", "5 Apps that will make your Mac Experience Awesome!", "This app will make you feel a Better Mac Person". "You deserve Beautiful Mac Software". If you are a linux person, you may like Mac ports. I use a large number of linux apps on my Mac, such as GIMP, GNU emacs, Inkscape, vncviewer, etc. Ugh.. It's like every single app has a 10$ price tag and it's all about selling bullshit with pretty words hidden behind colorful websites. There was a text editor that had this one major feature: Full screen mode with black side-bars. That was it. Nothing else, just a text editor with black bars on the side running at full-screen. And there's a whole website devoted to how awesome and inspiring and unique this is, how it "helps you focus". And a price tag. People buy this shit, it's unbelievable. There was also this thread on Reddit with a guy making some window-management software. All it did was divide the screen and resized the windows and put them side by side or something. And apparently this was so awesome everyone started yelling "Take my wallet NOW!!!". Same thing happened on ycombinator. I know of at least Autohotkey which came out in 2003 with which you can do window management with ease. Hotkeys, keyboard or mouse, or add buttons to your taskbar that do whatever you want with your windows. There's an entire community devoted to writing all sorts of cool window management scripts, and that's just one small feature of this app. But apparently this Mac software that resizes windows is revolutionary, comes with a price tag and everyone thought it was the best thing that ever happened.
Re: Integer conversions too pedantic in 64-bit
On 2/16/11 9:45 AM, Steven Schveighoffer wrote: I'm done with this thread... -Steve Ok, I don't want to drag on. But there is a reason why we have a style. size_t is against the D style and obviously does not match. I use size_t as much as Walter does in my day job, and I even like it. It just does not fit into D's type names. That is all.
Re: Integer conversions too pedantic in 64-bit
On 2/16/11 9:09 AM, Steven Schveighoffer wrote: On Tue, 15 Feb 2011 16:50:21 -0500, Nick Sabalausky wrote: "Nick Sabalausky" wrote in message module nick; alias size_t wordsize; Now you can use it anywhere, it's sooo freaking simple, I don't understand the outrage. But that is somewhat selfish. Given size_t causes dissatisfaction with a lot of people, people will start create their won aliases and then you end up having 5 different versions of it around. If this type is an important one for writing architecture independent code that can take advantage of architectural limits, then we better don't have 5 different names for it in common code. I don't think changing stuff like this should be distruptive. size_t can be marked deprecated and could be removed in a future release, giving people enough time to adapt. Furthermore, with the 64-bit support in dmd approaching, this is the time to do it, if ever.
Re: Integer conversions too pedantic in 64-bit
On 2/15/11 11:33 PM, Nick Sabalausky wrote: "Michel Fortin" wrote in message news:ijfhkt$1fte$1...@digitalmars.com... On 2011-02-15 22:41:32 -0500, "Nick Sabalausky" said: I like "nint". But is it unsigned or signed? Do we need 'unint' too? *shrug* Beats me. I can't even remember if size_t is signed or not. size_t is unsigned in C/C++, whereas ssize_t is signed. I like word/uword as well, but word is too common as a variable name. What about archint/uarchint ?
Re: Integer conversions too pedantic in 64-bit
On 2/15/11 12:24 PM, foobar wrote: I disagree that the discussion is pointless. On the contrary, the OP pointed out some valid points: 1. that size_t is inconsistent with D's style guide. the "_t" suffix is a C++ convention and not a D one. While it makes sense for [former?] C++ programmers it will confuse newcomers to D from other languages that would expect the language to follow its own style guide. 2. the proposed change is backwards compatible - the OP asked for an *additional* alias. 3. generic concepts should belong to the standard library and not user code which is also where size_t is already defined. IMO, we already have a byte type, it's plain common sense to extend this with a "native word" type. Look at the basic data types: bool, byte, ubyte, short, ushort, int, uint, long, ulong, cent, ucent, float, double, real, ifloat, idouble, ireal, cfloat, cdouble, creal, char, wchar, dchar While size_t is just an alias, it will be used in a similar way to the above. One can see that it does not fit among these, stylistically speaking. There seems to be a common pattern here, a prefixing character is consistently used to differentiate basic types, such as u-short/short, c-float/float, w-char/char, etc. I wonder if something similar can be done for size_t. nint comes to mind, for native int, that is n-int. Sample code: nint end = 0; // nintendo :) Having too many aliases seems like a problem to me. Different developers will start using different names and reading code will become harder. One would need to learn two things that refer to the same. My 2 cents: I suggest deprecating size_t and replacing it with a better alternative that fits with the D language.
Re: tooling quality and some random rant
On 2/14/11 3:22 PM, retard wrote: Your obsession with fast compile times is incomprehensible. It doesn't have any relevance in the projects I'm talking about. On multicore 'make - jN', distcc& low cost clusters, and incremental compilation already mitigate most of the issues. LLVM is also supposed to compile large projects faster than the 'legacy' gcc. There are also faster linkers than GNU ld. If you're really obsessed with compile times, there are far better languages such as D. The extensive optimizations and fast compile times have an inverse correlation. Of course your compiler compiles faster if it optimizes less. What's the point here? All your examples and stories are from 1980's and 1990's. Any idea how well dmc fares against latest Intel / Microsoft / GNU compilers? I work on a >1M LOC C++ project and using distcc with 4 nodes and ccache. Unfortunately, it is not enough. Yes, there are various cases where runtime performance matters a lot. But compile time performance of C++ is a huge problem. I am glad that Walter cares about this. The point about optimizations vs compile time seems to be a valid one. However, even without optimizations turned on gcc sucks big time w.r.t. compilation time. And most of the time is being spent in parsing gazillion number of headers. I did not have a chance to work with Intel's and MS's compilers.
Re: tooling quality and some random rant
On 2/13/11 2:05 PM, Walter Bright wrote: golgeliyele wrote: 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. Here is one proposal: 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 [options] D source files Options: --commandsread arguments from a command file -c, --compile only compile, do not link --coverage do code coverage analysis -D, --ddoc generate documentation --ddoc-dir write documentation file to a directory --ddoc-file write documentation file to a file -d, --deprecatedallow deprecated features --debug compile in debug code --debug-levelcompile in debug code <= level --debug-identcompile in debug code identified by ident --debug-lib set symbolic debug library to name --default-lib set default library to name --dependencieswrite module dependencies to a file --dylib generate dylib -g, --sym-debug add symbolic debug info --sym-debug-c add symbolic debug info, pretend to be C -H, --headergenerate 'header' file --header-dir write 'header' file to a directory --header-file write 'header' file to a file --help print this help -I, --imports where to look for imports --ignore-bad-pragmasignore unsupported pragmas --inlinedo function inlining -J, --string-imports where to look for string imports -L, --linker-flags pass flags to the linker --lib generate library rather than object files --man open web browser on manual page --linker-mapgenerate linker .map file --no-bounds-check turns off array bounds checking --no-float do not emit reference to floating point -O, --optimize optimize -n, --no-object-filedo not write object file --object-dir write object, library files to a directory --output name output file to a file name --no-path-strip do not strip paths from source file --profile profile runtime performance of code --quiet suppress unnecessary messages --release compile release version --runrun resulting program file, passing args --unittest compile in unit tests -v, --verbose verbose --versioncompile in version >= level --versioncompile in version identified by ident --tls-vars list all variables going into thread local storage -w, --warnings enable warnings -W, --info-warnings enable informational warnings -X, --json generate JSON file --json-file write JSON file to a given file
Re: Who here actually uses D?
"nedbrek" wrote: > > Yes, I am also using some tricks I found on the web to support building > outside of the source tree. > > I currently have all the dependendcies in one file, and regenerate manually. > I have gotten auto-dependency generation to work with C++ (it is just a > matter of breaking the dependencies into separate files). > If it is of interest, below is the makefile I have created for this purpose. It has the dependency generation built-in. The part I don't like about it is that the -deps option of dmd creates a very large file with all the dependencies, not just the one for the .d file being compiled. It is easy to filter out, but there is unnecessary IO (something you mentioned as being slow). == PHONY: all clean EXECUTABLE=foo SOURCE_DIR=source OUTPUT_DIR=output BINARY_DIR=$(OUTPUT_DIR)/bin BUILD_DIR=$(OUTPUT_DIR)/build DMD=/path/to/dmd DMD_FLAGS=-w -wi LINK_FLAGS=$(DMD_FLAGS) COMPILE_FLAGS=$(DMD_FLAGS) -I$(SOURCE_DIR) SOURCE_FILES=$(shell find $(SOURCE_DIR) -name "*.d") OBJECT_FILES=$(subst $(SOURCE_DIR), $(BUILD_DIR), \ $(SOURCE_FILES:%.d=%.o)) DEP_MAKEFILES=$(addsuffix .mk, $(OBJECT_FILES)) all: $(BINARY_DIR)/$(EXECUTABLE) $(BINARY_DIR)/$(EXECUTABLE): $(OBJECT_FILES) @echo "Linking '$@'..." @$(DMD) $(LINK_FLAGS) -of$@ $^ $(BUILD_DIR)/%.o: $(SOURCE_DIR)/%.d @echo "Compiling '$<'..." @mkdir -p `dirname $@`; \ $(DMD) $(COMPILE_FLAGS) -c -deps=$@.dep -of$@ $< && \ cat $@.dep | grep "^[^(]*($<" | \ sed 's;^.*(.*).*(\(.*\)).*;$@ : \1;' > $@.mk clean: rm -fr $(OUTPUT_DIR) -include $(DEP_MAKEFILES)
Re: Who here actually uses D?
> > I use an incremental build with Makefiles. > > Hope that helps, > Ned Hi, Can you tell me how you used incremental build with Makefiles? I don't know much about D1, but it most likely has similar module and build support as D2. I have been playing around with incremental build with dmd today (I couldn't find good info on the web). My solution was to use a makefile as well, but it required some advanced techniques, such as: - dmd compiler's -deps option to find out what are the dependencies of a module, which required simple post processing - GNU make's auto-dependency generation capabilities (mostly the ability to generate dependency stuff during make and at the same time include them into the makefile) I have too worries about this: 1) Requires experience with make and DMD, not easily gained through reading documentation 2) GNU make is not easily available on all platforms If you have a solution that is more straightforward please let me know. Also: How much time it takes for you to do a wholesale compilation versus incremental (say after changing a single file)?
Re: tooling quality and some random rant
Daniel Gibson 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
Walter Bright 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: tooling quality and some random rant
Walter Bright 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: d-programming-language.org
Can the D logo (as in the github site: https://secure.gravatar.com/avatar/1fe90c0586802aee103ff9ac0b8f3fbe?s=140&d=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
