On 2/16/14, 10:18, Elie Morisse wrote:

> IMHO an approach that would not involve making a binary choice between
> "full D" and "minimal D" is to add an option to make the linker strip
> druntime and Phobos' shared libraries (or any shared library, and it's
> not specific to D btw) to the "lowest common denominator" required by a
> bunch of libraries and applications. Wouldn't that fulfill one of the
> two goals -nodruntime is trying to achieve as far as I understand
> (saving memory)?
>
> And regarding the other goal, to help porting D to other platforms a
> stub druntime would be cleaner than a hackish compiler flag that
> requires many changes to DMD.

No.  Any library compiled with -nogc will be 100% usable from a program compiled without it.  Same goes for -noexceptions, etc.

This *is* a lowest common denominator.  And as such, the lowest common denominator is fully usable from code outside the subset.

All these do is error on whatever feature they are disabling.

On Sunday, 16 February 2014 at 16:18:13 UTC, Elie Morisse wrote:
> On Thursday, 13 February 2014 at 23:14:20 UTC, 1100110 wrote:
>> I think it's about time I gave back to this wonderful community.
>>
>> I'm offering a $50 bounty on this.
>> (Preferably Bitcoins, but I'll use bountysource if desired.)
>>
>> rules:
>> Has to be called -minimal
>> Has to fulfill Walter's original post. (listed below)
>> Has to split the separate parts into different flags as well as -minimal(-nogc, -nomoduleinfo, etc. Naming is left to the implementer).
>>
>>
>> This seems to be a good idea and has lots of support from the community, would anyone like to chip in a few more bucks?
>>
>> I haven't set the bounty yet, depends on if multiple people chip in.  I'll probably set it sometime tonight.
>>
>> Let me know what y'all think, am I leaving anything out?
>> Thanks
>>
>>
>> On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
>>> I've toyed with this idea for a while, and wondered what the interest there is in something like this.
>>>
>>> The idea is to be able to use a subset of D that does not require any of druntime or phobos - it can be linked merely with the C standard library. To that end, there'd be a compiler switch (-betterC) which would enforce the subset.
>>>
>>> (First off, I hate the name "better C", any suggestions?)
>>>
>>> The subset would disallow use of any features that rely on:
>>>
>>> 1. moduleinfo
>>> 2. exception handling
>>> 3. gc
>>> 4. Object
>>>
>>> I've used such a subset before when bringing D up on a new platform, as the new platform didn't have a working phobos.
>>>
>>> What do you think?
>
> Isn't this a bit premature?
>
> The idea is controversial, if you read the thread Andrei and Walter wanted to postpone it:
>
>>I convinced Walter of my view on this, so he won't work on it. I trust
> that at least between the two of us we can focus on working on what
> matters most first.
>>
>>Andrei
>
> so why the hurry?
>
>
> std.allocator should solve the biggest issue which is not making the GC mandatory, and then I don't see the point of stripping D of many of its essential features (classes, array operations, TLS, dynamic casts, static ctors and dtors, ...) when GDC and LDC are already able to enable them (i.e add parts of druntime and Phobos to the binary) on a per-needed basis when statically linking.
>
> IMHO an approach that would not involve making a binary choice between "full D" and "minimal D" is to add an option to make the linker strip druntime and Phobos' shared libraries (or any shared library, and it's not specific to D btw) to the "lowest common denominator" required by a bunch of libraries and applications. Wouldn't that fulfill one of the two goals -nodruntime is trying to achieve as far as I understand (saving memory)?
>
> And regarding the other goal, to help porting D to other platforms a stub druntime would be cleaner than a hackish compiler flag that requires many changes to DMD.

This is wrong in many levels:
a) Walter/Andrei effort vs community effort. It is very important
to have community goals/tasks, and this is a good one
b) Allocator design has nothing to do with e.g. avoiding
TypeInfo/ModuleInfo. Writing code that depends on nothing but C
runtime would allow writing code that is designed to run in C
environment (e.g. Python extensions).
c) "minimal D" may help simplify bootstrapping, ease porting D to
new platforms, open new opportunities for embedded development
with its lower footprint etc.

On Sunday, 16 February 2014 at 23:40:58 UTC, 1100110 wrote:
> On 2/16/14, 10:18, Elie Morisse wrote:
>
>> IMHO an approach that would not involve making a binary choice between
>> "full D" and "minimal D" is to add an option to make the linker strip
>> druntime and Phobos' shared libraries (or any shared library, and it's
>> not specific to D btw) to the "lowest common denominator" required by a
>> bunch of libraries and applications. Wouldn't that fulfill one of the
>> two goals -nodruntime is trying to achieve as far as I understand
>> (saving memory)?
>>
>> And regarding the other goal, to help porting D to other platforms a
>> stub druntime would be cleaner than a hackish compiler flag that
>> requires many changes to DMD.
>
> No.  Any library compiled with -nogc will be 100% usable from a program compiled without it.  Same goes for -noexceptions, etc.
>
> This *is* a lowest common denominator.  And as such, the lowest common denominator is fully usable from code outside the subset.
>
> All these do is error on whatever feature they are disabling.

However I doubt the other way around will work.

Linking all those nice D libraries developed with standard D into minimal D.

But what do I know, I always enable everything in C++.

--
Paulo

