On Friday, 16 December 2011 at 09:50:30 UTC, Jonathan M Davis wrote:
> Well, both std.datetime and core.time need static this() and can't not have it.

Why are they necessary? It looks like it sets the time zone...
wouldn't it work to put that into DateTime's regular constructor?

What I have in mind is if the timezone was something along
the lines of a singleton property, so it still works
the same way, except it is lazy loaded on first use.

(if this is indeed the right static constructor!)

On Friday, December 16, 2011 16:16:53 Adam D. Ruppe wrote:
> What I have in mind is if the timezone was something along
> the lines of a singleton property, so it still works
> the same way, except it is lazy loaded on first use.
> 
> (if this is indeed the right static constructor!)

That would break purity, so no that doesn't work. The singletons are pure.

- Jonathan M Davis

On Friday, 16 December 2011 at 16:35:27 UTC, Jonathan M Davis wrote:
> That would break purity, so no that doesn't work. The singletons are pure.

I'm tempted to say just cast it away, since you aren't actually
breaking purity in any meaningful way; the return value is always
the same and it should have no other side effects (except on the
internal variable).


Lying around pure was a bit of a pain... but this seems to have
done the trick:

alias pure string function () hax;

private string impureConstructor() {
       static string cache;
       if(cache is null)
               cache = "lol pure defeated";
       return cache;
}

private pure hax getPureConstructor() { return cast(hax) &impureConstructor; }

public @system @property pure string test() {
       return getPureConstructor()();
}


// test now works

Am 16.12.2011, 04:40 Uhr, schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
> https://github.com/D-Programming-Language/phobos/commit/b7f42ec925fb1d64564d48ea419e201bfc65ed53

Yeah one could also use the new (function-)local imports.

However, this also shows another problem common to C and D: You don't get any warnings if an import is unused.
A tool that detects removable import declarations would be awesome. I wish dmd was designed modularly and as a library like Clang...

Trass3r:

> > Now using ulink the hello world exe becomes 129_564 bytes.
> 
> What is its secret?

Linkers use grey magic, as you know.
And it doesn't use compression.

Bye,
bearophile

On 12/16/11 3:49 AM, Jonathan M Davis wrote:
> On Friday, December 16, 2011 02:38:09 Andrei Alexandrescu wrote:
>> On 12/16/11 1:12 AM, Jonathan M Davis wrote:
>>> Simply making it so that std.file is only imported in std.stdio with
>>> version(unittest) cut off _that_ much?
>>
>> Yah, but the matter is more complex. The issue is that std.file pulls
>> std.datetime, which (a) has static this() code, and (b) pulls core.time,
>> which in turn has static this() code.
>>
>> The issue with that is as follows. Any file that transitively imports a
>> module with constructors will have its own module info generated. When
>> that happens, all vtables in that module will be instantiated, so all
>> methods will be linked in. That in turn causes all functions they call
>> to also be linked in.
>>
>> That's why many programs using std are large.
>>
>> We can attack this in two ways:
>>
>> 1. Revise and reduce all static this() uses in phobos and druntime;
>>
>> 2. Improve the compiler to do minimal linking when static this() does
>> come about.
>
> Well, both std.datetime and core.time need static this() and can't not have
> it.

I am pretty sure they don't need static this(). Only last night I removed static this() from core.time.

Andrei

On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote:
> On 12/16/11 3:49 AM, Jonathan M Davis wrote:
> > On Friday, December 16, 2011 02:38:09 Andrei Alexandrescu wrote:
> >> On 12/16/11 1:12 AM, Jonathan M Davis wrote:
> >>> Simply making it so that std.file is only imported in std.stdio with version(unittest) cut off _that_ much?
> >> 
> >> Yah, but the matter is more complex. The issue is that std.file pulls
> >> std.datetime, which (a) has static this() code, and (b) pulls
> >> core.time,
> >> which in turn has static this() code.
> >> 
> >> The issue with that is as follows. Any file that transitively imports
> >> a
> >> module with constructors will have its own module info generated. When
> >> that happens, all vtables in that module will be instantiated, so all
> >> methods will be linked in. That in turn causes all functions they call
> >> to also be linked in.
> >> 
> >> That's why many programs using std are large.
> >> 
> >> We can attack this in two ways:
> >> 
> >> 1. Revise and reduce all static this() uses in phobos and druntime;
> >> 
> >> 2. Improve the compiler to do minimal linking when static this() does
> >> come about.
> > 
> > Well, both std.datetime and core.time need static this() and can't not
> > have it.
> 
> I am pretty sure they don't need static this(). Only last night I
> removed static this() from core.time.

I don't know how you could do that in core.time, since ticksPerSec and appOrigin are immutable and have to be set at runtime. How on earth can you do that without a static constructor?

std.datetime has the same problem with the added fun of having to avoid breaking purity, because the functions for getting the singletons are pure.

- Jonathan M Davis

On Dec 15, 2011, at 7:40 PM, Andrei Alexandrescu wrote:

> On 12/10/11 9:39 AM, Bane wrote:
>> Short term and long term suggestions ? Anything we can do ? I heard it is some problem with linking dead code?
>> 
>> 
>> 
>> import std.stdio;
>> int main(){
>> writefln("Hello Bloat!");
>> return 0;
>> }
>> 
>> dmd -release -O hello.d
>> 
>> On Windows:
>> v1.071 = 339 Kb
>> v2.056 = 1017 Kb
>> 
>> It looks very ugly and might distract some people.
> 
> In fact there was a low-hanging fruit, and I'm sure there are some more. This diff reduces the size of hello, world (compiled with -O -release -inline and after strip) from 700KB to 220 KB:
> 
> https://github.com/D-Programming-Language/phobos/commit/b7f42ec925fb1d64564d48ea419e201bfc65ed53
> 
> Right now an executable starts at around 218KB, which includes druntime (gc, type info, the works). Importing std.stdio and using writeln() only adds a couple of KBs.

So importing std.file adds 800K to a executable?

On 12/16/11 12:40 PM, Jonathan M Davis wrote:
> On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote:
>> I am pretty sure they don't need static this(). Only last night I
>> removed static this() from core.time.
>
> I don't know how you could do that in core.time, since ticksPerSec and
> appOrigin are immutable and have to be set at runtime. How on earth can you do
> that without a static constructor?
>
> std.datetime has the same problem with the added fun of having to avoid
> breaking purity, because the functions for getting the singletons are pure.

This goes back to the issue of lazy initialization. Today you need a cast to do that. Here's my code:

    static @trusted @property long ticksPerSec() pure nothrow
    {
        return (cast(immutable(long) function() pure nothrow) &ticksPerSecImpl)();
    }

    static @property immutable(long) ticksPerSecImpl() nothrow
    {
        static long result;

        if (result)
        {
            return result;
        }

        ... initialization ...
        return result;
    }

The presence of the cast is unsightly but the code does something unusual (modifies what looks from the outside like a constant) so it is justifiable, particularly since we're talking about the language's core library.


Andrei