• H. S. Teoh (33/33) Aug 08 2013 After the latest Phobos update, I can't run the Phobos unittests
• Dmitry Olshansky (12/25) Aug 10 2013 +1
• Richard Webb (5/7) Aug 12 2013 It seems ok here (on Windows, building with the new snn.lib), but it's

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

After the latest Phobos update, I can't run the Phobos unittests
anymore; std.algorithm runs out of memory.

What do you guys think?  Since we have package.d support now, I think
it's about time we split std.algorithm up into smaller pieces. As a
first stab at it, we could split it up according to the categories
already outlined in the docs: searching, comparison, iteration, sorting,
set operations, mutation. So we'd have something like:

phobos/
phobos/std/
phobos/std/algorithm
phobos/std/algorithm/package.d
phobos/std/algorithm/search.d
phobos/std/algorithm/cmp.d
phobos/std/algorithm/iter.d
phobos/std/algorithm/sort.d
phobos/std/algorithm/set.d
phobos/std/algorithm/mutation.d

(Yes I know some of you are going to complain about the naming -- the
names are not important, we can squabble over that later; what's
important is that it's time to dissect that monster called
std.algorithm.)

In addition to alleviating OOM problems, we'd also alleviate compiler
memory usage issues when compiling std.algorithm. As well as code
maintainability issues (std.algorithm is just too unwieldy right now, to
the point I tend to write new algorithm additions in a completely
separate project until it's well-tested and ready, before I put it into
std.algorithm for integration testing; it's just too painful to have to
recompile the entire std.algorithm every single code iteration).  As
well as allowing multithreaded unittest runs (this may help the
autotesters do their thing faster?).


T

-- 
Dogs have owners ... cats have staff. -- Krista Casada

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

08-Aug-2013 21:30, H. S. Teoh пишет:
 After the latest Phobos update, I can't run the Phobos unittests
 anymore; std.algorithm runs out of memory.

 What do you guys think?

+1

If the package feature is ready I think the problem should be fairly 
pull request friendly barring the usual 100-post debates on the most 
natural module names.

 In addition to alleviating OOM problems, we'd also alleviate compiler
 memory usage issues when compiling std.algorithm. As well as code
 maintainability issues (std.algorithm is just too unwieldy right now, to
 the point I tend to write new algorithm additions in a completely
 separate project until it's well-tested and ready, before I put it into
 std.algorithm for integration testing;

Amen to that. I think of splitting std.regex as well.
By the end of day module as a unit of encapsulation should have only 
what it takes to implement isolated piece of functionality. That should 
be applied Within reason obviously as packing similar stuff together 
just makes life simpler as long as file is small.

 it's just too painful to have to
 recompile the entire std.algorithm every single code iteration).  As
 well as allowing multithreaded unittest runs (this may help the
 autotesters do their thing faster?).



-- 
Dmitry Olshansky

Richard Webb <richard.webb boldonjames.com> writes:

On 08/08/2013 18:30, H. S. Teoh wrote:
 After the latest Phobos update, I can't run the Phobos unittests
 anymore; std.algorithm runs out of memory.

It seems ok here (on Windows, building with the new snn.lib), but it's 
taking measurably longer to compile the algorithm unit tests than it was 
last week (I was seeing it take about 11.2 seconds to compile, and now 
it's back to near 12 seconds) :-(