Re: Bounty for -minimal compiler flag

2014-04-26 Thread Kagamin via Digitalmars-d-announce
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.


Re: Bounty for -minimal compiler flag

2014-03-10 Thread Rel

So? Is anyone working on these features?


Re: Bounty for -minimal compiler flag

2014-02-17 Thread Steven Schveighoffer

On Mon, 17 Feb 2014 15:12:39 -0500, Jacob Carlborg  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


Re: Bounty for -minimal compiler flag

2014-02-17 Thread Paulo Pinto

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


Re: Bounty for -minimal compiler flag

2014-02-17 Thread 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.


Re: Bounty for -minimal compiler flag

2014-02-17 Thread Jacob Carlborg

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


Re: Bounty for -minimal compiler flag

2014-02-17 Thread 1100110

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.


Re: Bounty for -minimal compiler flag

2014-02-16 Thread Paulo Pinto

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


Re: Bounty for -minimal compiler flag

2014-02-16 Thread inout

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.


Re: Bounty for -minimal compiler flag

2014-02-16 Thread 1100110

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.


Re: Bounty for -minimal compiler flag

2014-02-16 Thread Steven Schveighoffer
On Sun, 16 Feb 2014 11:18:12 -0500, Elie Morisse   
wrote:



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?


It's not a rush, it's just that Walter has better things to do. But it  
doesn't mean the feature itself is controversial.


-Steve


Re: Bounty for -minimal compiler flag

2014-02-16 Thread Steven Schveighoffer

On Sun, 16 Feb 2014 06:46:53 -0500, Jacob Carlborg  wrote:


On Sunday, 16 February 2014 at 11:43:22 UTC, Jacob Carlborg wrote:

In D1 Tango added a new method, "dispose", to Object. This method is  
called when an object is destroyed either when calling "delete" or when  
going out of scope for scope declared objects.


Forgot to say, other GC objects are still valid when this method is  
called.


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.


-Steve


Re: Bounty for -minimal compiler flag

2014-02-16 Thread Paulo Pinto

Am 16.02.2014 17:18, schrieb Elie Morisse:

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.


That is also my opinion.


Re: Bounty for -minimal compiler flag

2014-02-16 Thread Elie Morisse

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.


Re: Bounty for -minimal compiler flag

2014-02-16 Thread Denis Koroskin
On Sunday, 16 February 2014 at 05:27:07 UTC, Steven Schveighoffer 
wrote:
On Sat, 15 Feb 2014 23:53:19 -0500, Denis Koroskin 
<2kor...@gmail.com> wrote:


On Sunday, 16 February 2014 at 02:57:25 UTC, Steven 
Schveighoffer wrote:
I think that the best and quickest approach at this time is 
to disallow classes. They are not trivial. If we can figure 
out a clean way to add them back, then they can be allowed 
later.




Note that the same applies to classes with ARC (or other 
reference counting mechanism).


Right, but ARC classes would be marked differently or derive 
from a different base. Like extern(C++) classes (which actually 
should work under minimal D).


What we are debating is allowing just plain-old D classes could 
compile and be used under minimal D. I don't think that's a 
good idea.


-Steve


Oh, sorry, I thought the were discussing extern(C++) classes 
support -- those are too GC'd by default so compiled with and 
without GC require different designs and implementations.


Plain objects require Object.d, core.Mutex, ModuleInfo, TypeInfo 
and a lot of other things to support, and as such most likely 
impossible to implement preserving compatibility with "full D".


Re: Bounty for -minimal compiler flag

2014-02-16 Thread Jacob Carlborg

On Sunday, 16 February 2014 at 11:43:22 UTC, Jacob Carlborg wrote:

In D1 Tango added a new method, "dispose", to Object. This 
method is called when an object is destroyed either when 
calling "delete" or when going out of scope for scope declared 
objects.


Forgot to say, other GC objects are still valid when this method 
is called.


--
/Jacob Carlborg


Re: Bounty for -minimal compiler flag

2014-02-16 Thread Jacob Carlborg
On Sunday, 16 February 2014 at 02:57:25 UTC, Steven Schveighoffer 
wrote:


New is not the issue. The expectation, when I write my class, 
that it will be cleaned up by the GC, is the issue.


I remember this little nugget of paradox from the documentation 
of classes:


"This means that when the garbage collector calls a destructor 
for an object of a class that has members that are references 
to garbage collected objects, those references may no longer be 
valid. This means that destructors cannot reference sub 
objects. This rule does not apply to auto objects or objects 
deleted with the DeleteExpression, as the destructor is not 
being run by the garbage collector, meaning all references are 
valid."


So if you can write your class such that it will always require 
manual deletion, it's OK to refer to other GC'd objects in the 
destructor. Otherwise, it's not. Oh, and the runtime doesn't 
tell you when you're in the GC :)


This leads us to the fun problem:

1. Without a GC, a destructor is REQUIRED to clean up owned 
resources that were (likely) malloc'd.
2. With a GC, a destructor is REQUIRED to NOT clean up owned 
resources that were GC'd.


How to write such a destructor?


In D1 Tango added a new method, "dispose", to Object. This method 
is called when an object is destroyed either when calling 
"delete" or when going out of scope for scope declared objects.


--
/Jacob Carlborg


Re: Bounty for -minimal compiler flag

2014-02-15 Thread Steven Schveighoffer
On Sat, 15 Feb 2014 23:53:19 -0500, Denis Koroskin <2kor...@gmail.com>  
wrote:



On Sunday, 16 February 2014 at 02:57:25 UTC, Steven Schveighoffer wrote:
I think that the best and quickest approach at this time is to disallow  
classes. They are not trivial. If we can figure out a clean way to add  
them back, then they can be allowed later.




Note that the same applies to classes with ARC (or other reference  
counting mechanism).


Right, but ARC classes would be marked differently or derive from a  
different base. Like extern(C++) classes (which actually should work under  
minimal D).


