www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Bounty for -minimal compiler flag

reply "1100110" <0b1100110 gmail.com> writes:
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?
Feb 13 2014
next sibling parent reply "John" <foo foo.com> writes:
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
Feb 13 2014
parent 1100110 <0b1100110 gmail.com> writes:
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.
Feb 13 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"1100110"  wrote in message news:tjgimnoqoflzrcrlwjws 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.
Feb 14 2014
next sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On 2/14/14, 5:10, Daniel Murphy wrote:

 "1100110"  wrote in message news:tjgimnoqoflzrcrlwjws 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.
Feb 14 2014
next sibling parent reply "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
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.
Feb 14 2014
parent reply 1100110 <0b1100110 gmail.com> writes:
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?
Feb 14 2014
next sibling parent "Rel" <relmail rambler.ru> writes:
On Friday, 14 February 2014 at 13:04:32 UTC, 1100110 wrote:

 Got any thoughts?


3. Disabling runtime type information and module information...
Feb 14 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
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.
Feb 14 2014
parent Rory McGuire <rjmcguire gmail.com> writes:
+1 especially if it shows the amount allocated as well.
On 14 Feb 2014 21:10, "Kagamin" <spam here.lot> 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.
Feb 15 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Feb 14 2014
parent reply 1100110 <0b1100110 gmail.com> writes:
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.
Feb 14 2014
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Feb 14 2014
next sibling parent reply 1100110 <0b1100110 gmail.com> writes:
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.
Feb 14 2014
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Feb 14 2014
next sibling parent reply 1100110 <0b1100110 gmail.com> writes:
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.
Feb 14 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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...
Feb 14 2014
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 14 Feb 2014 09:07:35 -0500, Daniel Murphy  
<yebbliesnospam gmail.com> 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
Feb 14 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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!
Feb 14 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 14 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 14 Feb 2014 15:39:24 -0500, Jacob Carlborg <doob me.com> 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
Feb 14 2014
parent Jacob Carlborg <doob me.com> writes:
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
Feb 14 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Feb 14 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Feb 14 2014
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 14 Feb 2014 08:09:21 -0500, Daniel Murphy  
<yebbliesnospam gmail.com> 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
Feb 14 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Feb 14 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 14 Feb 2014 10:46:19 -0500, Adam D. Ruppe  
<destructionator gmail.com> 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
Feb 14 2014
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
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`.
Feb 15 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 15 Feb 2014 07:33:04 -0500, Jakob Ovrum <jakobovrum gmail.com>  
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
Feb 15 2014
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sunday, 16 February 2014 at 02:57:25 UTC, Steven Schveighoffer 
wrote:

 On Sat, 15 Feb 2014 07:33:04 -0500, Jakob Ovrum 
 <jakobovrum gmail.com> 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).
Feb 15 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 15 Feb 2014 23:53:19 -0500, Denis Koroskin <2korden 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
Feb 15 2014
parent "Denis Koroskin" <2korden gmail.com> writes:
On Sunday, 16 February 2014 at 05:27:07 UTC, Steven Schveighoffer 
wrote:

 On Sat, 15 Feb 2014 23:53:19 -0500, Denis Koroskin 
 <2korden 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".
Feb 16 2014
prev sibling parent reply "Jacob Carlborg" <doob me.com> writes:
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
Feb 16 2014
parent reply "Jacob Carlborg" <doob me.com> writes:
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
Feb 16 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 16 Feb 2014 06:46:53 -0500, Jacob Carlborg <doob me.com> 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
Feb 16 2014
parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 17 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Feb 17 2014
parent "Kagamin" <spam here.lot> writes:
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.
Apr 26 2014
prev sibling parent "Mike" <none none.com> writes:
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
Feb 14 2014
prev sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Daniel Murphy, el 14 de February a las 22:10 me escribiste:

 "1100110"  wrote in message news:tjgimnoqoflzrcrlwjws 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
Feb 14 2014
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
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
Feb 14 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Denis Koroskin"  wrote in message 
news:wjdvvungwvpemwmxlbst 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.
Feb 14 2014
parent reply 1100110 <0b1100110 gmail.com> writes:
On 2/14/14, 20:40, Daniel Murphy wrote:

 "Denis Koroskin"  wrote in message
 news:wjdvvungwvpemwmxlbst 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.
Feb 14 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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=
Feb 14 2014
parent reply 1100110 <0b1100110 gmail.com> writes:
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.
Feb 14 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Feb 14 2014
parent reply 1100110 <0b1100110 gmail.com> writes:
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)
Feb 14 2014
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Feb 14 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 15 2014
parent 1100110 <0b1100110 gmail.com> writes:
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!
Feb 15 2014
prev sibling next sibling parent reply "Elie Morisse" <syniurge gmail.com> writes:
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.
Feb 16 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
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.
Feb 16 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 16 Feb 2014 11:18:12 -0500, Elie Morisse <syniurge gmail.com>  
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
Feb 16 2014
prev sibling next sibling parent reply 1100110 <0b1100110 gmail.com> writes:
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.
Feb 16 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Feb 16 2014
next sibling parent 1100110 <0b1100110 gmail.com> writes:
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.
Feb 17 2014
prev sibling parent reply "inout" <inout gmail.com> writes:
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.
Feb 17 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
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
Feb 17 2014
prev sibling parent "inout" <inout gmail.com> writes:
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.
Feb 16 2014
prev sibling parent "Rel" <relmail rambler.ru> writes:
So? Is anyone working on these features?
Mar 10 2014