Both have static constructors. This wasn't detected before because of a bug in dmd (now fixed).

This could probably be corrected by switching std.process to using lazy initialization.

On 9/30/2011 8:16 PM, Walter Bright wrote:
> Both have static constructors. This wasn't detected before because of a bug in dmd (now fixed).
>

On Friday, September 30, 2011 20:22:16 Walter Bright wrote:
> This could probably be corrected by switching std.process to using lazy initialization.

At some point, we're really going to have to look into adding something to the language that makes it possible to indicate when there is no circular dependency and that the order of initialization doesn't matter. This problem is _really_ annoying ever time that it comes up - and even worse, it can't be determined at compile time. Maybe something as simple as

static this() @nodepend(std.process)
{
    ...
}

I don't know. That's just off the top of my head, but I do think that this is an issue that is going to have be addressed at some point.

- Jonathan M Davis

On Friday, September 30, 2011 20:16:33 Walter Bright wrote:
> Both have static constructors. This wasn't detected before because of a bug
> in dmd (now fixed).

std.process doesn't even import std.datetime, so I don't know why a circular dependency would even exist in this case. As usual, trying to figure out what's really going on with a circular dependency isn't going to be fun.

- Jonathan M Davis

On Saturday, October 01, 2011 20:34:45 Jonathan M Davis wrote:
> On Friday, September 30, 2011 20:16:33 Walter Bright wrote:
> > Both have static constructors. This wasn't detected before because of a
> > bug in dmd (now fixed).
> 
> std.process doesn't even import std.datetime, so I don't know why a circular dependency would even exist in this case. As usual, trying to figure out what's really going on with a circular dependency isn't going to be fun.

Ah. It looks like it's happening because std.exception uses std.datetime in its unit tests. Well, hopefully the same trick that std.file and std.stdio use should work with std.process as well. It would be really nice though to be able to just somehow mark one or both of the static constructors or modules to indicate that the initialization order doesn't matter (or to tell it which order to use if that's a better solution). I'll have a pull request with an attempted solution up shortly, but someone with a Mac is going to have to test it.

- Jonathan M Davis

On 10/1/2011 9:07 PM, Jonathan M Davis wrote:
>
> It would be really nice though to be
> able to just somehow mark one or both of the static constructors or modules to
> indicate that the initialization order doesn't matter (or to tell it which
> order to use if that's a better solution).

If such a feature were added, it would not be allowed in @safe code.

On Sunday, October 02, 2011 14:49:26 Walter Bright wrote:
> On 10/1/2011 9:07 PM, Jonathan M Davis wrote:
> > It would be really nice though to be
> > able to just somehow mark one or both of the static constructors or
> > modules to indicate that the initialization order doesn't matter (or to
> > tell it which order to use if that's a better solution).
> 
> If such a feature were added, it would not be allowed in @safe code.

Well, it does kind of scream @trusted, since you're telling the compiler that what you're doing is safe instead of the compiler figuring it out on its own.

- Jonathan M Davis

How about:

--
pure static this()
{
  // Code
}
--

That is, pure at module level (doesn't depend on any other modules). Ordering can be done as before, we just need to add a clause in the docs to define pure module constructors as being run first given a "cyclic dependancy".

On 2 October 2011 23:42, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Sunday, October 02, 2011 14:49:26 Walter Bright wrote:
> > On 10/1/2011 9:07 PM, Jonathan M Davis wrote:
> > > It would be really nice though to be
> > > able to just somehow mark one or both of the static constructors or
> > > modules to indicate that the initialization order doesn't matter (or to
> > > tell it which order to use if that's a better solution).
> >
> > If such a feature were added, it would not be allowed in @safe code.
>
> Well, it does kind of scream @trusted, since you're telling the compiler
> that
> what you're doing is safe instead of the compiler figuring it out on its
> own.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>



-- 
Robert
http://octarineparrot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20111002/a3c63550/attachment.html>

On Oct 1, 2011, at 9:07 PM, Jonathan M Davis wrote:

> On Saturday, October 01, 2011 20:34:45 Jonathan M Davis wrote:
>> On Friday, September 30, 2011 20:16:33 Walter Bright wrote:
>>> Both have static constructors. This wasn't detected before because of a
>>> bug in dmd (now fixed).
>> 
>> std.process doesn't even import std.datetime, so I don't know why a circular dependency would even exist in this case. As usual, trying to figure out what's really going on with a circular dependency isn't going to be fun.
> 
> Ah. It looks like it's happening because std.exception uses std.datetime in its unit tests. Well, hopefully the same trick that std.file and std.stdio use should work with std.process as well. It would be really nice though to be able to just somehow mark one or both of the static constructors or modules to indicate that the initialization order doesn't matter (or to tell it which order to use if that's a better solution). I'll have a pull request with an attempted solution up shortly, but someone with a Mac is going to have to test it.

Seems like yet another reason to put complex unit tests in their own module.  And this was all for an alias of getpid that maps to functions in both Posix and Win32?  Is that even a good idea to begin with?  And why move the alias to core.thread?  It's not like threads have anything to do with processes or process IDs.  Was this meant to be a quick fix so we could run again or a permanent fix?

On Mon, 3 Oct 2011, Sean Kelly wrote:

> On Oct 1, 2011, at 9:07 PM, Jonathan M Davis wrote:
> 
> > On Saturday, October 01, 2011 20:34:45 Jonathan M Davis wrote:
> >> On Friday, September 30, 2011 20:16:33 Walter Bright wrote:
> >>> Both have static constructors. This wasn't detected before because of a
> >>> bug in dmd (now fixed).
> >> 
> >> std.process doesn't even import std.datetime, so I don't know why a circular dependency would even exist in this case. As usual, trying to figure out what's really going on with a circular dependency isn't going to be fun.
> > 
> > Ah. It looks like it's happening because std.exception uses std.datetime in its unit tests. Well, hopefully the same trick that std.file and std.stdio use should work with std.process as well. It would be really nice though to be able to just somehow mark one or both of the static constructors or modules to indicate that the initialization order doesn't matter (or to tell it which order to use if that's a better solution). I'll have a pull request with an attempted solution up shortly, but someone with a Mac is going to have to test it.
> 
> Seems like yet another reason to put complex unit tests in their own module.  And this was all for an alias of getpid that maps to functions in both Posix and Win32?  Is that even a good idea to begin with?  And why move the alias to core.thread?  It's not like threads have anything to do with processes or process IDs.  Was this meant to be a quick fix so we could run again or a permanent fix?

This was but one about a half dozen causes of loops.  Most of the rest were easier to fix (drop unnecessary imports, primarily of std.stdio). The (hopefully) last one will require some additional refactoring to break.  Only one of them involved the unittests, so let's remove that red herring from this thread.

I thought about introducing a core.process file, but that would have been even more dubious for just that pair of aliases and isn't something I felt confortable doing without a longer consultation cycle.

As to the permanency of it, nothing is ever permanent when it comes to code.  I'm all for a better home should one be found.  That said, the distinction between a process and a thread is a fairly narrow one so I don't consider it a particularly _bad_ fit either.  It's about the same delta as thread to fibre, imho.