What we are debating is allowing just plain-old D classes could compile  
and be used under minimal D. I don't think that's a good idea.


-Steve


Re: Bounty for -minimal compiler flag

2014-02-15 Thread Rory McGuire
+1 especially if it shows the amount allocated as well.
On 14 Feb 2014 21:10, "Kagamin"  wrote:

> I don't think, everything should be done by the compiler. Most trouble
> with gc is that its usage can't be traced similar to tls, so the feature
> will be diagnostics similar to -vtls option, say, -vminimal. The compiler
> can write the trace of runtime usage in machine-readable format to stdout
> (format: `vminimal:feature:file:line`) and a separate frontend (stylesop)
> can analyze the trace and apply arbitrary feature usage policy. Don't
> change semantics of language constructs. The first step would be to
> implement tracing of gc usage.
>


Re: Bounty for -minimal compiler flag

2014-02-15 Thread Denis Koroskin
On Sunday, 16 February 2014 at 02:57:25 UTC, Steven Schveighoffer 
wrote:
On Sat, 15 Feb 2014 07:33:04 -0500, Jakob Ovrum 
 wrote:


On Friday, 14 February 2014 at 15:56:16 UTC, Steven 
Schveighoffer wrote:
Classes are typically written with an expectation that the GC 
will clean them up. I don't think you can just get rid of 
that expectation. A class written without the assumption of 
the runtime is a very different object, and I would be 
hesitant to name it 'class' in D.


I recommend not supporting classes, at least for now.

-Steve


This applies to the `new` operator, not classes in general. 
Classes should be supported but not `new`.


New is not the issue. The expectation, when I write my class, 
that it will be cleaned up by the GC, is the issue.


I remember this little nugget of paradox from the documentation 
of classes:


"This means that when the garbage collector calls a destructor 
for an object of a class that has members that are references 
to garbage collected objects, those references may no longer be 
valid. This means that destructors cannot reference sub 
objects. This rule does not apply to auto objects or objects 
deleted with the DeleteExpression, as the destructor is not 
being run by the garbage collector, meaning all references are 
valid."


So if you can write your class such that it will always require 
manual deletion, it's OK to refer to other GC'd objects in the 
destructor. Otherwise, it's not. Oh, and the runtime doesn't 
tell you when you're in the GC :)


This leads us to the fun problem:

1. Without a GC, a destructor is REQUIRED to clean up owned 
resources that were (likely) malloc'd.
2. With a GC, a destructor is REQUIRED to NOT clean up owned 
resources that were GC'd.


How to write such a destructor?

But, besides that point: most classes are written expecting the 
GC to be used. They might possibly not use the new expression 
internally (or any other banned expressions by this new 
feature), and therefore compile. However, the expectation when 
writing such a class is that the GC will clean up after it. 
It's more the code that isn't there, than code that is 
forbidden.


If we allowed classes, we would have to have an "opt-in" 
mechanism, so one can indicate to the compiler that it can be 
used in this restricted mode (yes, compiler, I handle manual 
destruction properly).


I think that the best and quickest approach at this time is to 
disallow classes. They are not trivial. If we can figure out a 
clean way to add them back, then they can be allowed later.


-Steve


Note that the same applies to classes with ARC (or other 
reference counting mechanism).


Re: Bounty for -minimal compiler flag

2014-02-15 Thread Steven Schveighoffer
On Sat, 15 Feb 2014 07:33:04 -0500, Jakob Ovrum   
wrote:



On Friday, 14 February 2014 at 15:56:16 UTC, Steven Schveighoffer wrote:
Classes are typically written with an expectation that the GC will  
clean them up. I don't think you can just get rid of that expectation.  
A class written without the assumption of the runtime is a very  
different object, and I would be hesitant to name it 'class' in D.


I recommend not supporting classes, at least for now.

-Steve


This applies to the `new` operator, not classes in general. Classes  
should be supported but not `new`.


New is not the issue. The expectation, when I write my class, that it will  
be cleaned up by the GC, is the issue.


I remember this little nugget of paradox from the documentation of classes:

"This means that when the garbage collector calls a destructor for an  
object of a class that has members that are references to garbage  
collected objects, those references may no longer be valid. This means  
that destructors cannot reference sub objects. This rule does not apply to  
auto objects or objects deleted with the DeleteExpression, as the  
destructor is not being run by the garbage collector, meaning all  
references are valid."


So if you can write your class such that it will always require manual  
deletion, it's OK to refer to other GC'd objects in the destructor.  
Otherwise, it's not. Oh, and the runtime doesn't tell you when you're in  
the GC :)


This leads us to the fun problem:

1. Without a GC, a destructor is REQUIRED to clean up owned resources that  
were (likely) malloc'd.
2. With a GC, a destructor is REQUIRED to NOT clean up owned resources  
that were GC'd.


How to write such a destructor?

But, besides that point: most classes are written expecting the GC to be  
used. They might possibly not use the new expression internally (or any  
other banned expressions by this new feature), and therefore compile.  
However, the expectation when writing such a class is that the GC will  
clean up after it. It's more the code that isn't there, than code that is  
forbidden.


If we allowed classes, we would have to have an "opt-in" mechanism, so one  
can indicate to the compiler that it can be used in this restricted mode  
(yes, compiler, I handle manual destruction properly).


I think that the best and quickest approach at this time is to disallow  
classes. They are not trivial. If we can figure out a clean way to add  
them back, then they can be allowed later.


-Steve


Re: Bounty for -minimal compiler flag

2014-02-15 Thread 1100110

On 2/15/14, 4:52, Jacob Carlborg wrote:

On 2014-02-15 05:55, 1100110 wrote:


6) unittests (silent failure)


These should be kept since they can be accessed with __traits(getUnitTests)




Awesome!


Re: Bounty for -minimal compiler flag

