On 6/5/2013 12:47 PM, Brad Roberts wrote:
> Well, both bundle and parcel can be both nouns and verbs.

Then I propose we use the terms "dessertTopping" and "floorWax".

On Wednesday, June 05, 2013 13:37:10 Timothee Cour wrote:
> isn't that what DIP37 is supposed to address?

Yes. It will make it so that you have package.d with in the package, and it'll have public imports for all of the stuff that you want to be imported when you import the package. It also then gives you a place to document the package. Daniel Murphy has it partially implemented but still has some kinks to work out (and is busy enough at the moment that it sounds like it'll be at least a few weeks before he has the chance to work on it again).

- Jonathan M Davis

On 6/5/2013 1:29 PM, Idan Arye wrote:
> We already have that function and it's called `chunks`:

Well, we'll have to then change 'InputRange' to 'spew'.

On Wednesday, June 05, 2013 13:48:40 Walter Bright wrote:
> On 6/5/2013 11:36 AM, David Nadlinger wrote:
> > It also doesn't utilize template constraints, reinvents isRandomAccessRange && hasSlicing under a poor name,
> 
> Didn't want to include all of Phobos, which happens if you import std.range.

Which is why Dmitry was suggesting that we have separate modules for the traits rather than sticking them in the same modules as the functions.

- Jonathan M Davis

On Wednesday, June 05, 2013 20:25:44 w0rp wrote:
> An the subject of std.algorithm being very large, I realised something. Once the import change is in that makes it possible to import sub-modules all at once, there will be some nice potential for splitting up std.algorithm a bit into sub-modules, while making 'import std.algorithm' work exactly like it does now.

That was pretty much the point of DIP 37. If it was only about being able to import packages, then you could just do foo/all.d and have all.d publicly import all of the foo package - many people do this now. But DIP 37 will allow us to do this in a way which makes it possible to split up a module into a package in place without breaking code. So, we'll be able to split larger modules such as std.algorithm and std.datetime into packages without forcing everyone to change their code.

- Jonathan M Davis

06-Jun-2013 01:14, Jonathan M Davis пишет:
> On Wednesday, June 05, 2013 20:56:12 SomeDude wrote:
>> On Wednesday, 5 June 2013 at 18:36:34 UTC, David Nadlinger wrote:
>>> It also doesn't utilize template constraints, reinvents
>>> isRandomAccessRange && hasSlicing under a poor name, uses C
>>> printf (!) in the examples, has random 2-3 letter variable
>>> names (dis, dip, di, si) all over the place, …
>>>
>>> David
>>
>> Walter explained that calling printf allowed him not to import
>> half of std. I think it's a good practice to limit dependencies
>> to a reasonable minimum. Of course, it's hard to come up with a
>> general rule as to what "reasonable" means here.
>
> Given that pretty much every program is going to use std.stdio in one form or
> another,

Wrong.

> I see little point in avoiding using it.

Not pulling in a bunch of unrelated junk.

> And since it's an example,
> it makes even less sense. I would even argue that using printf is bad
> practice. writeln and writefln are properly typesafe, whereas printf is not. If
> you really actually _need_ to restrict how much you're importing, then using
> printf makes sense, but in general, it really doesn't.
>

I do agree that examples should use std.stdio writeln definetely not std.stdio. Importing it with version(unittest) or locally in each unittest is more sensible option here.

-- 
Dmitry Olshansky

06-Jun-2013 01:19, Jonathan M Davis пишет:
> On Wednesday, June 05, 2013 13:48:40 Walter Bright wrote:
>> On 6/5/2013 11:36 AM, David Nadlinger wrote:
>>> It also doesn't utilize template constraints, reinvents
>>> isRandomAccessRange && hasSlicing under a poor name,
>>
>> Didn't want to include all of Phobos, which happens if you import std.range.
>
> Which is why Dmitry was suggesting that we have separate modules for the
> traits rather than sticking them in the same modules as the functions.
>
> - Jonathan M Davis
>