On 2/17/14, 0:40, Paulo Pinto wrote:
> On Sunday, 16 February 2014 at 23:40:58 UTC, 1100110 wrote:
>> On 2/16/14, 10:18, Elie Morisse wrote:
>>
>>> IMHO an approach that would not involve making a binary choice between
>>> "full D" and "minimal D" is to add an option to make the linker strip
>>> druntime and Phobos' shared libraries (or any shared library, and it's
>>> not specific to D btw) to the "lowest common denominator" required by a
>>> bunch of libraries and applications. Wouldn't that fulfill one of the
>>> two goals -nodruntime is trying to achieve as far as I understand
>>> (saving memory)?
>>>
>>> And regarding the other goal, to help porting D to other platforms a
>>> stub druntime would be cleaner than a hackish compiler flag that
>>> requires many changes to DMD.
>>
>> No.  Any library compiled with -nogc will be 100% usable from a
>> program compiled without it.  Same goes for -noexceptions, etc.
>>
>> This *is* a lowest common denominator.  And as such, the lowest common
>> denominator is fully usable from code outside the subset.
>>
>> All these do is error on whatever feature they are disabling.
>
> However I doubt the other way around will work.
>
> Linking all those nice D libraries developed with standard D into
> minimal D.
>
> But what do I know, I always enable everything in C++.
>
> --
> Paulo

Of course that wouldn't work.  It's exactly what you are trying to prevent by using this in the first place.

On 2014-02-16 21:51, Steven Schveighoffer wrote:

> Right, but there is no obligation to follow this pattern. One is free to
> just not do anything, and the GC will clean up your garbage.

I was replying to the issue that it's not possible to know in the destructor of a class if it's destroyed by the GC or by delete/scope. With Object.dispose in D1 Tango it is possible.

-- 
/Jacob Carlborg

On Monday, 17 February 2014 at 06:40:54 UTC, Paulo Pinto wrote:
> On Sunday, 16 February 2014 at 23:40:58 UTC, 1100110 wrote:
>> On 2/16/14, 10:18, Elie Morisse wrote:
>>
>>> IMHO an approach that would not involve making a binary choice between
>>> "full D" and "minimal D" is to add an option to make the linker strip
>>> druntime and Phobos' shared libraries (or any shared library, and it's
>>> not specific to D btw) to the "lowest common denominator" required by a
>>> bunch of libraries and applications. Wouldn't that fulfill one of the
>>> two goals -nodruntime is trying to achieve as far as I understand
>>> (saving memory)?
>>>
>>> And regarding the other goal, to help porting D to other platforms a
>>> stub druntime would be cleaner than a hackish compiler flag that
>>> requires many changes to DMD.
>>
>> No.  Any library compiled with -nogc will be 100% usable from a program compiled without it.  Same goes for -noexceptions, etc.
>>
>> This *is* a lowest common denominator.  And as such, the lowest common denominator is fully usable from code outside the subset.
>>
>> All these do is error on whatever feature they are disabling.
>
> However I doubt the other way around will work.
>
> Linking all those nice D libraries developed with standard D into minimal D.
>
> But what do I know, I always enable everything in C++.
>
> --
> Paulo

Note that you can disable rtti/exceptions etc in C++ (and in fact
we do that in all the companies that I have ever worked for since
around 2005). The feature is there because it's very useful.

This discussion is all about adding similar capabilities to D.

Am 17.02.2014 21:40, schrieb inout:
> On Monday, 17 February 2014 at 06:40:54 UTC, Paulo Pinto wrote:
>> On Sunday, 16 February 2014 at 23:40:58 UTC, 1100110 wrote:
>>> On 2/16/14, 10:18, Elie Morisse wrote:
>>>
>>>> IMHO an approach that would not involve making a binary choice between
>>>> "full D" and "minimal D" is to add an option to make the linker strip
>>>> druntime and Phobos' shared libraries (or any shared library, and it's
>>>> not specific to D btw) to the "lowest common denominator" required by a
>>>> bunch of libraries and applications. Wouldn't that fulfill one of the
>>>> two goals -nodruntime is trying to achieve as far as I understand
>>>> (saving memory)?
>>>>
>>>> And regarding the other goal, to help porting D to other platforms a
>>>> stub druntime would be cleaner than a hackish compiler flag that
>>>> requires many changes to DMD.
>>>
>>> No.  Any library compiled with -nogc will be 100% usable from a
>>> program compiled without it.  Same goes for -noexceptions, etc.
>>>
>>> This *is* a lowest common denominator.  And as such, the lowest
>>> common denominator is fully usable from code outside the subset.
>>>
>>> All these do is error on whatever feature they are disabling.
>>
>> However I doubt the other way around will work.
>>
>> Linking all those nice D libraries developed with standard D into
>> minimal D.
>>
>> But what do I know, I always enable everything in C++.
>>
>> --
>> Paulo
>
> Note that you can disable rtti/exceptions etc in C++ (and in fact
> we do that in all the companies that I have ever worked for since
> around 2005). The feature is there because it's very useful.
>
> This discussion is all about adding similar capabilities to D.

I know, did you read my last sentence? I usually enable everything
unless I cannot do it.

I find it a pain to mix and match third C++ libraries distributed in
binary form, exactly because of that.

That is one of the reasons behind C++'s complexity as the compilers need to tackle several flavours of the language.


--
Paulo

On Mon, 17 Feb 2014 15:12:39 -0500, Jacob Carlborg <doob@me.com> wrote:

> On 2014-02-16 21:51, Steven Schveighoffer wrote:
>
>> Right, but there is no obligation to follow this pattern. One is free to
>> just not do anything, and the GC will clean up your garbage.
>
> I was replying to the issue that it's not possible to know in the destructor of a class if it's destroyed by the GC or by delete/scope. With Object.dispose in D1 Tango it is possible.

Yes, and one can do it with a global flag too. The lack of this ability is really a terrible omission for D2.

-Steve

So? Is anyone working on these features?

On Tuesday, 18 February 2014 at 02:24:32 UTC, Steven Schveighoffer wrote:
> Yes, and one can do it with a global flag too. The lack of this ability is really a terrible omission for D2.

We have the flag - GCX.running, it's just not exposed.