2014-02-15 Thread Jakob Ovrum
On Friday, 14 February 2014 at 15:56:16 UTC, Steven Schveighoffer 
wrote:
Classes are typically written with an expectation that the GC 
will clean them up. I don't think you can just get rid of that 
expectation. A class written without the assumption of the 
runtime is a very different object, and I would be hesitant to 
name it 'class' in D.


I recommend not supporting classes, at least for now.

-Steve


This applies to the `new` operator, not classes in general. 
Classes should be supported but not `new`.


Re: Bounty for -minimal compiler flag

2014-02-15 Thread Jacob Carlborg

On 2014-02-15 05:55, 1100110 wrote:


6) unittests (silent failure)


These should be kept since they can be accessed with __traits(getUnitTests)

--
/Jacob Carlborg


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Leandro Lucarella
Daniel Murphy, el 14 de February a las 22:10 me escribiste:
> "1100110"  wrote in message news:tjgimnoqoflzrcrlw...@forum.dlang.org...
> 
> >I'm offering a $50 bounty on this.
> >(Preferably Bitcoins, but I'll use bountysource if desired.)
> 
> I'd say just put it on bountysource, because then there's more
> chance others will add to it.
> 
> >
> >rules:
> >Has to be called -minimal
> 
> Dealbreaker.  The description for the switch reads "prevents all use
> of features which rely on druntime" and therefore the only
> reasonable switch name is "-nodruntime" or a variation of that.

-nort for short :)

-- 
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
Ideas claras, libertad y patriotismo, para mejorar la calidad de vida;
claro que todo con mucha calidad, porque, joven, ideas claras, libertad
o patriotismo tiene cualquiera.
-- Ricardo Vaporeso


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Adam D. Ruppe

On Saturday, 15 February 2014 at 04:55:32 UTC, 1100110 wrote:
Then what I actually want is for -betterC to be cleaned up and 
renamed (and Documented!)


BTW I did *not* actually use -betterC for my minimal.zip. I've 
been playing with it a bit recently to make an even more minimal 
thing, but I'm fairly happy with how the first try turned out: it 
runs on bare (x86) metal and the test binary is < 30 KB in size. 
That's really not too bad: most the language works and some of 
the parts that don't can be fixed for small cost too.


Up from the 5 KB I have going with the -betterC thing and my 
TypeInfo patches locally (or the 3 KB with no runtime at all, but 
that means no structs either which massively sucks) but 30 KB 
isn't really that large and IMO the other parts of the language 
are worth it. Classes and exceptions are cool.



2) module constructors and destructors (silent failure)


What we should get is RTInfo for modules. Why? Then you can have 
a library module scan the modules for static ctor/dtors and issue 
a static assert failure. No compiler switch needed, we can do 
custom project rules. Works in regular D too, totally awesome.


Re: Bounty for -minimal compiler flag

2014-02-14 Thread 1100110

On 2/14/14, 22:44, Adam D. Ruppe wrote:

On Saturday, 15 February 2014 at 04:34:30 UTC, 1100110 wrote:

Is it just ModuleInfo, or...?


Yeah, that's pretty much all it actually does, and it isn't quite
complete - array bounds checking for example won't work because they
depend on module info.

But I don't think they should depend on it anyway, regardless of
compiler switches.


I thought that was for the stdlib, not the runtime?


They're the same thing when they are build - druntime and phobos are
compiled together into phobos.lib. So turning them off means it won't
link it.
Damn.  I *knew* that.  I remember reading about it when linux was 
getting shared lib support.




Then if you provide an object.d in your local directory, it won't even
try to load any of the regular druntime. This is how I did it in my
minimal.zip.


Oh good.  Then what I actually want is for -betterC to be cleaned up and 
renamed (and Documented!), add compiler flags for no exceptions, no 
Object, and a way to turn the silent and link failures into compiler errors.




1) array concats. use the module memory.d instead (link failure)
2) module constructors and destructors (silent failure)
3) looping ModuleInfo without libc or bare metal (silent failure)
4) TLS variables. always use __gshared (runtime crash)
5) threads.
6) unittests (silent failure)


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Adam D. Ruppe

On Saturday, 15 February 2014 at 04:34:30 UTC, 1100110 wrote:

Is it just ModuleInfo, or...?


Yeah, that's pretty much all it actually does, and it isn't quite 
complete - array bounds checking for example won't work because 
they depend on module info.


But I don't think they should depend on it anyway, regardless of 
compiler switches.



I thought that was for the stdlib, not the runtime?


They're the same thing when they are build - druntime and phobos 
are compiled together into phobos.lib. So turning them off means 
it won't link it.


Then if you provide an object.d in your local directory, it won't 
even try to load any of the regular druntime. This is how I did 
it in my minimal.zip.


Re: Bounty for -minimal compiler flag

2014-02-14 Thread 1100110

On 2/14/14, 22:20, Adam D. Ruppe wrote:

On Saturday, 15 February 2014 at 04:13:49 UTC, 1100110 wrote:

1. Disable Garbage Collector   (suggestion: -nogc)


https://github.com/D-Programming-Language/dmd/pull/1886

Oh dmd! Why won't you build on my computer!?  Why!?




3. Disable ModuleInfo  (suggestion: -nomoduleinfo)


dmd -betterC though note
https://d.puremagic.com/issues/show_bug.cgi?id=11881


Needs a name that describes what it does, and also needs to be 
documented.  I knew it existed, but I'm a little fuzzy on what all it 
actually does.  Is it just ModuleInfo, or...?





5. Disable linking of druntime (suggestion: -nodruntime)


dmd -defaultlib= -debuglib=


I thought that was for the stdlib, not the runtime?

See? Now I know even less than I did before!
Sigh.


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Adam D. Ruppe

On Saturday, 15 February 2014 at 04:13:49 UTC, 1100110 wrote:

1. Disable Garbage Collector   (suggestion: -nogc)


https://github.com/D-Programming-Language/dmd/pull/1886


