digitalmars.D - Which is right?
- Andrei Alexandrescu (13/13) Feb 15 2015 We now have:
- Vladimir Panteleev (4/9) Feb 15 2015 I posted about this problem here:
- Andrei Alexandrescu (5/17) Feb 15 2015 Thanks. Could you please see to this? I'm working on getting
- H. S. Teoh via Digitalmars-d (7/24) Feb 15 2015 [...]
- Andrei Alexandrescu (18/39) Feb 15 2015 Indeed, and that doesn't help either :o). While at it, it would be great...
- H. S. Teoh via Digitalmars-d (14/41) Feb 15 2015 [...]
- Andrei Alexandrescu (19/27) Feb 15 2015 OK makes total sense, thanks. I'm on hook for it.
- H. S. Teoh via Digitalmars-d (32/43) Feb 15 2015 I thought people have been complaining about this since a long time ago?
- Andrei Alexandrescu (8/17) Feb 16 2015 I very much agree we need to get our act together, and pronto.
- deadalnix (4/19) Feb 16 2015 I've been thinking about having a sdunit utility based on
We now have: http://dlang.org/phobos-prerelease/std_algorithm.html and also http://dlang.org/phobos-prerelease/std_algorithm_package.html There are minor differences in formatting. Since std/algorithm.d was transformed into a package, std_algorithm_package.html is generated, and std_algorithm.html is old. However, there are still old links to it etc. so probably we should generate std_algorithm.html instead. Could somebody (preferably the contributor who converted std.algorithm into a package) see to this? Thanks, Andrei
Feb 15 2015
On Sunday, 15 February 2015 at 21:51:25 UTC, Andrei Alexandrescu wrote:We now have: http://dlang.org/phobos-prerelease/std_algorithm.html and also http://dlang.org/phobos-prerelease/std_algorithm_package.html There are minor differences in formatting.I posted about this problem here: http://forum.dlang.org/post/pprptmhgesszeqppohjd forum.dlang.org
Feb 15 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> On 2/15/15 2:01 PM, Vladimir Panteleev wrote:On Sunday, 15 February 2015 at 21:51:25 UTC, Andrei Alexandrescu wrote:Thanks. Could you please see to this? I'm working on getting std.experimental.allocator in reviewable form, and wherever I turn I find unrelated problems that are likely to cause trouble with 2.067. AndreiWe now have: http://dlang.org/phobos-prerelease/std_algorithm.html and also http://dlang.org/phobos-prerelease/std_algorithm_package.html There are minor differences in formatting.I posted about this problem here: http://forum.dlang.org/post/pprptmhgesszeqppohjd forum.dlang.org
Feb 15 2015
On Sun, Feb 15, 2015 at 01:51:26PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:We now have: http://dlang.org/phobos-prerelease/std_algorithm.html and also http://dlang.org/phobos-prerelease/std_algorithm_package.html There are minor differences in formatting. Since std/algorithm.d was transformed into a package, std_algorithm_package.html is generated, and std_algorithm.html is old. However, there are still old links to it etc. so probably we should generate std_algorithm.html instead. Could somebody (preferably the contributor who converted std.algorithm into a package) see to this?[...] This is not the only package with this problem; std.range and std.container also has the same issue. T -- "I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly
Feb 15 2015
On 2/15/15 3:20 PM, H. S. Teoh via Digitalmars-d wrote:On Sun, Feb 15, 2015 at 01:51:26PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:Indeed, and that doesn't help either :o). While at it, it would be great to eliminate the duplication in the makefile, e.g.: $(DOC_OUTPUT_DIR)/std_container_%.html : std/container/%.d $(STDDOC) $(DDOC) project.ddoc $(STDDOC) -Df$ $< $(DOC_OUTPUT_DIR)/std_algorithm_%.html : std/algorithm/%.d $(STDDOC) $(DDOC) project.ddoc $(STDDOC) -Df$ $< $(DOC_OUTPUT_DIR)/std_range_%.html : std/range/%.d $(STDDOC) $(DDOC) project.ddoc $(STDDOC) -Df$ $< $(DOC_OUTPUT_DIR)/std_regex_%.html : std/regex/%.d $(STDDOC) $(DDOC) project.ddoc $(STDDOC) -Df$ $< There must be a simple way to handle all packages in std/ in a uniform manner so we don't need separate definitions (STD_ALGO_MODULES, STD_RANGE_MODULES, STD_CONTAINER_MODULES... all that must go away). In brief the handling of packages in std/ needs some serious TLC, and quickly - before 2.067. As I vaguely recall you (H.S. Teoh) did most of the package-ing, would it be reasonable to kindly ask you to take this? AndreiWe now have: http://dlang.org/phobos-prerelease/std_algorithm.html and also http://dlang.org/phobos-prerelease/std_algorithm_package.html There are minor differences in formatting. Since std/algorithm.d was transformed into a package, std_algorithm_package.html is generated, and std_algorithm.html is old. However, there are still old links to it etc. so probably we should generate std_algorithm.html instead. Could somebody (preferably the contributor who converted std.algorithm into a package) see to this?[...] This is not the only package with this problem; std.range and std.container also has the same issue.
Feb 15 2015
On Sun, Feb 15, 2015 at 03:30:19PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:On 2/15/15 3:20 PM, H. S. Teoh via Digitalmars-d wrote:[...][...] Actually, that's not quite accurate. :-P I only did std.algorithm; the rest were done by other people. I didn't even do very much as far as the makefiles were concerned; I just copy-n-pasted what std.container and std.range did. I honestly don't even understand what the makefile lines quoted above actually do (beyond a nebulous impression); I just copy-n-pasted them for std.algorithm. You might prefer to find somebody else who has a better grasp of makefile subtleties than myself for this task. ;-) T -- What do you call optometrist jokes? Vitreous humor.This is not the only package with this problem; std.range and std.container also has the same issue.Indeed, and that doesn't help either :o). While at it, it would be great to eliminate the duplication in the makefile, e.g.: $(DOC_OUTPUT_DIR)/std_container_%.html : std/container/%.d $(STDDOC) $(DDOC) project.ddoc $(STDDOC) -Df$ $< $(DOC_OUTPUT_DIR)/std_algorithm_%.html : std/algorithm/%.d $(STDDOC) $(DDOC) project.ddoc $(STDDOC) -Df$ $< $(DOC_OUTPUT_DIR)/std_range_%.html : std/range/%.d $(STDDOC) $(DDOC) project.ddoc $(STDDOC) -Df$ $< $(DOC_OUTPUT_DIR)/std_regex_%.html : std/regex/%.d $(STDDOC) $(DDOC) project.ddoc $(STDDOC) -Df$ $< There must be a simple way to handle all packages in std/ in a uniform manner so we don't need separate definitions (STD_ALGO_MODULES, STD_RANGE_MODULES, STD_CONTAINER_MODULES... all that must go away). In brief the handling of packages in std/ needs some serious TLC, and quickly - before 2.067. As I vaguely recall you (H.S. Teoh) did most of the package-ing, would it be reasonable to kindly ask you to take this?
Feb 15 2015
On 2/15/15 3:38 PM, H. S. Teoh via Digitalmars-d wrote:Actually, that's not quite accurate.:-P I only did std.algorithm; the rest were done by other people. I didn't even do very much as far as the makefiles were concerned; I just copy-n-pasted what std.container and std.range did. I honestly don't even understand what the makefile lines quoted above actually do (beyond a nebulous impression); I just copy-n-pasted them for std.algorithm. You might prefer to find somebody else who has a better grasp of makefile subtleties than myself for this task.;-)OK makes total sense, thanks. I'm on hook for it. Loosely related: we need to raise the review scrutiny so we make sure issues like this are detected before they make it into the repository. It's inefficient to pull work that makes progress in one dimension but sets us back in another, just to require clean up afterwards. I'm trying to just clean my plate before getting into std.experimental.allocator and I got to say it's quite discouraging: * We have the fastest compiler _and_ language in the world, yet it's impossible to unittest one module; unittesting one requires building a ton of unrelated stuff, which takes a long time. * Documentation build dependencies are wrongly set up; after changing one std module, trying to rebuild dlang.org doesn't "get" it. You need to rebuild html in phobos with some arcane command line. * Don't get me started about the ddox build. Right now the building and testing rig is quite suboptimal for significant phobos work. Worst of all, all of these issues were solved earlier. I'll do my part by increasing review scrutiny. Andrei
Feb 15 2015
On Sun, Feb 15, 2015 at 04:02:30PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...]* We have the fastest compiler _and_ language in the world, yet it's impossible to unittest one module; unittesting one requires building a ton of unrelated stuff, which takes a long time.I thought people have been complaining about this since a long time ago? That they wanted more control over unittesting? That compiling user code with -unittest also activates unittest blocks in 3rd party library code? I guess it's about time to get our act together and fix that...* Documentation build dependencies are wrongly set up; after changing one std module, trying to rebuild dlang.org doesn't "get" it. You need to rebuild html in phobos with some arcane command line.Welcome to the wonderfully simple world of makefiles. (Except when it's not.) :-P* Don't get me started about the ddox build. Right now the building and testing rig is quite suboptimal for significant phobos work. Worst of all, all of these issues were solved earlier. I'll do my part by increasing review scrutiny.[...] I know I'm biased, but these kinds of issues are exactly why I don't like makefiles, and especially the fact that current makefiles have out-of-tree dependencies. Those things may work reasonably well at first, but they inevitably, inescapably, drift towards becoming a hairball of unmaintainable mess. Eventually, to deal with the mess, you end up reinventing what so many make alternatives have already done, years ago. Dmitry recently was working on implementing some SCons scripts for the D repos, but nooo, we can't get rid of makefiles 'cos they are "universal" and everybody knows them and we don't like to change old habits and we just plain like makefiles. Sigh. But ranting aside, it would be good to draft up an official Phobos contributors' guidelines page (or update an existing one if it already exists, and put it in a place where people can actually find it, since I don't even know if such a thing exists and I've been contributing to Phobos for quite some time -- the only thing I know of is the coding style guidelines). Many common items belong there, like linking to the style guidelines, correct trusted usage, needing ddoc'd unittests, coverage expectations, updating doc headers, updating makefiles (including win32.mak and win64.mak, that often get neglected), updating dlang.org for when the navbar needs to be updated, etc., etc.. T -- Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel
Feb 15 2015
On 2/15/15 10:19 PM, H. S. Teoh via Digitalmars-d wrote:On Sun, Feb 15, 2015 at 04:02:30PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...]I very much agree we need to get our act together, and pronto. Using make is really low on our list of issues. It's always easy to blame the tools or politicize the matter ("W&A are set in their ways and use that crappy make instead of $BUILD_TOOL"). The reality is we need to raise the quality of contributions. To do so, we need better reviews that transform pull requests from good to great. Andrei* We have the fastest compiler _and_ language in the world, yet it's impossible to unittest one module; unittesting one requires building a ton of unrelated stuff, which takes a long time.I thought people have been complaining about this since a long time ago? That they wanted more control over unittesting? That compiling user code with -unittest also activates unittest blocks in 3rd party library code? I guess it's about time to get our act together and fix that...
Feb 16 2015
On Monday, 16 February 2015 at 06:21:22 UTC, H. S. Teoh wrote:On Sun, Feb 15, 2015 at 04:02:30PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...]I've been thinking about having a sdunit utility based on libd/libd-llvm that would jit unittests in a module and run them. I don't have the bandwidth at this point.* We have the fastest compiler _and_ language in the world, yet it's impossible to unittest one module; unittesting one requires building a ton of unrelated stuff, which takes a long time.I thought people have been complaining about this since a long time ago? That they wanted more control over unittesting? That compiling user code with -unittest also activates unittest blocks in 3rd party library code? I guess it's about time to get our act together and fix that...
Feb 16 2015