After that I've been toying around with the idea of mini-phobos lately.
It's like keeping a "micro-kernel" skeleton inside of Phobos, user code doesn't have to see this. It's a bit more then just traits/non-traits separation though.

A couple of tiny functions (min/max/pointsTo/...) and a bunch of traits is all that many modules need actually if you limit their hunger for std.stdio/std.format to unittests where appropriate.


-- 
Dmitry Olshansky

06-Jun-2013 01:36, Dmitry Olshansky пишет:
> 06-Jun-2013 01:14, Jonathan M Davis пишет:
>> On Wednesday, June 05, 2013 20:56:12 SomeDude wrote:
>>> On Wednesday, 5 June 2013 at 18:36:34 UTC, David Nadlinger wrote:
>>>> It also doesn't utilize template constraints, reinvents
>>>> isRandomAccessRange && hasSlicing under a poor name, uses C
>>>> printf (!) in the examples, has random 2-3 letter variable
>>>> names (dis, dip, di, si) all over the place, …
>>>>
>>>> David
>>>
>>> Walter explained that calling printf allowed him not to import
>>> half of std. I think it's a good practice to limit dependencies
>>> to a reasonable minimum. Of course, it's hard to come up with a
>>> general rule as to what "reasonable" means here.
>>
>> Given that pretty much every program is going to use std.stdio in one
>> form or
>> another,
>
> Wrong.
>
>> I see little point in avoiding using it.
>
> Not pulling in a bunch of unrelated junk.
>
>> And since it's an example,
>> it makes even less sense. I would even argue that using printf is bad
>> practice. writeln and writefln are properly typesafe, whereas printf
>> is not. If
>> you really actually _need_ to restrict how much you're importing, then
>> using
>> printf makes sense, but in general, it really doesn't.
>>
>
> I do agree
that examples should use std.stdio writeln definetely not
> std.stdio.

Darn, should be not core.stdc printf

 Importing it with version(unittest) or locally in each
> unittest is more sensible option here.
>


-- 
Dmitry Olshansky

On Wednesday, 5 June 2013 at 21:15:06 UTC, Jonathan M Davis wrote:
> And since it's an example, it makes even less sense.

Not if you want to show off D's compile speed! On my box, compiling Walter's module with -c took:

~$ time dmd -c compress

real    0m0.032s
user    0m0.023s
sys     0m0.007s

3 hundredths of a second. (Running it over and over again gives ranges from .02 to .04).


Now if I add "import std.stdio;" to the bottom of the file, no other changes, not even using it, look at this:

$  time dmd -c compress

real    0m0.456s
user    0m0.407s
sys     0m0.041s

Over 10x as much compile time!



I used to think dmd2 broke something dmd1 got right. Every program I ever did in D1 compiled virtually instantly. A lot of times I'd hit "make" and think nothing happened because it returned so fast. Even my biggest D1 program, a 15k line little RTS game, compiles faster than the typical D2 hello world.


But I've come to see it isn't dmd2 that's slow. It is phobos2.

Compile and link time for my minimal D toy:

$ time make
dmd -version=withoaut_custom_runtime_reflection -debug=allocations -m64 -debug -c object.d minimal.d invariant.d memory.d -gc -defaultlib= -debuglib=
gcc minimal.o object.o invariant.o memory.o -o minimal -g -m64 -nostdlib

real    0m0.280s
user    0m0.240s
sys     0m0.032s

That's D2 code but no phobos. Comparable speed to D1.... and still less than an *empty* D2 file that just imports std.stdio! (0.6s to compile and run, over twice as long.)


Now, granted, this can become negligible in bigger programs. It takes about 8 seconds for my work website to compile on my computer. Most that time is spent on my web.d's template magic.

But still, if we want to show off D's compilation speed in examples, that's a good reason to avoid import std.stdio. It is the difference between noticing and not noticing the compile.

you know it might be a decent idea to change std.stdio to use scoped imports and have the writeln that specializes on string to not import anything else and see what happens on the hello world case.