digitalmars.D - Splitting stdio, etc.
- Shammah Chancellor (4/4) Nov 12 2014 Will a PR for splitting stdio up into a package require a DIP? It
- Andrei Alexandrescu (20/24) Nov 12 2014 $ wc -l std/stdio.d
- Adam D. Ruppe (23/26) Nov 12 2014 I think line count shouldn't be the metric. My simpledisplay.d is
- H. S. Teoh via Digitalmars-d (10/26) Nov 12 2014 It's a legacy function that is on the way out. If it hasn't been
- H. S. Teoh via Digitalmars-d (15/42) Nov 12 2014 [...]
- Adam D. Ruppe (15/20) Nov 12 2014 I think if the imports can be localized, there's no need to split
- Andrei Alexandrescu (2/6) Nov 12 2014 The cost of D parsing is negligible in most instances. -- Andrei
- David Nadlinger (9/12) Nov 12 2014 One point that tends to be ignored every time this discussion
- Dicebot (7/16) Nov 14 2014 It is still needed because with such approach compile times can
Will a PR for splitting stdio up into a package require a DIP? It should not be a breaking change -- correct? Some of the standard module files are very substantial at this point and require quite a bit of work to compile a simple "Hello World" application.
Nov 12 2014
On 11/12/14 6:51 AM, Shammah Chancellor wrote:Will a PR for splitting stdio up into a package require a DIP? It should not be a breaking change -- correct? Some of the standard module files are very substantial at this point and require quite a bit of work to compile a simple "Hello World" application.$ wc -l std/stdio.d 4130 std/stdio.d Looks reasonably sized to me. $ wc -l std/**/*.d | sort -nr | head 212342 total 33275 std/datetime.d 14589 std/algorithm.d 10703 std/range.d 9010 std/uni.d 6540 std/math.d 6452 std/traits.d 6254 std/format.d 5235 std/typecons.d 5183 std/conv.d Better choose from these. Jonathan has long planned to break std.datetime into smaller parts, but he's as busy as the next guy so feel free to take up on that. Thanks, Andrei
Nov 12 2014
On Wednesday, 12 November 2014 at 14:59:02 UTC, Andrei
Alexandrescu wrote:
$ wc -l std/stdio.d
4130 std/stdio.d
Looks reasonably sized to me.
I think line count shouldn't be the metric. My simpledisplay.d is
almost 6,000 lines, but it compiles lightning fast and makes a
small binary. It doesn't import anything in Phobos.
When splitting a module, we need to think about independent
functionality with the goal of reducing the total number of
imports a program uses. I think local imports generally help more
than splitting modules.
So the stdio splitup would probably get the biggest gain by
making sure std.format isn't imported unless the user
specifically uses it (making sure it is localally imported in
writefln but not writeln would probably do it, since they are
templates, no need to split the module for this).
Actually, looking at the code, std.format is already a local
import, but it is in a plain function in some places, like the
private void writefx. Why is that function even there?
std.format is also imported in module scope in std.conv.... which
is imported in std.traits.
What a mess.
Bottom line, we shouldn't split up modules for its own sake. It
should be done as a step toward the larger goal of cleaning up
the import web.
Nov 12 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> On Wed, Nov 12, 2014 at 03:25:40PM +0000, Adam D. Ruppe via Digitalmars-d wrote: [...]So the stdio splitup would probably get the biggest gain by making sure std.format isn't imported unless the user specifically uses it (making sure it is localally imported in writefln but not writeln would probably do it, since they are templates, no need to split the module for this). Actually, looking at the code, std.format is already a local import, but it is in a plain function in some places, like the private void writefx. Why is that function even there?It's a legacy function that is on the way out. If it hasn't been deprecated yet, it should be, and it should be deleted within the next release or two.std.format is also imported in module scope in std.conv.... which is imported in std.traits. What a mess. Bottom line, we shouldn't split up modules for its own sake. It should be done as a step toward the larger goal of cleaning up the import web.Yeah, Ilya has been working on cleaning up imports in Phobos. Things should improve in the next release. Hopefully. T -- There are 10 kinds of people in the world: those who can count in binary, and those who can't.
Nov 12 2014
On Wed, Nov 12, 2014 at 06:59:03AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:On 11/12/14 6:51 AM, Shammah Chancellor wrote:[...] Ilya has been working on localizing imports, which will help in splitting up these modules. I've tried splitting up std.algorithm before but it was way too huge to be doable in a short amount of time (I didn't have enough free time to go through the entire module, and there were many problems with interdependencies, import dependencies, etc.). I'm thinking perhaps it should be done piecemeal -- start introducing one or two submodules under std.algorithm and rename the current algorithm.d to package.d, then gradually migrate functions over to the submodules, keeping them as public imports in package.d. T -- "A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - Natural Intelligence, Inc.Will a PR for splitting stdio up into a package require a DIP? It should not be a breaking change -- correct? Some of the standard module files are very substantial at this point and require quite a bit of work to compile a simple "Hello World" application.$ wc -l std/stdio.d 4130 std/stdio.d Looks reasonably sized to me. $ wc -l std/**/*.d | sort -nr | head 212342 total 33275 std/datetime.d 14589 std/algorithm.d 10703 std/range.d 9010 std/uni.d 6540 std/math.d 6452 std/traits.d 6254 std/format.d 5235 std/typecons.d 5183 std/conv.d Better choose from these. Jonathan has long planned to break std.datetime into smaller parts, but he's as busy as the next guy so feel free to take up on that.
Nov 12 2014
On Wednesday, 12 November 2014 at 15:34:37 UTC, H. S. Teoh via Digitalmars-d wrote:Ilya has been working on localizing imports, which will help in splitting up these modules.I think if the imports can be localized, there's no need to split the module, especially if it is template heavy like std.algorithm, which is de-facto lazy and minimal anyway - they are always imported, but the real work is only done upon being used. I *might* be wrong about the cost of parsing templates vs instantiating, I've used several thousand line programs of plain code but not that much template without pulling in all of Phobos, which makes the speed hard to isolate. But regardless, I still think we should do one thing at a time. If the cleaned up import solves the speed+size problem, no need to spend the time trying to split the module."A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'..." -LOL
Nov 12 2014
On 11/12/14 7:40 AM, Adam D. Ruppe wrote:I *might* be wrong about the cost of parsing templates vs instantiating, I've used several thousand line programs of plain code but not that much template without pulling in all of Phobos, which makes the speed hard to isolate.The cost of D parsing is negligible in most instances. -- Andrei
Nov 12 2014
On Wednesday, 12 November 2014 at 15:40:49 UTC, Adam D. Ruppe wrote:But regardless, I still think we should do one thing at a time. If the cleaned up import solves the speed+size problem, no need to spend the time trying to split the module.One point that tends to be ignored every time this discussion comes up is that of encapsulation. Since access modifiers work on a per-module basis in D, I think there is a strong incentive to making modules as small as reasonably possible by default. If a more coarse-grained structure is desired for imports from user code, one can always use package modules. David
Nov 12 2014
On Wednesday, 12 November 2014 at 15:40:49 UTC, Adam D. Ruppe wrote:On Wednesday, 12 November 2014 at 15:34:37 UTC, H. S. Teoh via Digitalmars-d wrote:It is still needed because with such approach compile times can regress easily if something gets turned from template to normal function or anything like that. Smaller modules are simply more resilient in that sense because it is easier to locate the offender.Ilya has been working on localizing imports, which will help in splitting up these modules.I think if the imports can be localized, there's no need to split the module, especially if it is template heavy like std.algorithm, which is de-facto lazy and minimal anyway - they are always imported, but the real work is only done upon being used.
Nov 14 2014