3. Disable ModuleInfo  (suggestion: -nomoduleinfo)


dmd -betterC though note 
https://d.puremagic.com/issues/show_bug.cgi?id=11881



5. Disable linking of druntime (suggestion: -nodruntime)


dmd -defaultlib= -debuglib=



Re: Bounty for -minimal compiler flag

2014-02-14 Thread 1100110

On 2/14/14, 20:40, Daniel Murphy wrote:

"Denis Koroskin"  wrote in message
news:wjdvvungwvpemwmxl...@forum.dlang.org...


I'll throw in $300 extra (maybe more), but can you please first
formalize the requirements (list of flags, and what each flag
should mean, required unittests to pass etc).


Required unittests are very helpful, specifying switch names less so.


I also think it's best to split into a few tasks (e.g. a task per
feature or compiler flag). This way it is:
- easier to verify correctness/completeness
- many people can work without interfering with each other
- easier to implement and grab a bounty


Yes.



Ok, In discussing all of this I just realize I looped all the way back 
around to pretty much Walter's original post.


I'm thinking about setting Bounties on these to start off with.
But I'll be digging through the source code tomorrow to make sure.

(the suggested switch names are just for clarity)

1. Disable Garbage Collector   (suggestion: -nogc)
Currently it's pretty difficult to know what allocates and what does 
not.  There should be a way to completely disable it, and error on 
attempted GC allocations. I would also like a method to warn on GC 
allocations (-vgc maybe?), but that is optional.


2. Disable Exceptions  (suggestion: -noexceptions)
There should be a way to completely disable Exceptions, and ensure that 
none are thrown.


3. Disable ModuleInfo  (suggestion: -nomoduleinfo)
There should be a way to disable any features that rely on ModuleInfo.

4. Disable Object  (suggestion: -noobject)
And anything that depends on it.

5. Disable linking of druntime (suggestion: -nodruntime)

Really I need to learn more about all of this to make sure what I'm 
proposing will accomplish the end goal of being able to completely 
disable druntime.  Is RTTI necessary, or should it be added to the list 
of things to disable?


You convinced me that keeping assert would be for the best, so that 
should be added under suggestions.  Classes would be nice, but there's 
always C++ classes.


I think it's very important to not change the semantics of D in any way. 
 The end goal is to have a solid, core subset of the language, 
therefore it's important that any code that compiles with these flags 
would also compile without them.


Jeez, the more I look into this, the more I realize how little I know 
about it all.


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Daniel Murphy
"Denis Koroskin"  wrote in message 
news:wjdvvungwvpemwmxl...@forum.dlang.org...



I'll throw in $300 extra (maybe more), but can you please first
formalize the requirements (list of flags, and what each flag
should mean, required unittests to pass etc).


Required unittests are very helpful, specifying switch names less so.


I also think it's best to split into a few tasks (e.g. a task per
feature or compiler flag). This way it is:
- easier to verify correctness/completeness
- many people can work without interfering with each other
- easier to implement and grab a bounty


Yes. 



Re: Bounty for -minimal compiler flag

2014-02-14 Thread Denis Koroskin

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?


I'll throw in $300 extra (maybe more), but can you please first
formalize the requirements (list of flags, and what each flag
should mean, required unittests to pass etc).

I also think it's best to split into a few tasks (e.g. a task per
feature or compiler flag). This way it is:
- easier to verify correctness/completeness
- many people can work without interfering with each other
- easier to implement and grab a bounty


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Jacob Carlborg

On 2014-02-14 22:02, Steven Schveighoffer wrote:


That's... old. Why doesn't DMD start using it? 10.7 came out in 2011.


It wasn't that old until recently, when 10.9 was released. It's the same 
as with everything else. Someone just have to commit time and implement 
it. I guess this is a bit different though, since we might need to drop 
support for 10.6.



I wasn't aware of that. One has to consider how it will be expected to
work. Most of the time, D compiles and runs unit tests if -unittest is
passed. What happens in -nodruntime -unittest?


-unittest need to be passed for __traits(getUnitTests) to return anything.


Does it just compile the
unit tests into the objects but not store the pointers since there is no
moduleinfo?


I would say so, yes.

--
/Jacob Carlborg


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Steven Schveighoffer

On Fri, 14 Feb 2014 15:39:24 -0500, Jacob Carlborg  wrote:


On 2014-02-14 16:42, Steven Schveighoffer wrote:


I'm 90% sure that MacOS does not natively support TLS, and uses the
core.Thread class to store it.


OS X support TLS natively since 10.7, but DMD still uses emulated TLS on  
OS X.


That's... old. Why doesn't DMD start using it? 10.7 came out in 2011.




Yes, this also depends on moduleinfo, like static ctor/dtor.


As I've replied to other posts, there's __traits(getUnitTests) as well.



I wasn't aware of that. One has to consider how it will be expected to  
work. Most of the time, D compiles and runs unit tests if -unittest is  
passed. What happens in -nodruntime -unittest? Does it just compile the  
unit tests into the objects but not store the pointers since there is no  
moduleinfo?


Here is a possible compromise: -unittest and -nodruntime are mutually  
exclusive. If you want to run unit tests, run with -unittest. If you want  
to run without druntime, use -nodruntime. Any code that builds under  
-nodruntime should also build without that switch.


-Steve


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Jacob Carlborg

On 2014-02-14 16:42, Steven Schveighoffer wrote:


I'm 90% sure that MacOS does not natively support TLS, and uses the
core.Thread class to store it.


OS X support TLS natively since 10.7, but DMD still uses emulated TLS on 
OS X.



Yes, this also depends on moduleinfo, like static ctor/dtor.


As I've replied to other posts, there's __traits(getUnitTests) as well.

--
/Jacob Carlborg


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Jacob Carlborg

On 2014-02-14 15:07, Daniel Murphy wrote:


It's probably platform dependent, I guess it should work everywhere that
C supports TLS.


