Re: Bounty for -minimal compiler flag
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
So? Is anyone working on these features?
Re: Bounty for -minimal compiler flag
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
+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
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
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
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
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
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
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
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
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
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
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
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
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
"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
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
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
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
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
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
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
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
"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
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
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
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
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
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
"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
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
"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
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
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
"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
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
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
"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
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
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
"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
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
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
