Re: Errors compiling DSSS
On 2012-11-29 23:06, Rob T wrote: For the moment, let's talk about ddoc, or unit testing in D. That's the difference, it's not an external tool set, it's instead a a part of the standard language feature set. BTW, IMO ddoc was implemented poorly, using comments, which I fully agree with you would be a vary bad way to go about implementing the feature. In that case, I would rather use Ruby. The built-in support for unit testing is too simplistic. I think one needs an external tool anyway that makes use of the built-in support unit tests. I just want to be able to do something like: $ test a.d b.d And it will run all unit tests in the modules "a" and "b". In D I need to manually creating a test module which imports all modules I want to test. This will give the most basic functionality. This is a few things of that's missing: * Run a single test * Names or context for the tests * Nice report of which tests failed * Continue running other tests if a given test failed I would say that the build specific code would have to go into the main.d file, but since libraries do not have a "main" file, the build process code would have to go into another file, perhaps named "build.d", that contains the entire build section which the compiler uses to kick off the build process. The build.d files can be chained so that multiple related projects can be constructed. That's the exact same thing as I'm proposing, except it's the compiler handling it. In any event, I'd ask how do the current build systems do it? They read and parse through the source files to learn about dependencies No, they: 1. Run "$ dmd -o- -c main.d -deps=deps.txt" which will write out all dependencies of "main.d" to "deps.txt" 2. Read the "deps.txt" file and pass all files to dmd OR a programmer specifies all of it manually, which is a complete nightmare to maintain on large projects. I completely agree. Now, if things were designed correctly, I don't see why a semi-automated build, using internally specified build options for manual tweaking where needed, cannot be done with an embedded build system. If it was designed correctly the compiler would be built as a library. The build tool could the use this library to get all the dependencies of a given source file. Another analogy is to think about languages that have embedded reflection - unfortunately D currently lacks a generalized solution for reflection, but you can see hints of the potential it offers. Simplifying how builds are performed through "reflection" will increase productivity, and will potentially offer new ways of solving old problems well past what was considered possible before. Do you have any example? -- /Jacob Carlborg
Re: Errors compiling DSSS
On 2012-11-29 22:46, Andrei Alexandrescu wrote: Actually I figured it out - rdmd can simply read its own file argument and look at the shebang line. Then there's no more issue of space coalescing, line length limitations etc. I don't know if you intended to answer to my post but having a separate build system is no problem. What Gor suggested was having the build system in the compiler, that will cause problems. -- /Jacob Carlborg
Re: The future of UDAs.
On 2012-11-30 03:39, Walter Bright wrote: It's not a complete solution, since using a symbol S from module A does not necessarily mean dependency on S being statically constructed in A. But it would be a start. Well, not using any symbol from module A means it has no dependency for sure on A in the static constructor. -- /Jacob Carlborg
Re: Fixing cyclic import static construction problems
On 11/29/2012 5:51 PM, Max Samukha wrote:
On Thursday, 29 November 2012 at 15:18:11 UTC, Paulo Pinto wrote:
Maybe you care to provide an example?
The general problem is constructing global data structures based on data
introspected at compile-time.
My specific problem is extending scarce runtime type information
provided by the language with something usable for runtime reflection.
With lots of detail omitted:
module reflect;
Meta[string] metas;
mixin template Reflect(alias object) {
static this()
{
auto m = meta!(object);
metas[m.fullName] ~= m;
}
}
module a;
import reflect;
struct S
{
}
mixin Reflect!S;
The meta-object for S is automatically made available at runtime through
the global metas array. Note that we do not want to force the user to
register the meta-object manually because then it would not be a "better
architecture".
The important (Andrei somehow thinks it is not) requirement is there
must not be circular dependency issues for the users of the "reflect"
module.
How about running your own set of "constructors" searching the module
info array, searching for specific classes in the module that are added
by a mixin:
--
module register;
RegisterBase[string] registry;
void doRegister(string name, RegisterBase r) { registry[name] = r; }
class RegisterBase
{
abstract void _register();
}
template Register(string name)
{
enum string Register = "
class Register : RegisterBase
{
override void _register() { doRegister(\"" ~ name ~ "\", this);
}
}
";
}
void registerAll()
{
foreach(m; ModuleInfo)
{
TypeInfo_Class[] clss = m.localClasses();
foreach(c; clss)
{
if(c.base is RegisterBase.classinfo)
{
if(auto reg = cast(RegisterBase) c.create())
{
reg._register();
}
}
}
}
}
---
module a;
import register;
mixin(Register!"a");
---
module main;
import std.stdio;
import register;
void main()
{
registerAll();
foreach(a, o; registry)
writeln(a, " ", o);
}
This might also work for the benchmark module.
Re: Errors compiling DSSS
On Thursday, 29 November 2012 at 20:47:49 UTC, Jacob Carlborg
wrote:
What's the difference compared to any other build tool. Where
you have to learn some kind of special syntax. This is a
special syntax as well, just happens to be a real language as
well.
In D could be quite elegant. Here a simplified sample how I think
it could look like:
---
// Builder Library
module dlang.builder;
struct Target
{
string output;
string[] source;
string[] libs;
}
alias Target Executable;
alias Target StaticLib;
struct Environment
{
bool tests = false;
bool verbose = false;
string[] importDirs;
}
mixin template Builder()
{
int main(string[] args)
{
// enumerate and build the targets...
}
}
---
// build.d in project folder
#!/usr/bin/env rdmd
import dlang.builder;
// version(X) to differentiate
Environment env = {
tests: true,
verbose: true,
importDirs: ["../deimos"]
}
Executable myapp = {
output: "myapp.exe",
source: ["app/a.d", "app/b.d"],
libs: ["libutil"]
}
StaticLib libutil = {
source: ["util/*.d"]
}
mixin Builder;
invocation would be basically rdmd build.d
./build.d --variant=release --toolset=dmd_2_060
Re: D Stable Proposal
OK, first debian system is not suitable for a programing language IMO. They have to solve the exact opposite problem than ours : debian relies on programs, programs rely on programming languages. Second doing that in a separate project, with people volunteering in it is a bad idea. This increase the workload instead of decreasing it. It is beneficial for D users, but not beneficial for D devellopers, and as it is a open source project where people participate on their free time, I don't think this will work. Anyway, I don't want to discourage you because if it does work, this is awesome. I'd love to be proven wrong on that one, so if you believe in it, go for it ! Secondly, some people were talking about roadmap, people in charge and everything. This is required for very important task, but likely to fail again on a project where people participate on their free time. It would be much more beneficial to improve what occasional dev on D can do to help. We have to allow people to work on the stuff they moticate them ATM : fix a bug that occurs in their programs, learn some new area of programming, or whatever. Such thing is easier to do on something stable. Currently, to work on D, you need to know what is the current state of thing, what is the intended state, why isn't it tat way (historical reasons, difficulties of implementations, etc . . .) and new feature addition tend to continue this situation (as new bugs are introduced hen other are removed, and real profound issue get harder to solve). This is important because even if you don't use the new functionality, you don't get rid of the bugs. They'll manifest themselves because 3rd party code will use such feature.
Re: Fixing cyclic import static construction problems
On 2012-11-29 22:43, Jonathan M Davis wrote: They just let you blow your foot off. All static variables can be directly initialized at runtime, so it's easy to use variables before they're actually initialized. I don't know how they decide what order to run static constructors in, but AFAIK, it never worries about circular dependencies. We're only running into this problem beacuse we're trying to provide higher safety and better guarantees with regards to when and how variables are initialized. I see. -- /Jacob Carlborg
Re: Fixing cyclic import static construction problems
On 11/29/12 23:34, Jonathan M Davis wrote: > On Thursday, November 29, 2012 23:28:07 Timon Gehr wrote: >> On 11/29/2012 01:17 PM, Jonathan M Davis wrote: >>> In the past when I've brought up similar solutions, he's been completely >>> opposed to them. ... >> >> It is not a solution, it is a workaround. > > What do you mean? The runtime sees circular dependencies between modules even > when there's no actual circular dependency between static constructors. We > need to fix that. One way is to just make the runtime not care, which > wouldn't > be particularly safe. Another is to explicitly tell it that there are no such > dependencies. I don't see how that's not a solution. And unless someone can > come up with a way for the runtime to somehow determine on its own that > there's no actual, circular dependency, I don't see how anything better could > be done. It's relatively easy for the /compiler/ to figure it out; it's just that implementing a simple user-provided flag requires the least amount of work. What Walter suggested can be tweaked to be sane (per-ctor flag) and will still be useful if/when the compiler becomes smarter (think lazily initted module fields). For the compiler to check if the value of every imported symbol accessed inside a mod-ctor can be evaluated at compile-time (if you encounter a case where this is not true it means there (potentially) is a true dependency and the ctors should be ordered) would require more work. artur
Re: Errors compiling DSSS
On 2012-11-30 09:19, Tavi Cacina wrote:
// version(X) to differentiate
Environment env = {
tests: true,
verbose: true,
importDirs: ["../deimos"]
}
That's quite a clever syntax, but you forgot the trailing semicolon and
isn't that syntax intended to be deprecated? It's also quite limiting,
it would be nice to be able to execute arbitrary code for a given target.
--
/Jacob Carlborg
Re: D Stable Proposal
On 11/30/2012 02:22 AM, deadalnix wrote: OK, first debian system is not suitable for a programing language IMO. They have to solve the exact opposite problem than ours : debian relies on programs, programs rely on programming languages. Second doing that in a separate project, with people volunteering in it is a bad idea. This increase the workload instead of decreasing it. It is beneficial for D users, but not beneficial for D devellopers, and as it is a open source project where people participate on their free time, I don't think this will work. Anyway, I don't want to discourage you because if it does work, this is awesome. I'd love to be proven wrong on that one, so if you believe in it, go for it ! Secondly, some people were talking about roadmap, people in charge and everything. This is required for very important task, but likely to fail again on a project where people participate on their free time. It would be much more beneficial to improve what occasional dev on D can do to help. We have to allow people to work on the stuff they moticate them ATM : fix a bug that occurs in their programs, learn some new area of programming, or whatever. Such thing is easier to do on something stable. Currently, to work on D, you need to know what is the current state of thing, what is the intended state, why isn't it tat way (historical reasons, difficulties of implementations, etc . . .) and new feature addition tend to continue this situation (as new bugs are introduced hen other are removed, and real profound issue get harder to solve). This is important because even if you don't use the new functionality, you don't get rid of the bugs. They'll manifest themselves because 3rd party code will use such feature. Debian relies on third-party code. One of the major draws of a programming language is third-party code. The more libraries we support, and the easier we make D to target for stable code, the better. Sure, there are practical differences, I'm not going to deny that. But there are practical similarities as well. We should use the metaphor only as far as it works. If you want to suggest another successful system currently in use, please do. I don't want to repeat anyone else's mistakes. The most important thing right now is to come up with a system that works, and isn't a hassle for anyone. DMD developers should find it easy and useful, D users should find it easy and helpful. I'm not going to suggest that D Stable take the Debian route of requiring all third-party code be forked by us for inclusion. That's not what this should be about. As so a (very) large part of their system is currently being ignored by me. That is a task that a D package manager should deal with. We would just greatly simplify their job of making sure that the packages work where they say they should. They can make their own requirements for the actual third-party code. Walter's support is a key part of this. Scheduled releases are a must, even if there are no new features or important changes. IMO Version bump releases are fine because it is expected. Andrei's support is also necessary, IIRC he is one of main person behind phobos. A stable version of D is not useful without a stable version of phobos and druntime to go with it. Equally important is third party code. If code claims to target the current stable version of D, it should work as expected.(excepting Bugs of course, I'm not that crazy) It should be easy to tell exactly what needs to be changed in order to make it work. There should be tools that assist this process. And yes, it should be as easy as possible to contribute. One-off commits should be completely welcome, and encouraged. I would love to hear advice on how to simplify that process. Look at Dlang.org You can click a button, edit the file online, and create a pull request. I noticed a typo. I was curious as to how easy it would be to fix. I was done approximately 2 minutes later (I dawdled on the commit message). The pull was accepted a few hours later. It was beautiful. Now how can we make everything else that easy?
Re: Fixing cyclic import static construction problems
On Friday, 30 November 2012 at 01:07:57 UTC, Andrei Alexandrescu wrote: On 11/29/12 5:43 PM, Walter Bright wrote: On 11/30/2012 12:09 AM, Daniel Murphy wrote: I don't think this is sufficient. Imagine a group of modules that really _do_ have a cyclic dependency, and a mixin that adds an independent static this. Ideally you'd be able to mark the mixed-in constructor as independent without tainting the whole module. So just make the pragma apply to declarations, you either mark specific functions (which can then be mixed in) or put `pragma(...):` at the top of your module and you get your behaviour. It is possible for each static constructor to specify independently of the other static constructors which imports must be constructed first. But do we really want to go that far? I think we either do it right or leave it as it is. It's not like there's no workaround so if we take a stand here we better have something compelling. Andrei +1 FWIW, I think this proposal sounds like a massive hack. Not a fan.
Re: D Stable Proposal
My github account is eskimor. I think the model described in: http://nvie.com/posts/a-successful-git-branching-model/ is a really good one, to get started. If we want to keep changes to a minimum, then the development branch in the model could simply be the current master. The master branch in the model would be the master branch of dmd-stable. Feature branches already exist in form of pull requests. Release/hotfix branches would have to be introduced. A little education of people would be needed. (E.g. where and when to merge things, bugs/features.) Where and how changes are documented. I would volunteer to help writing an automatic upgrade tool. We should, define things there, so reports of breaking changes/deprecations, the developers provide, could then be already in a format the tool can understand. On Thu, 2012-11-29 at 23:49 -0600, 1100110 wrote: > On 11/29/2012 11:17 PM, Rob T wrote: > > On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote: > >> Let's do this thing. > > > > I can help with formulating a process and I can also help write up the > > guidelines and so forth, so I'll sign up. > > > > If we can decide on a road map and write it up, and get enough consensus > > for implementing it, then everyone will know what they should be working > > on, and also what to expect. > > > > How many people do you think we need to get started, 5 or so? > > > > --rt > > > > I've started work on the specification here > https://github.com/D-Programming-Language-Stable/dmd/wiki/Specification > > I'd like for someone else to start with the writeup, since I've pretty > much made my ideal known by this point. > > If you have a github account, give me your user name and I'll add you to > the Project. > > It'll at least give us a public place to define things for right now.
Re: D Stable Proposal
On Fri, 2012-11-30 at 07:31 +0100, Rob T wrote: > One quick suggestion before I call it a day, is for there to be > an "experimental branch" for the great minds behind D to play > around with (eg UDA's etc). We probably don't want experimental > stuff going directly into a branch that is destined for stable. > Unstable should be for items that are relatively finalized in > terms of design and agreement that the concept is to be > eventually incorporated into stable, i.e., moving a new feature > into unstable starts the refinement process towards a stable > release of that feature. Totally agreed. In the development branch only already finalized things should be merged. Having official experimental branch(es) is a good idea. I think the things people are working on should be easily accessible. So other people can contribute and test the stuff. These branches should then also be included in dpaste.dzfl.pl. Maybe a dmd-experimental project, where people can get access to, very easily. So they can push their branches there. It should be as easy for people to try out experimental things as to try out things from the development branch, to get as much early testing as possible. Automatic creation of binary releases would also be cool. So the workflow could be something like: 1. Document on a dedicated wiki page that you start working on feature X or bug fix Y. 2. Get started on a private/semipublic feature branch. 3. As soon as you got something push it to dmd-experimental 4. Continue to work and improve things there 5. Experimental branches are considered for inclusion in devel. 6. Things are tested in an integrated way in devel, with binary releases every two months or so. (Much like we have now) 7. At predefined intervals you branch of a release branch and stabilize things further. 8. Release branch is merged in dmd-stable/master Someone posted this, as why not to use feature branches: http://www.youtube.com/watch?v=xzstASOvqNc&feature=youtu.be I personally don't think that feature branches are the problem, but more a lack of communication. If people work on the same stuff you get merge conflicts, that is granted, so you should know on what people are working before starting to work. A wiki page where you add a link to your feature branch and what you are currently working on and dmd-experimental could help in this regard.
Re: D Stable Proposal
On 11/30/2012 12:48 PM, 1100110 wrote: Raid it for ideas! Since we're raiding for _ideas_, I guess we can have a look at the development process used by other languages. Here's what the cPython mercurial repository looks like (http://hg.python.org/cpython/branches): branch -- 2.7 default 3.3 3.2 2.6 3.1 2.5 3.0 legacy-trunk 2.4 2.3 2.2 2.1 2.0 and here's the revision graph: http://hg.python.org/cpython/graph This is what Wikipedia had to tell about Python's development process (http://en.wikipedia.org/wiki/Python_%28programming_language%29#Development): CPython's public releases come in three types, distinguished by which part of the version number is incremented: ***Backwards-incompatible versions**, where code is expected to break and must be manually ported. The first part of the version number is incremented. These releases happen infrequently—for example, version 3.0 was released 8 years after 2.0. ***Major or "feature" releases**, which are largely compatible but introduce new features. The second part of the version number is incremented. These releases are scheduled to occur roughly every 18 months, and each major version is supported by bugfixes for several years after its release. ***Bugfix releases**, which introduce no new features but fix bugs. The third and final part of the version number is incremented. These releases are made whenever a sufficient number of bugs have been fixed upstream since the last release, or roughly every 3 months. Security vulnerabilities are also patched in bugfix releases. A number of alpha, beta, and release-candidates are also released as previews and for testing before the final release is made. Although there is a rough schedule for each release, this is often pushed back if the code is not ready. The development team monitor the state of the code by running the large unit test suite during development, and using the BuildBot _continuous integration system_. Regards, r_m_r
Re: typeid() broken for interfaces?
On Friday, 30 November 2012 at 10:05:21 UTC, Gor Gyolchanyan
wrote:
interface I { }
class C: I { }
I object = new C;
assert(typeid(object) == typeid(C)); // fails
Is this normal or is it a bug?
Note, that the same works fine in case of a base class, rather
then an
interface.
It works according to spec. Object is expression of type
interface I, so no dynamic type search is performed.
Re: typeid() broken for interfaces?
On Friday, 30 November 2012 at 11:04:10 UTC, Gor Gyolchanyan wrote: So the interfaces aren't supposed to hold a TypeInfo? That doesn't sound right. That makes interfaces useless in a very large set of use cases. You can find information about interfaces and classes at http://dlang.org/abi.html (interfaces have a pointer to vtbl[] which entries have pointers to TypeInfo). You can also write enhancement request if you consider your proposal worth implementing (but I don't understand what exactly you want).
Re: D Stable Proposal
On 11/30/2012 04:22 AM, Robert wrote: My github account is eskimor. I think the model described in: http://nvie.com/posts/a-successful-git-branching-model/ I have just been reading that for advice and find the --no-ff comments confusing. Can you explain that please? I see two contradicting claims. Also you have been added as a member. is a really good one, to get started. If we want to keep changes to a minimum, then the development branch in the model could simply be the current master. The master branch in the model would be the master branch of dmd-stable. I agree that we should be smart about this, but I'm not quite following you. Please explain the best design that you have in mind. In my mind, stable is just an abstraction over the stable branch, we should be working as close to the development branch as we can, to prevent useless duplication. Feature branches already exist in form of pull requests. Release/hotfix branches would have to be introduced. A little education of people would be needed. (E.g. where and when to merge things, bugs/features.) Where and how changes are documented. Exactly. We develop a standard. We follow that standard. I would volunteer to help writing an automatic upgrade tool. We should, define things there, so reports of breaking changes/deprecations, the developers provide, could then be already in a format the tool can understand. Very good! And yes, I think that a proper automatic upgrade tool(and warning system!) should work with the existing systems as much as possible. That would be beautiful. You are in the "Trusted" team on the project since everything is in flux. Expect to move or be moved to a team that is limited to something similar to a tools repo for what you want to work on. If you want to actually get started, I'll create a Tools repo(or a better name?) and give you commit access. But right now, you do not have commit access.
Re: Fixing cyclic import static construction problems
On 11/30/2012 9:05 PM, Peter Alexander wrote: On Friday, 30 November 2012 at 01:07:57 UTC, Andrei Alexandrescu wrote: I think we either do it right or leave it as it is. It's not like there's no workaround so if we take a stand here we better have something compelling. Andrei +1 FWIW, I think this proposal sounds like a massive hack. Not a fan. Andrei has a point.
Re: D Stable Proposal
On 11/30/2012 04:40 AM, Robert wrote: On Fri, 2012-11-30 at 07:31 +0100, Rob T wrote: One quick suggestion before I call it a day, is for there to be an "experimental branch" for the great minds behind D to play around with (eg UDA's etc). We probably don't want experimental stuff going directly into a branch that is destined for stable. Unstable should be for items that are relatively finalized in terms of design and agreement that the concept is to be eventually incorporated into stable, i.e., moving a new feature into unstable starts the refinement process towards a stable release of that feature. Totally agreed. In the development branch only already finalized things should be merged. Having official experimental branch(es) is a good idea. I think the things people are working on should be easily accessible. So other people can contribute and test the stuff. These branches should then also be included in dpaste.dzfl.pl. Maybe a dmd-experimental project, where people can get access to, very easily. So they can push their branches there. It should be as easy for people to try out experimental things as to try out things from the development branch, to get as much early testing as possible. Automatic creation of binary releases would also be cool. So the workflow could be something like: 1. Document on a dedicated wiki page that you start working on feature X or bug fix Y. 2. Get started on a private/semipublic feature branch. 3. As soon as you got something push it to dmd-experimental 4. Continue to work and improve things there 5. Experimental branches are considered for inclusion in devel. I think you would end up targeting experimental to prevent clashes with other stuff that has also yet to be merged. From what I see, whatever you call it, upstream should remain upstream. Maybe its a good Idea, but I would consider that out of our hands. A Testing branch that new features are pulled to after inclusion in upstream would be nice, and allow Testing to handle it's own releases and have it's own guarantees. That would enable the short term releases and early testing. But I do not want to interfere with devel. 6. Things are tested in an integrated way in devel, with binary releases every two months or so. (Much like we have now) 7. At predefined intervals you branch of a release branch and stabilize things further. 8. Release branch is merged in dmd-stable/master Someone posted this, as why not to use feature branches: http://www.youtube.com/watch?v=xzstASOvqNc&feature=youtu.be Fixin to sleep, I'll watch it in the morning and respond. I personally don't think that feature branches are the problem, but more a lack of communication. If people work on the same stuff you get merge conflicts, that is granted, so you should know on what people are working before starting to work. A wiki page where you add a link to your feature branch and what you are currently working on and dmd-experimental could help in this regard. This is a a question for Walter et al to answer. I don't think we should define their workflow, In fact I'd prefer that the devel remain completely under Walter's domain. Testing branch could be useful, though.
Re: D Stable Proposal
On 11/30/2012 05:30 AM, 1100110 wrote: A few of the requests were:(in no specific order) Base Update and Upgrade paths on successful projects, such as Debian's Three branches. To be honest, I don't think that what is needed is a detailed proposal for the branch structure etc. There are only so many ways you can do it, after all, and the details don't matter so much as long as an effective stable version comes out of it. What _is_ needed is to get people committed to actually doing the work to maintain a stable version. Once you have the people, they can work out the details for themselves. I can also include specific versions of LDC and GDC (and any other compiler willing to target a release.) I think that before bringing LDC/GDC into the equation, it would help if we got to the point where the frontend was genuinely portable, as discussed e.g. here: http://forum.dlang.org/post/mailman.1565.1352137245.5162.d@puremagic.com
Re: Time to kill T() as (sometimes) working T.init alias ?
On 29/11/2012 12:10, Maxim Fomin wrote:
On Thursday, 29 November 2012 at 10:41:46 UTC, Mehrdad wrote:
I'm just not understanding the whole "the default construction of a
struct should be a compile time creature, not a runtime one".
Don't you have to initialize the struct with zero's either way?
So either way, you're going to have to initialize it... so no perf
increase in any way. Why prevent the user from default-initializing it
the way he wants to?
Every type has a CT-known default initializer, even classes have (null).
If structures had a runtime one, this would break code (especially
templates and CTFE) which relies on knowing something about constant
default instance of a type at CT.
extern bool foo();
struct S
{
int i;
this() {
i = foo() ? 1 : -1;
}
}
-
S s;
dosmth(s);
-
//somewhere in Phobos
void dosmth(T) (T obj)
{
T val; // is i 0, -1 or 1 ?
}
I think s.i and val.i should be zero. S.this() should never be called
implicitly IMO, but instead like this:
// runtime code
S s = S();
These two should always be equivalent, and compile-time evaluated:
S s;
S s = S.init;
If we actually need non-trivial compile-time 'default' constructors,
they should have a different syntax:
// runtime ctors
this();
this(int x = 0);
this(T...)(T args);
// CT ctor (if actually needed)
default this(){...}
S.init would imply a call to the above CT constructor.
Re: mixin templates with name parameter
On Friday, 30 November 2012 at 04:04:10 UTC, Ali Çehreli wrote:
On 11/29/2012 05:08 PM, js.mdnq wrote:
mixin templates seems like they could benefit from an extra
parameter
that one can pass a name. The name, a string literal, sort of
acts like
a preprocessor token:
mixin template InjectX!(T)
{
private T x;
T get#name#( ) { return x; }
void set#name#(T y)
{
// Checks
x = y;
}
}
Then something like "mixin InjectX!int Mylnt;" will create the
following
function
getMylnt and setMylnt.
The scope names are a nice solution and sometimes what one
wants. But
sometimes one would like to avoid an extra referencing step.
In fact, it would be nice if one could inject code into the
template
code. One, could example, even supply an object or another
mixin with
the mixin to compose the code. If, say, I wanted slightly
different set
functions above I would have to write a template for each one,
but if I
code compose mixins then I could avoid that.
In any case, it can get rather complicated and notation is the
key
issue(how to describe it all elegantly). I think the idea and
the way D
does it is pretty elegant though and probably good enough for
most
cases. I just imagine cases where a very complex mixin might
need slight
changes from one use to the next but unfortunately would
require some
inelegant methods to use it.
Possibly one could compose mixins in a way that all common
function
overlap are serialized.
"alias mixin InjectX!int with InjectY!int Mylntalias;"
"mixin MyIntalias!int MyInt;"
will produce a mixin s.t., the set functions of Y are
serialized with
those of X. (the new set function will first call the set of
InjectY
then that of InjectX)
This way, we can "extend" a mixin relatively easy by simply
"appending"
code to it's functions.
Just some food for thought.
There are also string mixins, which provide some help:
string getFunction(string name)()
{
return "T get" ~ name ~ "( ) { return x; }";
}
string setFunction(string name)()
{
return "void set" ~ name ~ "(T y)" ~ q{
{
// Checks
x = y;
}
};
}
string varDeclaration(string name)()
{
return "private T " ~ name ~ ";";
}
template InjectX(T, string name)
{
mixin (varDeclaration!name);
mixin (getFunction!name);
mixin (setFunction!name);
}
class C
{
mixin InjectX!(int, "x");
}
void main()
{
auto c = new C;
c.getx();
c.setx(42);
}
There is a warning though: The current compiler is very slow
when there are too many little string mixins. I heard that one
large function that generates all three string above would be
way faster than the three that I have used.
Ali
Yeah, it's a bit "stringy" for my tastes but it does provide a
solution.
I suppose one can actually store the templates in another file
and parse them beforehand(sort of preprocessing) and just replace
all occurrences of #name# with the name provided? e.g.,
templates = import("templates.dtp")
mixin parsename(templates, "myname");
(just pseudo code, I don't know enough about D yet to get it to
work)
templates.dtp would be normal template mixins(not stringified)
except using #name# as a name token. parsename will simply
replace #name#(or whatever symbol used) with the 2nd parameter.
mixin will mix it in as normal.
Re: Fixing cyclic import static construction problems
On Thursday, 29 November 2012 at 23:02:17 UTC, Walter Bright
wrote:
On 11/30/2012 9:43 AM, Walter Bright wrote:
It is possible for each static constructor to specify
independently of
the other static constructors which imports must be
constructed first.
But do we really want to go that far?
One way to do that might be to borrow syntax from classes:
static this() : std.stdio, a, c
{
...
}
and the this static constructor only requires that modules
std.stdio, a, and c be constructed first.
static this() : void
{
...
}
means it has no dependencies on other imports.
static this()
{
...
}
has the current behavior (all imported modules must be
constructed first).
Why not simplify?
static this()
{
import std.stdio, a, c; // existing syntax
...
}
static this()
{ // no imports -> no dependencies
...
}
The current behavior should just be dropped.
Re: Strange struct/atomicLoad behaviour
This is another bug with structures. Consider posting this to bugzilla.
Re: Fixing cyclic import static construction problems
On 11/29/2012 02:50 PM, Andrei Alexandrescu wrote: On 11/28/12 11:26 PM, bearophile wrote: There are few things left to implement for purity (they are listed in Bugzilla), but what's left to do for const and immutable? Construction flow and copy conversion. ... meaning e.g. being able to effectively .dup or .idup any class, struct, etc.?
Re: Fixing cyclic import static construction problems
On Friday, 30 November 2012 at 14:09:48 UTC, foobar wrote:
Why not simplify?
static this()
{
import std.stdio, a, c; // existing syntax
...
}
static this()
{ // no imports -> no dependencies
...
}
The current behavior should just be dropped.
+2
Simple & Elegant.
Re: Fixing cyclic import static construction problems
On Fri, 30 Nov 2012 14:29:19 -, Tove wrote:
On Friday, 30 November 2012 at 14:09:48 UTC, foobar wrote:
Why not simplify?
static this()
{
import std.stdio, a, c; // existing syntax
...
}
static this()
{ // no imports -> no dependencies
...
}
The current behavior should just be dropped.
+2
Simple & Elegant.
-2
Confusing. What is the scope of the import? How does it interact with
imports above/below the static this?
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Strange struct/atomicLoad behaviour
On Fri, Nov 30, 2012 at 7:41 PM, Maxim Fomin wrote: > This is another bug with structures. Consider posting this to bugzilla. > Thanks for confirming. I have posted this to Bugzilla. Regards - Puneet
Re: The future of UDAs.
On 11/29/12 9:39 PM, Walter Bright wrote: On 11/30/2012 1:17 AM, Andrei Alexandrescu wrote: A possibly better approach would be e.g. to do a simple analysis of the static constructor's use of symbols, and use that set to decide whether two static constructors must be ordered or not. It's not a complete solution, since using a symbol S from module A does not necessarily mean dependency on S being statically constructed in A. But it would be a start. From what I see it would solve most problems there are out there, 100% automatically, without any syntax addition, and without any downside risk. Andrei
Re: The future of UDAs.
On 11/30/12 3:12 AM, Jacob Carlborg wrote: On 2012-11-30 03:39, Walter Bright wrote: It's not a complete solution, since using a symbol S from module A does not necessarily mean dependency on S being statically constructed in A. But it would be a start. Well, not using any symbol from module A means it has no dependency for sure on A in the static constructor. Exactly. It would be the sensible thing to do. It would disallow only modules with static constructors that use stuff in other modules with static constructors. Though that is still conservative, it would catch a vast majority of cases with a simple and easy to understand policy. Andrei
Deprecated Library Functions / Methods
Is there a way of telling when things in the library will calm down and it'll be save to develop in D and update old code? I started with D2 version 2.051 and created a medium-sized project fairly quickly, but now I have a lot of deprecated methods in my code. I couldn't keep up with all the changes and I have been hesitant to update my code because there are still a lot of "Will be removed in September/November/December ..." warnings in the library. Much that I like D, I simply cannot develop in D at the moment due to the constant changes in the Phobos library. I have this sinking feeling that this is killing the language.
Re: D Stable Proposal
On 11/30/12 4:49 AM, 1100110 wrote: Andrei's support is also necessary, IIRC he is one of main person behind phobos. A stable version of D is not useful without a stable version of phobos and druntime to go with it. I'm very supportive of a serious, meaningful initiative. My perception is that we're having growing pains - our process is lagging behind the participation in the project and the attention it receives. If Walter and I do not acknowledge that in time and act swiftly on it, we're heading toward a crisis in the community much, much larger and dangerous than the D1/D2 schism. Andrei
Re: Fixing cyclic import static construction problems
On 11/30/12 9:09 AM, foobar wrote:
On Thursday, 29 November 2012 at 23:02:17 UTC, Walter Bright wrote:
On 11/30/2012 9:43 AM, Walter Bright wrote:
It is possible for each static constructor to specify independently of
the other static constructors which imports must be constructed first.
But do we really want to go that far?
One way to do that might be to borrow syntax from classes:
static this() : std.stdio, a, c
[snip]
Why not simplify?
[snip]
Why not further simplify?
static this()
{
// JUST AS BEFORE
...
}
There is no need to redundantly specify what modules are used because...
well they are right there in the body of the static constructor.
* no extra syntax
* no change in the symbol visibility rules (why are symbols invisible by
default in static cdtors?)
* no change to the manual
* no breakage of existing code (only code that was broken will be accepted)
* no acceptance of actual circular dependencies go through compilation
This would be purely an improvement to the implementation that would
allow more correct programs to compile. It's a removal of limitation -
the best kind of language change there ever is.
We should have a "bootcamp" area with small compiler and library
projects (such as this after we reach consensus). People who are
interested in helping D, whether or not they've done it before, could
find this area things that are well defined and will definitely be
accepted if properly executed.
Andrei
Re: Deprecated Library Functions / Methods
On 11/30/12 10:04 AM, Chris wrote: Is there a way of telling when things in the library will calm down and it'll be save to develop in D and update old code? I started with D2 version 2.051 and created a medium-sized project fairly quickly, but now I have a lot of deprecated methods in my code. I couldn't keep up with all the changes and I have been hesitant to update my code because there are still a lot of "Will be removed in September/November/December ..." warnings in the library. Much that I like D, I simply cannot develop in D at the moment due to the constant changes in the Phobos library. I have this sinking feeling that this is killing the language. Thanks for this testimony. Andrei
Re: D Stable Proposal
On Friday, 30 November 2012 at 04:30:10 UTC, 1100110 wrote: In the thread: Breaking D2 Language/Spec, A lot of good points were made regarding a Stable branch for D. A few of the requests were:(in no specific order) Base Update and Upgrade paths on successful projects, such as Debian's Three branches. 1. Stable branch - Stable branch only receives bug fixes and is updated at predetermined intervals. - Updates are clones of upstream. - Do not update too often, as that causes too much work. (6, 8, 12 months) - Do not break code unless extremely necessary. (Not even then?) - Document all changes, Document every release - Make each transition as simple as possible. - Warn stable users about soon to be broken code. - Do not allow Stable and upstream to diverge too much. (See Walters's comment regarding D1.) 2. Tools - Provide Tools to allow easier transition between releases. 3. Testing branch. - What should go here? Need clear lines in the sand. There's more, but this is already way too much for one person to handle. But with enough support, all of them are entirely possible. So here I have a few questions, both for the D maintainers and the community. 1. What did I miss that is requested? 2. What should definitely be removed? The question was raised as to why I created a project instead of a simple branch. If people want to volunteer, I can set permissions to allow them access. A project and a branch are not mutually exclusive. Druntime and Phobos depend on specific versions on D, do they not? So those projects would need to remain in sync as well. A project simplifies things to an extent. The dmd developers do not need to have any involvement at all, or it can be as tightly integrated as they wish. I can also include specific versions of LDC and GDC (and any other compiler willing to target a release.) I wanted room to expand. The worse that can happen is that this is completely ignored, nobody uses it, and I eventually lose interest in something that has no support from the community or the devs. (I'm not stopping for any other condition. You're stuck with me.) The best that can happen is that D Stable receives support from the D Developers and the community, allowing for many tools to be created targeting a Stable specification of the Language. Let's define a specification for this thing, shall we? First things first! How long should support of the Stable branch last? 1. 6 months 2. 12 months 3. longer (specify and give reasons) Now how do we organize this? 1. The current git master will be considered Unstable, and will freeze to define the next Stable. Are there better ideas than this? 2. Do we want to go with Stable, Testing, Unstable or another system? I'd like to see some pros and cons before making any decisions. I'm leaning towards the 3 stage system. Yes, this is ambitious. So is D. And D appears to be thriving. Yes, I know that I cannot even accomplish half of this alone. That's the point. There was a lot of discussion, so this obviously interests many people. By myself, I can maintain a specific version of DMD with non-breaking bugfixes. That is about it. Let's do this thing. For all this to actually be possible we need branch maintainers - it is not an easy job and not many people are capable of doing it on production level. It is easy to complain and whine about problems. I haven't seen people actually offer to help here...
Re: Deprecated Library Functions / Methods
On Friday, 30 November 2012 at 15:04:02 UTC, Chris wrote: I have this sinking feeling that this is killing the language. I feel your pain. I often wonder if the Phobos developers actually use D.
Re: Deprecated Library Functions / Methods
Chris: I started with D2 version 2.051 and created a medium-sized project fairly quickly, but now I have a lot of deprecated methods in my code. I couldn't keep up with all the changes and I have been hesitant to update my code because there are still a lot of "Will be removed in September/November/December ..." warnings in the library. Much that I like D, I simply cannot develop in D at the moment due to the constant changes in the Phobos library. I have this sinking feeling that this is killing the language. Phobos is young, and several of its parts were designed by one or very few persons. So I think some changes are inevitable. Deprecation messages have the purpose to reduce the pain of updated. So those are not killing the language. In Phobos some changes are planned or are expected, like in std.algorithm.max/min, reduce, etc. Bye, bearophile
Re: Deprecated Library Functions / Methods
In Phobos some changes are planned or are expected, like in std.algorithm.max/min, reduce, etc. What changes to std.algorithm.max/min are expected?
Re: Deprecated Library Functions / Methods
On 2012-11-30 16:04, Chris wrote: Is there a way of telling when things in the library will calm down and it'll be save to develop in D and update old code? I started with D2 version 2.051 and created a medium-sized project fairly quickly, but now I have a lot of deprecated methods in my code. I couldn't keep up with all the changes and I have been hesitant to update my code because there are still a lot of "Will be removed in September/November/December ..." warnings in the library. Much that I like D, I simply cannot develop in D at the moment due to the constant changes in the Phobos library. I have this sinking feeling that this is killing the language. You can either stay at a given version of D. Or you could use something more stable than Phobos. Tango, for example, is very stable. The problem is that it doesn't receive much changes at all. https://github.com/SiegeLord/Tango-D2 http://www.dsource.org/projects/tango/docs/current/ -- /Jacob Carlborg
Re: Deprecated Library Functions / Methods
jerro: What changes to std.algorithm.max/min are expected? Some time ago I have asked for some changes in max/min: http://d.puremagic.com/issues/show_bug.cgi?id=4705 Later Andrei has shown related different functions in two of his recent talks. I don't know what Andrei now thinks about such changes. Bye, bearophile
Re: Errors compiling DSSS
On Friday, 30 November 2012 at 08:05:25 UTC, Jacob Carlborg wrote: That's the exact same thing as I'm proposing, except it's the compiler handling it. Which would be better because it is integrated and not an external tool. In any event, I'd ask how do the current build systems do it? They read and parse through the source files to learn about dependencies No, they: 1. Run "$ dmd -o- -c main.d -deps=deps.txt" which will write out all dependencies of "main.d" to "deps.txt" Personally, I don't see how that would work using the current form of the output. I tried it with Make to figure out dependencies and the problem I immediately ran into was that the output did not contain full path information for the projects modules, and without that information, there was no way to combine builds from related project under a separate folder. What I find, is that with D, people seem to be building in simple ways, everything under one folder. This works perhaps for many people, but not for everyone. Currently I want send all build output to a separate folder outside my project folder onto a separate drive, but I can't do something even that simple. Sure I can hack it with perhaps a symbolic, but that's a hack which sucks. 2. Read the "deps.txt" file and pass all files to dmd OR a programmer specifies all of it manually, which is a complete nightmare to maintain on large projects. I completely agree. Now, if things were designed correctly, I don't see why a semi-automated build, using internally specified build options for manual tweaking where needed, cannot be done with an embedded build system. If it was designed correctly the compiler would be built as a library. The build tool could the use this library to get all the dependencies of a given source file. No doubt the compiler should be a library. Why isn't it? If it was a library, then perhaps it could use itself in some very interesting ways. The compiler should also accept plugins for extensibility. I have not looked at the code yet, but I suspect what we have under the hood will make me want to cry. Another analogy is to think about languages that have embedded reflection - unfortunately D currently lacks a generalized solution for reflection, but you can see hints of the potential it offers. Simplifying how builds are performed through "reflection" will increase productivity, and will potentially offer new ways of solving old problems well past what was considered possible before. Do you have any example? If there's information inside the source, then the compiler could use that information during a build. A very simple example of this, would be the imports. So instead of manually dumping a deps file, and working some build script magic, the compiler could have that information available internally, thereby saving the programmer from hacking away at an external build script to get it. My guess that's the least of the advantages, there's probably a lot more that could be done. To me, building is just an ugly hack and patch process caused by a broken system that is unable to build itself. It's a total mess. The best place to fix the problem is right at the source. --rt
Re: Deprecated Library Functions / Methods
On Friday, 30 November 2012 at 17:00:15 UTC, bearophile wrote: jerro: What changes to std.algorithm.max/min are expected? Some time ago I have asked for some changes in max/min: http://d.puremagic.com/issues/show_bug.cgi?id=4705 Later Andrei has shown related different functions in two of his recent talks. I don't know what Andrei now thinks about such changes. Bye, bearophile Those proposed changes to min and max look useful. They shouldn't break much code either.
Re: Deprecated Library Functions / Methods
There have been quite a few changes since 2.051 and I cannot stick to that version, because I would introduce more deprecated code. I wanted to update my code but saw in the library that again loads of methods were scheduled for deprecation. So what's the point? Changes are necessary and I think they are reasonable (like the regex algorithm), but as a developer who uses D, you need some sort of security, i.e. that your code won't break in a few months' time. I really appreciate the fantastic work on D, but sometimes it seems to me like a "code laboratory" where programmers test certain ideas, algorithms, approaches etc, which would be fine for a college project. But if you have to use and work with the library to develop real world applications, it's a nightmare. If this doesn't change, I fear D will never take off. Most frameworks at least "tolerate" deprecated functions until developers have time to update their code.
Re: Errors compiling DSSS
On Friday, 30 November 2012 at 17:12:10 UTC, Rob T wrote: On Friday, 30 November 2012 at 08:05:25 UTC, Jacob Carlborg wrote: That's the exact same thing as I'm proposing, except it's the compiler handling it. Which would be better because it is integrated and not an external tool. Why would it be better and why would you care one way or the other? Some people are pointing out that integration of features related to code, but that are not actual code is not necessarily desirable (e.g. comment processing). Many of us use git, so why don't we have dmd do our diffs against the git repository for us as well? Hyperbole, but what happened to the single responsibility principle? Let the compiler do its thing, compile - but let a more knowledgeable entity than the source give it its flags. What I don't understand is how the writer of source would know how it is to be built everywhere and in every way a client might want it. They probably wouldn't - so leave the description of that out of the source entirely. When rdmd does work for the simple case, you would not complain: well this stinks having to type rdmd instead of dmd. No, you'd use it and be happy with its simplicity. Lack of integration into dmd has not hurt at all. It does not satisfy all cases - but it seems it adds great value without disrupting dmd. Why wouldn't a more complex build system want the same thing? [snip] No doubt the compiler should be a library. Why isn't it? 20/20 hindsight maybe. If it was a library, then perhaps it could use itself in some very interesting ways. The compiler should also accept plugins for extensibility. I have not looked at the code yet, but I suspect what we have under the hood will make me want to cry. The beauty of encapsulation ... don't look. To me, building is just an ugly hack and patch process caused by a broken system that is unable to build itself. It's a total mess. The best place to fix the problem is right at the source. I don't think it is that bad at all - but then I'm using rdmd for everything for now. And I agree that the best place to fix the problem is right at the source... the problem is which source. I would say the build source, not the D source as they serve different purposes. Right now we don't have standard build source is the issue and it sounds like you are advocating the two go together.
Re: Deprecated Library Functions / Methods
Chris: But if you have to use and work with the library to develop real world applications, it's a nightmare. If this doesn't change, I fear D will never take off. It's useful to know your pain experience, but please don't turn this thread into FUD (http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt ). Possible solutions only come from more rational discussions. In another thread people are discussion a solution that will help you, a "Stable D", updated only once in a time, like every 6-8-12 months, that has no know regressions and where only nonbreaking changes are allowed (here Phobos modules deprecations are probably to be intended as breaking changes). Bye, bearophile
Re: Errors compiling DSSS
In any event, I'd ask how do the current build systems do it? They read and parse through the source files to learn about dependencies No, they: 1. Run "$ dmd -o- -c main.d -deps=deps.txt" which will write out all dependencies of "main.d" to "deps.txt" Personally, I don't see how that would work using the current form of the output. I tried it with Make to figure out dependencies and the problem I immediately ran into was that the output did not contain full path information for the projects modules, and without that information, there was no way to combine builds from related project under a separate folder. It's easy to work around that. It's certainly orders of magnitude easier than parsing the source files. Besides, parsing them isn't even enough because imports can be inside static if blocks or templates. You need pretty much an entire D frontend to correctly find dependencies from source files.
Re: D Stable Proposal
On Friday, 30 November 2012 at 15:08:24 UTC, Andrei Alexandrescu wrote: On 11/30/12 4:49 AM, 1100110 wrote: Andrei's support is also necessary, IIRC he is one of main person behind phobos. A stable version of D is not useful without a stable version of phobos and druntime to go with it. I'm very supportive of a serious, meaningful initiative. My perception is that we're having growing pains - our process is lagging behind the participation in the project and the attention it receives. If Walter and I do not acknowledge that in time and act swiftly on it, we're heading toward a crisis in the community much, much larger and dangerous than the D1/D2 schism. The thing is that I don't see that succeed as an external project. This is like we wanted both vegetarian and non vegetarian food, and reached that goal by cooking everything all together and then some people spent their time to separate the meat from the rest. Most likely they'll get bored rapidly as it is a lot of boring work, that is useless if the process don't mix everything in the first place.
Re: Deprecated Library Functions / Methods
11/30/2012 9:27 PM, Chris пишет: There have been quite a few changes since 2.051 and I cannot stick to that version, because I would introduce more deprecated code. I wanted to update my code but saw in the library that again loads of methods were scheduled for deprecation. So what's the point? Java has plenty deprecated stuff. So does *cough* php. So do other languages. That alone is not an indication of anything except of the on-going development. There are always references to (usually) better replacements. There are still cases of simple renaming to make functions follow the convention, but these ones are easily fixed with find/replace. Changes are necessary and I think they are reasonable (like the regex algorithm), but as a developer who uses D, you need some sort of security, i.e. that your code won't break in a few months' time. I really appreciate the fantastic work on D, but sometimes it seems to me like a "code laboratory" where programmers test certain ideas, algorithms, approaches etc, which would be fine for a college project. But if you have to use and work with the library to develop real world applications, it's a nightmare. I'd just keep certain version of the compiler & phobos + libs that are needed. And then when deadlines are passed do some refactoring/tweaking to bump used versions up a notch. I agree that it's far from ideal. If this doesn't change, I fear D will never take off. Most frameworks at least "tolerate" deprecated functions until developers have time to update their code. The deprecated APIs do still work if you use the -d switch. What is far more shattering are compiler changes (and bugfixes, sadly) given that 2.051 is 9 versions behind he latest it won't surprise me that it breaks a _lot_. > Most frameworks at least "tolerate" deprecated functions > until developers have time to update their code. Problem is these frameworks also have certain version requirement last time I checked it goes like this: requires php 5.3+ or say python 2.5+ etc. So we'd better have certain D versions that are more lasting. But that'll make sense once the feature set is fully implemented and polished. Anyway see D stable topic. -- Dmitry Olshansky
Re: Deprecated Library Functions / Methods
Great to hear that. I'd like to see D take off one day.
Re: Errors compiling DSSS
11/30/2012 12:05 PM, Jacob Carlborg пишет: On 2012-11-29 23:06, Rob T wrote: For the moment, let's talk about ddoc, or unit testing in D. That's the difference, it's not an external tool set, it's instead a a part of the standard language feature set. BTW, IMO ddoc was implemented poorly, using comments, which I fully agree with you would be a vary bad way to go about implementing the feature. In that case, I would rather use Ruby. The built-in support for unit testing is too simplistic. I think one needs an external tool anyway that makes use of the built-in support unit tests. I just want to be able to do something like: $ test a.d b.d And it will run all unit tests in the modules "a" and "b". In D I need to manually creating a test module which imports all modules I want to test. AFAIK you don't need to import module to run its tests. So rdmd --main -unittest a.d b.d should work. Then we should also be able to make rdmd more extendable. There is e.g. quite interesting --eval switch but I feel it could be something more customizable w/o a lot of extra work. This will give the most basic functionality. This is a few things of that's missing: * Run a single test * Names or context for the tests * Nice report of which tests failed * Continue running other tests if a given test failed -- Dmitry Olshansky
Re: Deprecated Library Functions / Methods
Am Fri, 30 Nov 2012 10:19:08 -0500 schrieb Andrei Alexandrescu : > On 11/30/12 10:04 AM, Chris wrote: > > Is there a way of telling when things in the library will calm down > > and it'll be save to develop in D and update old code? > > Thanks for this testimony. > > Andrei I think what we need is a "hard cut" for phobos. We could release 2.061 and then stop all regular bug fixing / enhancement work on phobos for two weeks. In those two weeks all work would be concentrated on reviewing the existing phobos modules. So we'd start a wiki page, assign every module to at least one person reviewing it. Those people should correct naming and codig style of the module in their local repositories. Controversial changes could be discussed on the wiki. If names have to be changed to match the coding conventions the old names should be deprecated. Some modules should be deprecated as a whole, even if we do not yet have a proper replacement yet. For example we know for many years that std.xml is broken and nobody is fixing it, but we still ship it with phobos. std.signal is written in an old D1 style. std.json should probably be removed as well. We should get rid of all that legacy even if we don't have a replacement yet. In the end we would have a 2.062 release with all the old functionality (deprecated) and new functionality / names matching our coding conventions. Some releases later (e.g. 2.064) all deprecated functionality will be removed. Then everyone knows that: * The new functions in 2.062 should be used ASAP. * 2.063 will be the last version supporting the deprecated functionality. * 2.064 will be 'clean'. All deprecated features will be removed and the rest of the functions will be stable. (At very least there will be no more naming changes or similar stuff) So we'd end up with a phobos with less functionality because of the dropped features and upgrading user code to 2.064 might be a bigger task, but we will guarantee that there will be no (or at least very few) breaking changes after 2.064 and obeying the naming conventions in all modules should lead to a better user experience. If someone really needs a deprecated module like std.xml it could always be maintained in a different repository / project but we should remove everything from phobos which doesn't fit our quality standards.
Re: Errors compiling DSSS
On Friday, 30 November 2012 at 17:59:23 UTC, jerro wrote: It's easy to work around that. It's certainly orders of magnitude easier than parsing the source files. Besides, parsing them isn't even enough because imports can be inside static if blocks or templates. You need pretty much an entire D frontend to correctly find dependencies from source files. It may be easy, but it's not obvious, which makes it hard. That's the problem with external builds. You make a very good point about the static ifs and so on, which means the best place to get that kind of information is directly from the compiler during the build process, but why assume that the compiler can only partly build rather than perform full builds, including an installation? It just seems like a good idea to use D as the build language rather than something else.
Re: Time to kill T() as (sometimes) working T.init alias ?
11/30/2012 3:31 AM, Jonathan M Davis пишет: On Thursday, November 29, 2012 20:27:32 Dmitry Olshansky wrote: 11/29/2012 7:24 AM, Walter Bright пишет: On 11/29/2012 4:47 AM, monarch_dodra wrote: On Sunday, 25 November 2012 at 16:47:08 UTC, Dmitry Olshansky wrote: Thoughts? I don't know about "killing" T(), but I think there *needs* to be an (easy) mechanism to declare ***and*** run-time initialize an object, in a single and comprehensive line. I had proposed something 2 months ago here: http://forum.dlang.org/thread/bvuquzwfykiytdwsq...@forum.dlang.org The proposal wasn't perfect, but still. We need to figure something out... The original idea is that there should be *no such thing* as default construction of a struct as being anything other than T.init. The default construction of a struct should be a compile time creature, not a runtime one. Okay let it be. I'm not against having a defined blank default constructed object. Just don't make T() mean it, please! I'm all for T() meaning T.init if T doesn't have a static opCall, but T() shouldn't be guaranteed to be T.init. I'd very much like to see code like auto t = T(); to continue to work regardless of whether T has a static opCall or not. And what you'd expect 't' to be then? And why such code is useful anyway? The only sane way I see is to make it an explicit call of 0-arg constructor then one can safely assume: 1. t is of type T 2. t is properly constructed and not some invalid state like T.init may be Currently with opCall it could be anything otherwise it ends up T.init or compiler error if T is a built-in type. But it should be able to have a static opCall, and T() should work if it doesn't have one. Assuming that T() means T.init makes no sense. Why in the nine hells we have static opCall to begin with? Probably to workaround 0-argument ctor situation. I haven't seen a better or at least sensible use case. Yet it has great potential for abuse. (and the fact that compiler picks opCall first (static or not) instead of constructor doesn't help matters much) -- Dmitry Olshansky
Re: Errors compiling DSSS
On Friday, 30 November 2012 at 19:16:56 UTC, Rob T wrote: On Friday, 30 November 2012 at 17:59:23 UTC, jerro wrote: It's easy to work around that. It's certainly orders of magnitude easier than parsing the source files. Besides, parsing them isn't even enough because imports can be inside static if blocks or templates. You need pretty much an entire D frontend to correctly find dependencies from source files. It may be easy, but it's not obvious, which makes it hard. That's the problem with external builds. If you are writing a build tool, I don't imagine writing those few extra lines to convert relative paths to absolute would be a problem. You make a very good point about the static ifs and so on, which means the best place to get that kind of information is directly from the compiler during the build process And you already can get that info from the compiler using -deps flag.
Re: D Stable Proposal
On Friday, 30 November 2012 at 18:14:58 UTC, deadalnix wrote: The thing is that I don't see that succeed as an external project. I agree that it cannot be an external project, and instead it has to become the official D process. For example, as was discussed, and i think generally agreed on, we have to change the way the version numbering works to a major.minor.revision model (unless someone has a better idea to propose, which I'd love to know about). There's been mention that maintaining multiple branches will fail, and I see that someone has previously attempted to create a stable version of D that has in fact failed. Rather than taking on a defeatist attitude, we need to look at those past failures and learn from them, so as not to repeat the same mistakes over again, and also to figure out a better solution that has a better chance for success. There's been mention that branch maintenance will be a great deal of tedium for a maintainer, so I think that's an area that needs to be dealt with first. If it's too difficult to maintain, I agree it probably won't be maintained for very long. We have to make it so that the path of least resistance for everyone is to follow whatever process is eventually worked out. I also do expect to see some failures here and there, but that's normal and to be expected, we just have to be persistent until a workable solution is found. The issue here, as stated by Andrei, which I fully agree with, is that D is fighting for its own life. We have no choice but to improve the process, otherwise D will never grow past the current point it is at and will eventually fade away into obscurity. This is a do or die situation IMO. --rt
Re: D Stable Proposal
On Friday, 30 November 2012 at 19:42:12 UTC, Rob T wrote: The issue here, as stated by Andrei, which I fully agree with, is that D is fighting for its own life. We have no choice but to improve the process, otherwise D will never grow past the current point it is at and will eventually fade away into obscurity. This is a do or die situation IMO. --rt Sorry, that came out in an overly bleak way. The really REALLY good news, is that D has grown to the point where we are being forced to adapt to the growth. What we're hoping to achieve is a way that removes the limiters that are holding D back from further growth. The "do or die" scenario only happens if D cannot continue to grow, and other competing languages take over, like Rust and perhaps Go. That's the only dire part to pay attention to, the optimistic point being that we are forced to grow because of D's success, not because of its failures. --rt
Re: D Stable Proposal
On Friday, 30 November 2012 at 19:52:44 UTC, Rob T wrote: On Friday, 30 November 2012 at 19:42:12 UTC, Rob T wrote: The issue here, as stated by Andrei, which I fully agree with, is that D is fighting for its own life. We have no choice but to improve the process, otherwise D will never grow past the current point it is at and will eventually fade away into obscurity. This is a do or die situation IMO. --rt Sorry, that came out in an overly bleak way. The really REALLY good news, is that D has grown to the point where we are being forced to adapt to the growth. What we're hoping to achieve is a way that removes the limiters that are holding D back from further growth. The "do or die" scenario only happens if D cannot continue to grow, and other competing languages take over, like Rust and perhaps Go. That's the only dire part to pay attention to, the optimistic point being that we are forced to grow because of D's success, not because of its failures. --rt A much simpler way to state the current situation is that we're in fact experiencing a "good problem"! --rt
Re: Errors compiling DSSS
On Friday, 30 November 2012 at 19:35:38 UTC, jerro wrote: If you are writing a build tool, I don't imagine writing those few extra lines to convert relative paths to absolute would be a problem. How does the script know what is a relative path and what is not? It's not that easy, and the programmer should not have to be fooling around solving non-productive problems like this. You make a very good point about the static ifs and so on, which means the best place to get that kind of information is directly from the compiler during the build process And you already can get that info from the compiler using -deps flag. But it does not supply enough information and the -deps thing externalizes the build process, which only supports the externalized build mess. The whole thing was designed based on using an external build process, but I don't think it has to be done in that way.
Re: Deprecated Library Functions / Methods
On Friday, November 30, 2012 16:04:01 Chris wrote: > Is there a way of telling when things in the library will calm > down and it'll be save to develop in D and update old code? > > I started with D2 version 2.051 and created a medium-sized > project fairly quickly, but now I have a lot of deprecated > methods in my code. I couldn't keep up with all the changes and I > have been hesitant to update my code because there are still a > lot of "Will be removed in September/November/December ..." > warnings in the library. Much that I like D, I simply cannot > develop in D at the moment due to the constant changes in the > Phobos library. I have this sinking feeling that this is killing > the language. A lot of changes were being done for a while to try and rename stuff to the follow the correct naming scheme and make other needed adjustments. That has dropped off considerably however and the goal is to make deprecations rare. It's just that there were a lot of changes that needed to be made to clean up the library. Most of that has been done has been done now, and the remainder is likely to just not be cleaned up or to stick around long term with an alternative which has been cleaned up. We don't want a lot of churn in the standard library. We want it to be stable so that people can rely on their code continuing to compile. At present, there should be very little which is currently scheduled for deprecation, and it's unknown how long the stuff which has been actually deprecated will stay around. We were removing after 6 months of deprecation but have been re-examining that. What we're trying to get Walter to do is to make it so that deprecated just generates warnings, not errors (rather a new flag will be added to make them generate errors if that's what you want, and -d will stay the same). With that, anything that gets deprecated should stick around for quite a while (though there's a good chance that it'll end up being undocumented after a while in order to further discourage its use), and it won't actually prevent compilation, just bug you to update your code. But as deprecations should become much rarer, even that won't happen anywhere near as often. There's an open pull request to make the change, but Walter hasn't agreed to it yet: https://github.com/D-Programming-Language/dmd/pull/1287 I'd very much like to see the large blocks of stuff that was renamed or moved fully removed rather than sticking around as deprecated (e.g. std.ctype and all of the deprecated functions in std.string should go away), but we do want to be moving away from making large breaking changes like that, and deprecations should become quite rare. Pretty much all of those kind of changes which have been suggested recently have been rejected. - Jonathan m Davis
Re: Fixing cyclic import static construction problems
On Friday, November 30, 2012 10:27:31 Artur Skawina wrote: > On 11/29/12 23:34, Jonathan M Davis wrote: > > On Thursday, November 29, 2012 23:28:07 Timon Gehr wrote: > >> On 11/29/2012 01:17 PM, Jonathan M Davis wrote: > >>> In the past when I've brought up similar solutions, he's been completely > >>> opposed to them. ... > >> > >> It is not a solution, it is a workaround. > > > > What do you mean? The runtime sees circular dependencies between modules > > even when there's no actual circular dependency between static > > constructors. We need to fix that. One way is to just make the runtime > > not care, which wouldn't be particularly safe. Another is to explicitly > > tell it that there are no such dependencies. I don't see how that's not a > > solution. And unless someone can come up with a way for the runtime to > > somehow determine on its own that there's no actual, circular dependency, > > I don't see how anything better could be done. > > It's relatively easy for the /compiler/ to figure it out; it's just that > implementing a simple user-provided flag requires the least amount of work. > What Walter suggested can be tweaked to be sane (per-ctor flag) and will > still be useful if/when the compiler becomes smarter (think lazily initted > module fields). > For the compiler to check if the value of every imported symbol accessed > inside a mod-ctor can be evaluated at compile-time (if you encounter a case > where this is not true it means there (potentially) is a true dependency and > the ctors should be ordered) would require more work. It can't be evaluated at compile time because of .di files. The compiler doesn't necessarily have all of the source to work with - including the static constructors - and if it doesn't have that, it can't do it. If anything figures this out automatically, it has to be the runtime. If we can do that, great, but it means that it'll have actually have to look at individual symbols rather than just at the module level like it's doing now, and right now, we have nothing even close to that. Regardless, while the compiler may be able to provide additional information to the runtime, it's still the runtime that needs to figure this out and not the compiler. - Jonathan M Davis
Re: Time to kill T() as (sometimes) working T.init alias ?
On Friday, November 30, 2012 23:34:04 Dmitry Olshansky wrote: > 11/30/2012 3:31 AM, Jonathan M Davis пишет: > > I'm all for T() meaning T.init if T doesn't have a static opCall, but T() > > shouldn't be guaranteed to be T.init. I'd very much like to see code like > > > > auto t = T(); > > > > to continue to work regardless of whether T has a static opCall or not. > > And what you'd expect 't' to be then? And why such code is useful > anyway? The only sane way I see is to make it an explicit call of 0-arg > constructor then one can safely assume: > 1. t is of type T > 2. t is properly constructed and not some invalid state like T.init may be > > Currently with opCall it could be anything otherwise it ends up T.init > or compiler error if T is a built-in type. If auto t = T(); works then you don't have to care whether the type has a static opCall or not. You get the most valid default-constructed object that there is (or at least, the closest thing that there is to a default-constructed object). If that's init, then it's init. If it's static opCall, then it's static opCall. I don't want to have to care which it is. Also, if I see T t; I'm likely to think that was supposed to be initialized, but the programmer forgot, whereas with auto t = T(); it's clear that that it was intended to be initialized to whatever T() is (be it T.init or the result of a static opCall), and it's clear that the programmer didn't forget to initialize it. > > But it > > should be able to have a static opCall, and T() should work if it doesn't > > have one. Assuming that T() means T.init makes no sense. > > Why in the nine hells we have static opCall to begin with? > Probably to workaround 0-argument ctor situation. I haven't seen a > better or at least sensible use case. Yet it has great potential for abuse. > > (and the fact that compiler picks opCall first (static or not) instead > of constructor doesn't help matters much) I don't know why we have static opCall, but it's used heavily for no-arg constructors, and it's extremely useful to be able to have those. Interestingly enough though, if you were to give all of your class static opCalls, it would become possible to construct classes as if they were structs and not care which you're dealing with (similar to what std.container.make tries to do). I don't know that that's necessarily a good idea, but it's at least another potentially useful way to use static opCall other than providing no-arg constructors to structs. - Jonathan M Davis
Re: Fixing cyclic import static construction problems
On Friday, 30 November 2012 at 20:40:23 UTC, Jonathan M Davis wrote: It can't be evaluated at compile time because of .di files. The compiler doesn't necessarily have all of the source to work with - including the static constructors - and if it doesn't have that, it can't do it. If anything figures this out automatically, it has to be the runtime. If we can do that, great, but it means that it'll have actually have to look at individual symbols rather than just at the module level like it's doing now, and right now, we have nothing even close to that. Regardless, while the compiler may be able to provide additional information to the runtime, it's still the runtime that needs to figure this out and not the compiler. I'd bet you can solve most cases anyway.
Re: The future of UDAs.
On 12/1/2012 1:53 AM, Andrei Alexandrescu wrote:
On 11/29/12 9:39 PM, Walter Bright wrote:
On 11/30/2012 1:17 AM, Andrei Alexandrescu wrote:
A possibly better approach would be e.g. to do a simple analysis of the
static constructor's use of symbols, and use that set to decide whether
two static constructors must be ordered or not.
It's not a complete solution, since using a symbol S from module A does
not necessarily mean dependency on S being statically constructed in A.
But it would be a start.
From what I see it would solve most problems there are out there, 100%
automatically, without any syntax addition, and without any downside risk.
I don't know that it will solve them 100%, because it will have to be
conservative, but I think this is definitely the next step.
For example, in module a:
int x;
static this() { x = 3; }
int foo() { return 2; }
Now, in our module b:
import a;
int y;
static this() { y = a.foo(); }
You might think, aha! this does not depend on b's static this(), so I
can construct in any order. The trouble is, though, that D is a
separately compiled language, and changing b.foo() to:
int foo() { return x; }
will not change the object file of b, and the bug will go unnoticed.
Essentially, it must work like purity inference. The inference works
only for functions where the source must be available - lambdas and
function templates. For other functions, the conservative view must be
taken that the function might depend on a static constructor.
Note that even detecting the existence or not of a static constructor in
module a is not sufficient to determine if b's constructor depends on
it, as the maintainer may add one later.
To sum up, I don't think it is at all clear that this will solve 100% of
the issue, but it is a big step towards that and may reduce the problem
to only a rare annoyance that is more easily worked around.
Re: D Stable Proposal
On Fri, 2012-11-30 at 06:02 -0600, 1100110 wrote: > I have just been reading that for advice and find the --no-ff > comments > confusing. Can you explain that please? I see two contradicting > claims. > > Well the comments say that --no-ff does not create a single commit of the merged in commits, but only create a merge commit. Which is right, but it suffices to preserve the merge information and what was merged. In a fast forward merge basically the following happens: ---**-*-*master You branch to my_branch and do a commit ---**-*-*master |*mybranch If you merge mybranch into master now: ---**-*-**master/mybranch The information is now lost that the last commit actually came from mybranch, with --no-ff you get a merge commit, which is special because it has two parents: git merge --no-ff mybranch: ---**-*-* * master |/ |*mybranch You can now list the commits that came from mybranch with the following command: git log master^..master^2 or simply visually print the merge graph in the log messages: git log --graph
Re: Garbage Collector
On 11/30/2012 03:21 PM, js.mdnq wrote: > I noticed that in both x64 and x86 builds the GC seems to get > exponentially slower as the objects are allocated. [...] > Since the sample code that you have forgotten to show ;) > allocates objects sequentially without any > deallocation it seems there is a huge "bug" in the GC code. Possible. > Can we expect improvements of the GC at in time in the near > future(months, not years)? Yes. There is already a precise GC implementation for D, which should be available with dmd as early as 2.062. Ali
Re: Garbage Collector
On Friday, 30 November 2012 at 23:35:16 UTC, Ali Çehreli wrote: On 11/30/2012 03:21 PM, js.mdnq wrote: > I noticed that in both x64 and x86 builds the GC seems to get > exponentially slower as the objects are allocated. [...] > Since the sample code that you have forgotten to show ;) > allocates objects sequentially without any > deallocation it seems there is a huge "bug" in the GC code. Possible. > Can we expect improvements of the GC at in time in the near > future(months, not years)? Yes. There is already a precise GC implementation for D, which should be available with dmd as early as 2.062. Ali Cool. The code is basically taken off the first link. I modified it a little but the original code should work. All I did was increase the size of objects that are being allocated. I was mainly using GDC x64 though. What I did was run the code and watch the memory usage as it ran. I noticed that it was getting slower and slower. Now, one could expect such if the main memory was fragmented and GDC could not allocate contiguous blocks, but I do not think that was the case and it happens for much smaller amounts of memory. My guess, and just a guess, is that it does not reserve large enough blocks of memory once it is initial memory block is full.
Re: D Stable Proposal
On 11/30/2012 09:08 AM, Andrei Alexandrescu wrote: On 11/30/12 4:49 AM, 1100110 wrote: Andrei's support is also necessary, IIRC he is one of main person behind phobos. A stable version of D is not useful without a stable version of phobos and druntime to go with it. I'm very supportive of a serious, meaningful initiative. My perception is that we're having growing pains - our process is lagging behind the participation in the project and the attention it receives. If Walter and I do not acknowledge that in time and act swiftly on it, we're heading toward a crisis in the community much, much larger and dangerous than the D1/D2 schism. Andrei I know, I feel the same way.
Re: Time to kill T() as (sometimes) working T.init alias ?
On 11/30/2012 3:31 PM, Mehrdad wrote: If that's the case, then we need to get rid of postblits entirely. The only justification I've ever been able to come up with for postblits is implementing a reference counting type.
Re: Time to kill T() as (sometimes) working T.init alias ?
On Saturday, December 01, 2012 15:32:39 Walter Bright wrote: > On 11/30/2012 3:31 PM, Mehrdad wrote: > > If that's the case, then we need to get rid of postblits entirely. > > The only justification I've ever been able to come up with for postblits > is implementing a reference counting type. Any struct which contains reference types needs them. For instance, a struct containing int[] needs to dup that array if it doesn't want to have the copy referring to the same elements as the original and therefore risk having them be mutated. Arrays with immutable elements don't have that problem, but those with mutable elements (and to some extent those with const) do have such a problem, as to structs with classes or structs which are reference types, etc. I'm surprised that you'd think that postblit constructors were only useful for implementing reference counting types. IMHO, the language would be crippled without a postblit or copy constructor for structs. - Jonathan M Davis
Re: Time to kill T() as (sometimes) working T.init alias ?
On Saturday, 1 December 2012 at 04:32:44 UTC, Walter Bright wrote: On 11/30/2012 3:31 PM, Mehrdad wrote: If that's the case, then we need to get rid of postblits entirely. The only justification I've ever been able to come up with for postblits is implementing a reference counting type. Which have to check for null all over the place because it can be uninitialized.
Re: Time to kill T() as (sometimes) working T.init alias ?
On Saturday, December 01, 2012 05:42:23 deadalnix wrote: > On Saturday, 1 December 2012 at 04:32:44 UTC, Walter Bright wrote: > > On 11/30/2012 3:31 PM, Mehrdad wrote: > >> If that's the case, then we need to get rid of postblits > >> entirely. > > > > The only justification I've ever been able to come up with for > > postblits is implementing a reference counting type. > > Which have to check for null all over the place because it can be > uninitialized. That's only an issue with a ref-counting type which is attempting to be non- nullable. Most shared pointers are nullable, making such checks be required regardless. In most cases, I would consider this to be a complete non-issue. - Jonathan M Davis
Re: Garbage Collector
On Friday, 30 November 2012 at 23:35:16 UTC, Ali Çehreli wrote: On 11/30/2012 03:21 PM, js.mdnq wrote: > Can we expect improvements of the GC at in time in the near > future(months, not years)? Yes. There is already a precise GC implementation for D, which should be available with dmd as early as 2.062. Ali Please elaborate about GC plans for 2.062. I saw thread related to GC GSOC project and precise GC, however I do not remember about announcements to pull it in master branch.
Re: Time to kill T() as (sometimes) working T.init alias ?
On Friday, 30 November 2012 at 07:20:39 UTC, monarch_dodra wrote: Related: Why doesn't: "auto a = int(5);" work? and, even more importantly, why don't we have this? : "int* p = new int (5);" The fact that we have "T()/T(arg)", but not "int()/int(arg)" makes *zero* sense to me. THAT has been a source of initial confusion when I moved to D. I'd like to point out that what you are describing are examples of inconsistencies in D, and inconsistencies tend to be a significant cause of productivity loss in many areas. They needlessly complicate the learning curve, the users code, and even the documentation, and unless eliminated they will forever taint the user experience to a degree. As for the way structs are default constructed, I found it to be very difficult to comprehend. The documentation needs to be made better and more detailed. However, I've come around to think that the behaviors are correct and worth putting up with. Yes it can be very confusing at times, so if there's a way to make it less confusing, that would be a big help. --rt
Re: Time to kill T() as (sometimes) working T.init alias ?
On Saturday, 1 December 2012 at 04:51:44 UTC, Jonathan M Davis wrote: On Saturday, December 01, 2012 05:42:23 deadalnix wrote: On Saturday, 1 December 2012 at 04:32:44 UTC, Walter Bright wrote: > On 11/30/2012 3:31 PM, Mehrdad wrote: >> If that's the case, then we need to get rid of postblits >> entirely. > > The only justification I've ever been able to come up with > for > postblits is implementing a reference counting type. Which have to check for null all over the place because it can be uninitialized. That's only an issue with a ref-counting type which is attempting to be non- nullable. Most shared pointers are nullable, making such checks be required regardless. In most cases, I would consider this to be a complete non-issue. - Jonathan M Davis The reference to the counter can be null too, not only the payload.
Re: Time to kill T() as (sometimes) working T.init alias ?
On Saturday, December 01, 2012 08:26:54 deadalnix wrote: > On Saturday, 1 December 2012 at 04:51:44 UTC, Jonathan M Davis > > wrote: > > On Saturday, December 01, 2012 05:42:23 deadalnix wrote: > >> On Saturday, 1 December 2012 at 04:32:44 UTC, Walter Bright > >> > >> wrote: > >> > On 11/30/2012 3:31 PM, Mehrdad wrote: > >> >> If that's the case, then we need to get rid of postblits > >> >> entirely. > >> > > >> > The only justification I've ever been able to come up with > >> > for > >> > postblits is implementing a reference counting type. > >> > >> Which have to check for null all over the place because it can > >> be > >> uninitialized. > > > > That's only an issue with a ref-counting type which is > > attempting to be non- > > nullable. Most shared pointers are nullable, making such checks > > be required > > regardless. In most cases, I would consider this to be a > > complete non-issue. > > > > - Jonathan M Davis > > The reference to the counter can be null too, not only the > payload. Not a big deal, because you just have it so it would only be null if the payload is null, so you wouldn't need to check it much, if ever. At most, you'd have to check it when setting the payload to something other than null, and if the counter is set to null if the payload is set to null, then you don't even need to do that. - Jonathan M Davis