Well, on OS X it's natively supported on since 10.7 but DMD still uses 
emulated TLS:



Dynamic cast can be disabled.


Sure, but should it be an error or be replaced with a static cast?


static this/~this is tougher.  If it is possible for it to work, then
it should.  I feel that this is more of a language feature.


These might work with init sections, but maybe not.


similarly, I'd expect scope(exit) to still work.


With no exceptions, scope(xxx) will work just fine.

Similarly, try-catch will be valid, just not throwing.


profiling and code coverage are fine left out, since other tools can
fill the same task.


Yah.


It would be nice if assert didn't depend on the runtime, but it's easy
enough to implement.  conditional, message and  exit();


mmm...


unittests are out as well.


Most likely.


Theoretically it should be possible to just disabled the ModuleInfo part 
and then use __traits(getUnitTests) instead.



I don't think it's worth throwing out assert over.  A runtime that
supported assert + Object would be about 8 lines and would IMO be
worthwhile.


Perhaps leave the assert handler, which could be overridden, which could 
default to a halt like assert(0) does in release mode?


--
/Jacob Carlborg


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Jacob Carlborg

On 2014-02-14 14:50, 1100110 wrote:


This does come with a cost.

I dont know enough about TLS to comment really. Thoughts?

Dynamic cast can be disabled.

static this/~this is tougher.  If it is possible for it to work, then it
should.


This requires ModuleInfo, if I recall correctly.


profiling and code coverage are fine left out, since other tools can
fill the same task.


Doesn't that require another flag anyway?


It would be nice if assert didn't depend on the runtime, but it's easy
enough to implement.  conditional, message and  exit();

unittests are out as well.


Theoretically it should be possible to just disabled the ModuleInfo part 
and then use __traits(getUnitTests) instead.


--
/Jacob Carlborg


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Kagamin
I don't think, everything should be done by the compiler. Most 
trouble with gc is that its usage can't be traced similar to tls, 
so the feature will be diagnostics similar to -vtls option, say, 
-vminimal. The compiler can write the trace of runtime usage in 
machine-readable format to stdout (format: 
`vminimal:feature:file:line`) and a separate frontend (stylesop) 
can analyze the trace and apply arbitrary feature usage policy. 
Don't change semantics of language constructs. The first step 
would be to implement tracing of gc usage.


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Daniel Murphy
"Steven Schveighoffer"  wrote in message 
news:op.xa929juueav7ka@stevens-macbook-pro.local...


>> static this/~this is tougher.  If it is possible for it to work, then 
>> it should.  I feel that this is more of a language feature.

>
> These might work with init sections, but maybe not.

No, static ctor/dtor is not a trivial mechanism. There is a runtime graph 
analysis to make sure there are no cycles, and then run them in the proper 
order.


I think this feature has to be disabled.


I meant that we could get something mostly working using init sections, but 
it's probably not a good idea.



>> unittests are out as well.
>
> Most likely.

Yes, this also depends on moduleinfo, like static ctor/dtor.


Same with this, not worth the hack.


>
> I'll take it you've never seen how virtual functions are implemented in 
> C? Classes are awesome.


This requires vtables and typeinfo. I've seen virtual functions 
implemented in C (back when I wrote Xt widgets). I also think that with 
D's compile-time power, one could probably recreate it using templates.


I don't want to recreate it, I want to avoid it.

The issue I have with allowing classes is the implications of classes. D 
classes are infinite-lifetime, meaning requiring GC. What we would end up 
with is classes written for the minimal no-gc version of D, and classes 
that were written to be allocated on the GC heap in full-D. And both would 
be named 'class'


This is a very good point.  extern(C++) classes do not depend on druntime, 
and currently do not have their destructors run by the GC! 



Re: Bounty for -minimal compiler flag

2014-02-14 Thread Steven Schveighoffer
On Fri, 14 Feb 2014 10:46:19 -0500, Adam D. Ruppe  
 wrote:



On Friday, 14 February 2014 at 15:34:16 UTC, Steven Schveighoffer wrote:
I think classes heavily depend on druntime, I believe Walter was  
indicating they would not be allowed (which trivially excludes class ==)


My problem with excluding them is that it isn't hard to bring in the  
druntime parts they depend on when you need it. It's not like writing a  
class is a hidden feature - you don't need the compiler to help you find  
places you used them, and the linker error about the missing functions  
are fine.


Then we can just provide class support in one module that you just start  
compiling in to opt-in to the feature.


Classes are typically written with an expectation that the GC will clean  
them up. I don't think you can just get rid of that expectation. A class  
written without the assumption of the runtime is a very different object,  
and I would be hesitant to name it 'class' in D.


I recommend not supporting classes, at least for now.

-Steve


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Rel

On Friday, 14 February 2014 at 13:04:32 UTC, 1100110 wrote:

Got any thoughts?

3. Disabling runtime type information and module information...



Re: Bounty for -minimal compiler flag

2014-02-14 Thread Adam D. Ruppe
On Friday, 14 February 2014 at 15:34:16 UTC, Steven Schveighoffer 
wrote:
I think classes heavily depend on druntime, I believe Walter 
was indicating they would not be allowed (which trivially 
excludes class ==)


My problem with excluding them is that it isn't hard to bring in 
the druntime parts they depend on when you need it. It's not like 
writing a class is a hidden feature - you don't need the compiler 
to help you find places you used them, and the linker error about 
the missing functions are fine.


Then we can just provide class support in one module that you 
just start compiling in to opt-in to the feature.


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Steven Schveighoffer
On Fri, 14 Feb 2014 09:07:35 -0500, Daniel Murphy  
 wrote:



"1100110"  wrote in message news:ldl6v6$255r$1...@digitalmars.com...


I dont know enough about TLS to comment really. Thoughts?


It's probably platform dependent, I guess it should work everywhere that  
C supports TLS.


I'm 90% sure that MacOS does not natively support TLS, and uses the  
core.Thread class to store it.


static this/~this is tougher.  If it is possible for it to work, then  
it should.  I feel that this is more of a language feature.


These might work with init sections, but maybe not.


No, static ctor/dtor is not a trivial mechanism. There is a runtime graph  
analysis to make sure there are no cycles, and then run them in the proper  
order.


I think this feature has to be disabled.


unittests are out as well.


Most likely.


Yes, this also depends on moduleinfo, like static ctor/dtor.


I'm unsure how useful classes will be without a GC or the runtime...
Thoughts?
I'd be fine with then being disabled.


I'll take it you've never seen how virtual functions are implemented in  
C? Classes are awesome.


This requires vtables and typeinfo. I've seen virtual functions  
implemented in C (back when I wrote Xt widgets). I also think that with  
D's compile-time power, one could probably recreate it using templates.


The issue I have with allowing classes is the implications of classes. D  
classes are infinite-lifetime, meaning requiring GC. What we would end up  
with is classes written for the minimal no-gc version of D, and classes  
that were written to be allocated on the GC heap in full-D. And both would  
be named 'class'


-Steve


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Steven Schveighoffer
On Fri, 14 Feb 2014 08:09:21 -0500, Daniel Murphy  
 wrote:


TLS, dynamic cast, profiling, static this/static ~this, assert, -cov,  
-profile, class == and synchronized all rely on druntime code.


Also, D classes will fail to link without Object.


I think classes heavily depend on druntime, I believe Walter was  
indicating they would not be allowed (which trivially excludes class ==)



Should `array.length = x` be an error or just unsafely set the length?


It should be an error, you can do this unsafely:

array = array.ptr[0..x];

-Steve


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Daniel Murphy

"1100110"  wrote in message news:ldl9fj$28g6$1...@digitalmars.com...

> I don't think it's worth throwing out assert over.  A runtime that
> supported assert + Object would be about 8 lines and would IMO be
> worthwhile.

But then where do we stop?
This is why I think it's an excellent idea to have multiple flags, or 
options, one for each thing disabled.


So you can only disable what you do not want.


'assert' is pretty fundamental (compared to something like exceptions) and 
is especially important in low-level code.  It can also be disabled 
using -release.


I guess worst case the compiler could inline it as `e || 
_whatever_the_clib_calls_on_assert_failure`



>
> This puts us in the nasty situation of having code behave differently
> with and without the switch.  Like dynamic cast, I'd rather it was a
> compile-time error and you had to use arr.ptr[0..newlen] instead.
>

Very Very good point there.  I didn't think about that.  Code should not 
behave any differently with different switches.  Period.  I seriously 
doubt it would make it into the repo either.


Hmm, I forgot about new and delete.  They would be nice to have as wrappers 
around malloc, but that would change the meaning of code... 



Re: Bounty for -minimal compiler flag

2014-02-14 Thread 1100110

On 2/14/14, 8:07, Daniel Murphy wrote:

"1100110"  wrote in message news:ldl6v6$255r$1...@digitalmars.com...


I dont know enough about TLS to comment really. Thoughts?


It's probably platform dependent, I guess it should work everywhere that
C supports TLS.


Dynamic cast can be disabled.


Sure, but should it be an error or be replaced with a static cast?


static this/~this is tougher.  If it is possible for it to work, then
it should.  I feel that this is more of a language feature.


These might work with init sections, but maybe not.


similarly, I'd expect scope(exit) to still work.


With no exceptions, scope(xxx) will work just fine.

Similarly, try-catch will be valid, just not throwing.


profiling and code coverage are fine left out, since other tools can
fill the same task.


Yah.


It would be nice if assert didn't depend on the runtime, but it's easy
enough to implement.  conditional, message and  exit();


mmm...


unittests are out as well.


Most likely.


All of those are optional features really.  It would be nice to have
them, but I feel that those pretty much require a runtime, and the
whole point is to *not* require the runtime.



I don't think it's worth throwing out assert over.  A runtime that
supported assert + Object would be about 8 lines and would IMO be
worthwhile.


But then where do we stop?
This is why I think it's an excellent idea to have multiple flags, or 
options, one for each thing disabled.


So you can only disable what you do not want.



ie small enough to copy+paste into your main.d


> Also, D classes will fail to link without Object.

I'm unsure how useful classes will be without a GC or the runtime...
Thoughts?
I'd be fine with then being disabled.


I'll take it you've never seen how virtual functions are implemented in
C? Classes are awesome.


>
> Should `array.length = x` be an error or just unsafely set the length?

Unsafely set the length.
Justification:  There is no way to know whether or not you have
manually adjusted the array or not.

I see it as similar to pointer arithmetic in current D.  Whether it
works or not is dependent on the programmer.


This puts us in the nasty situation of having code behave differently
with and without the switch.  Like dynamic cast, I'd rather it was a
compile-time error and you had to use arr.ptr[0..newlen] instead.



Very Very good point there.  I didn't think about that.  Code should not 
behave any differently with different switches.  Period.  I seriously 
doubt it would make it into the repo either.


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Daniel Murphy

"1100110"  wrote in message news:ldl6v6$255r$1...@digitalmars.com...


I dont know enough about TLS to comment really. Thoughts?


It's probably platform dependent, I guess it should work everywhere that C 
supports TLS.



Dynamic cast can be disabled.


Sure, but should it be an error or be replaced with a static cast?

static this/~this is tougher.  If it is possible for it to work, then it 
should.  I feel that this is more of a language feature.


These might work with init sections, but maybe not.


similarly, I'd expect scope(exit) to still work.


With no exceptions, scope(xxx) will work just fine.

Similarly, try-catch will be valid, just not throwing.

profiling and code coverage are fine left out, since other tools can fill 
the same task.


Yah.

It would be nice if assert didn't depend on the runtime, but it's easy 
enough to implement.  conditional, message and  exit();


mmm...


unittests are out as well.


Most likely.

All of those are optional features really.  It would be nice to have them, 
but I feel that those pretty much require a runtime, and the whole point 
is to *not* require the runtime.




I don't think it's worth throwing out assert over.  A runtime that supported 
assert + Object would be about 8 lines and would IMO be worthwhile.


ie small enough to copy+paste into your main.d


> Also, D classes will fail to link without Object.

I'm unsure how useful classes will be without a GC or the runtime...
Thoughts?
I'd be fine with then being disabled.


I'll take it you've never seen how virtual functions are implemented in C? 
Classes are awesome.



>
> Should `array.length = x` be an error or just unsafely set the length?

Unsafely set the length.
Justification:  There is no way to know whether or not you have manually 
adjusted the array or not.


I see it as similar to pointer arithmetic in current D.  Whether it works 
or not is dependent on the programmer.


This puts us in the nasty situation of having code behave differently with 
and without the switch.  Like dynamic cast, I'd rather it was a compile-time 
error and you had to use arr.ptr[0..newlen] instead.




Re: Bounty for -minimal compiler flag

2014-02-14 Thread 1100110

On 2/14/14, 7:09, Daniel Murphy wrote:

"1100110"  wrote in message news:ldl2pf$20b0$1...@digitalmars.com...


I want a way to disable the GC, and have the compiler verify that no
GC allocations may occur.

I want a way to disable Exceptions, and have the compiler verify that
no Exceptions may occur.



Good, this is what I had in mind.


I want a way to disable linking either the standard library and the
runtime, and be able to run a minimal D program without needing to
stub anything out manually.

The idea can be boiled down to:
> 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.


Cool.


Can you name anything I'm missing?


TLS, dynamic cast, profiling, static this/static ~this, assert, -cov,
-profile, class == and synchronized all rely on druntime code.


This does come with a cost.

I dont know enough about TLS to comment really. Thoughts?

Dynamic cast can be disabled.

static this/~this is tougher.  If it is possible for it to work, then it 
should.  I feel that this is more of a language feature.

similarly, I'd expect scope(exit) to still work.


profiling and code coverage are fine left out, since other tools can 
fill the same task.


It would be nice if assert didn't depend on the runtime, but it's easy 
enough to implement.  conditional, message and  exit();


unittests are out as well.

All of those are optional features really.  It would be nice to have 
them, but I feel that those pretty much require a runtime, and the whole 
point is to *not* require the runtime.




Also, D classes will fail to link without Object.


I'm unsure how useful classes will be without a GC or the runtime...
Thoughts?
I'd be fine with then being disabled.



Should `array.length = x` be an error or just unsafely set the length?


Unsafely set the length.
Justification:  There is no way to know whether or not you have manually 
adjusted the array or not.


I see it as similar to pointer arithmetic in current D.  Whether it 
works or not is dependent on the programmer.




Should it be ABI-compatible with normal D?
Yes.   It should be as compatible as possible.  If that is not possible, 
then C, as D is compatible with C.




If you don't have strong feelings about any of these they should still
probably be listed.




Re: Bounty for -minimal compiler flag

2014-02-14 Thread Mike

On Friday, 14 February 2014 at 12:39:11 UTC, 1100110 wrote:

Can you name anything I'm missing?



* no module info
* no runtime type info
* treat TLS as __gshared for single threaded programs

Mike



Re: Bounty for -minimal compiler flag

2014-02-14 Thread Daniel Murphy

"1100110"  wrote in message news:ldl2pf$20b0$1...@digitalmars.com...

I want a way to disable the GC, and have the compiler verify that no GC 
allocations may occur.


I want a way to disable Exceptions, and have the compiler verify that no 
Exceptions may occur.




Good, this is what I had in mind.

I want a way to disable linking either the standard library and the 
runtime, and be able to run a minimal D program without needing to stub 
anything out manually.


The idea can be boiled down to:
> 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.


Cool.


Can you name anything I'm missing?


TLS, dynamic cast, profiling, static this/static ~this, 
assert, -cov, -profile, class == and synchronized all rely on druntime code.


Also, D classes will fail to link without Object.

Should `array.length = x` be an error or just unsafely set the length?

Should it be ABI-compatible with normal D?

If you don't have strong feelings about any of these they should still 
probably be listed. 



Re: Bounty for -minimal compiler flag

2014-02-14 Thread 1100110

On 2/14/14, 5:42, Francesco Cattoglio wrote:

On Friday, 14 February 2014 at 11:28:30 UTC, 1100110 wrote:

I thought that would be best, unfortunately.

Bitcoins are nice, but bountysource is the way to go. It's both more
official and easier to contribute to the bounty.


Meh, I just have a lot more spare Bitcoins than actual money at the 
moment.  I can do both though.



I'd be fine with the switch being name -nodruntime, and honestly I
like that better.

I like it too.



I will as soon as I iron a few wrinkles.  I need to figure out if
typeinfo should be a part of this as well.


Work on the details, take your time, no hurry. I'm in for chipping
around 50$ too.



Ok.  I think It'd be best if we split this into two bounties for the 
moment.  Here are the two I think are most important.



1.  GC -- Give us a way to disable it, GC allocations will not be 
allowed, and the GC will not run.


2.  Runtime -- Give us a way to disable the stdlib and runtime 
completely, and be able to compile and link programs that do not depend 
on them.


Got any thoughts?


Re: Bounty for -minimal compiler flag

2014-02-14 Thread 1100110

On 2/14/14, 5:45, Daniel Murphy wrote:

"1100110"  wrote in message news:ldkuku$1sgt$1...@digitalmars.com...


I don't think we'll ever please everyone here.  All I'm really trying
to do by specifying the name is prevent some cutesy annoying name.


It's pretty hard to get a pull request in with a silly switch name, so I
wouldn't worry too much about that.


I'd be fine with the switch being name -nodruntime, and honestly I
like that better.


Me too!


>> 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).
>
> Make a enhancement report on bugzilla with the details.

I will as soon as I iron a few wrinkles.  I need to figure out if
typeinfo should be a part of this as well.


I strongly recommend putting only goals in the enhancement request, and
avoiding implementation details (and especially syntax) whenever possible.

Eg Struct equality requires typeinfo, but and implementation that
changed it to use templates instead would probably be fine.  The
typeinfo part is irrelevant here, you just want to avoid having to link
druntime in.

Specifying individual flags is also not recommended, because a better
interface might emerge and then the issue of whether the ER is completed
gets messy.  Instead saying "I want a way to disable just the GC" avoids
this.


Alright,
I want a way to disable the GC, and have the compiler verify that no GC 
allocations may occur.


I want a way to disable Exceptions, and have the compiler verify that no 
Exceptions may occur.


I want a way to disable linking either the standard library and the 
runtime, and be able to run a minimal D program without needing to stub 
anything out manually.



The idea can be boiled down to:

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.



Can you name anything I'm missing?



Finally, putting many things in one request discourages partial fixes,
makes discussion harder to follow, and could get complicated with a
bounty involved. (what if two people implement different parts etc)  It
would be better (IMO) to split each atomic feature into its own ER and
cross-link them, even if this means splitting the bounty across them.


Good point, I'll do that.


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Daniel Murphy

"1100110"  wrote in message news:ldkuku$1sgt$1...@digitalmars.com...

I don't think we'll ever please everyone here.  All I'm really trying to 
do by specifying the name is prevent some cutesy annoying name.


It's pretty hard to get a pull request in with a silly switch name, so I 
wouldn't worry too much about that.


I'd be fine with the switch being name -nodruntime, and honestly I like 
that better.


Me too!


>> 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).
>
> Make a enhancement report on bugzilla with the details.

I will as soon as I iron a few wrinkles.  I need to figure out if typeinfo 
should be a part of this as well.


I strongly recommend putting only goals in the enhancement request, and 
avoiding implementation details (and especially syntax) whenever possible.


Eg Struct equality requires typeinfo, but and implementation that changed it 
to use templates instead would probably be fine.  The typeinfo part is 
irrelevant here, you just want to avoid having to link druntime in.


Specifying individual flags is also not recommended, because a better 
interface might emerge and then the issue of whether the ER is completed 
gets messy.  Instead saying "I want a way to disable just the GC" avoids 
this.


Finally, putting many things in one request discourages partial fixes, makes 
discussion harder to follow, and could get complicated with a bounty 
involved. (what if two people implement different parts etc)  It would be 
better (IMO) to split each atomic feature into its own ER and cross-link 
them, even if this means splitting the bounty across them. 



Re: Bounty for -minimal compiler flag

2014-02-14 Thread Francesco Cattoglio

On Friday, 14 February 2014 at 11:28:30 UTC, 1100110 wrote:

I thought that would be best, unfortunately.
Bitcoins are nice, but bountysource is the way to go. It's both 
more official and easier to contribute to the bounty.


I'd be fine with the switch being name -nodruntime, and 
honestly I like that better.

I like it too.


I will as soon as I iron a few wrinkles.  I need to figure out 
if typeinfo should be a part of this as well.


Work on the details, take your time, no hurry. I'm in for 
chipping around 50$ too.


Re: Bounty for -minimal compiler flag

2014-02-14 Thread 1100110

On 2/14/14, 5:10, Daniel Murphy wrote:

"1100110"  wrote in message news:tjgimnoqoflzrcrlw...@forum.dlang.org...


I'm offering a $50 bounty on this.
(Preferably Bitcoins, but I'll use bountysource if desired.)


I'd say just put it on bountysource, because then there's more chance
others will add to it.


I thought that would be best, unfortunately.



rules:
Has to be called -minimal


Dealbreaker.  The description for the switch reads "prevents all use of
features which rely on druntime" and therefore the only reasonable
switch name is "-nodruntime" or a variation of that.

I don't think we'll ever please everyone here.  All I'm really trying to 
do by specifying the name is prevent some cutesy annoying name.


I'd be fine with the switch being name -nodruntime, and honestly I like 
that better.



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).


Make a enhancement report on bugzilla with the details.


I will as soon as I iron a few wrinkles.  I need to figure out if 
typeinfo should be a part of this as well.


Re: Bounty for -minimal compiler flag

2014-02-14 Thread Daniel Murphy

"1100110"  wrote in message news:tjgimnoqoflzrcrlw...@forum.dlang.org...


I'm offering a $50 bounty on this.
(Preferably Bitcoins, but I'll use bountysource if desired.)


I'd say just put it on bountysource, because then there's more chance others 
will add to it.




rules:
Has to be called -minimal


Dealbreaker.  The description for the switch reads "prevents all use of 
features which rely on druntime" and therefore the only reasonable switch 
name is "-nodruntime" or a variation of that.



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).


Make a enhancement report on bugzilla with the details. 



Re: Bounty for -minimal compiler flag

2014-02-13 Thread 1100110

On 2/14/14, 0:22, John wrote:

I haven't gone into the history, but the only thing to really object to
is 'gc' surely. Isn't the rest of it fairly innocuous?

J


On Thursday, 13 February 2014 at 23:14:20 UTC, 1100110 wrote:

1. moduleinfo
2. exception handling
3. gc
4. Object




Why object to gc? You can always simply not use it, and use only the 
flags you want.  If a library that you use uses it, you don't have to 
worry about it since it will work without the flags as well as with.


IMO this will help make it a lot easier to manage GC allocations if that 
is what you wish to do.


Re: Bounty for -minimal compiler flag

2014-02-13 Thread John
I haven't gone into the history, but the only thing to really 
object to is 'gc' surely. Isn't the rest of it fairly innocuous?


J


On Thursday, 13 February 2014 at 23:14:20 UTC, 1100110 wrote:

1. moduleinfo
2. exception handling
3. gc
4. Object