User feedback - recurrent runtime bug

Steven Schveighoffer schveiguy at yahoo.com
Thu Nov 4 07:20:28 PDT 2010


On Thu, 04 Nov 2010 09:32:35 -0400, simen <simen at nowhere.com> wrote:

> I tried D some years ago and liked it's ideas but thought it too soon to  
> jump in then.
>
> Call this try once.
>
> Then I came back about a year ago to try D version 2 and again found it  
> also too early to jump in, but, admittedly, still liking the D concept.  
>   IIRC the reason I dropped out the second time was then to do with  
> cyclic dependency problems that emerged when I tried converting a Java  
> project to D just for fun.
>
> Call this try twice.
>
> A year later I try D version 2 to see if it has improved.  Porting some  
> rather simple Java code to D and compiling it without error, I am  
> initially impressed that the SLOC metric is much smaller than the  
> original Java code.  So far, so good until running the simple app, the  
> same runtime error message surfaces as per my second attempt a year ago:
>
> object.Exception: Cyclic dependency in module test
>
> Call this try twice again and now thrice shy.
>
>  From what can glean this does not need a new bug report being a known  
> and still uncorrected problem.

It is likely the cyclic dependency problem will not be solved.  The  
granularity is too coarse -- if two modules contain static constructors,  
and they depend on eachother, then there is a cycle.  It doesn't matter if  
the static constructors don't access data from other modules.

There are two options I can think of for solutions.  First is to add  
syntax to indicate the lack of dependency.  This is unlikely to happen,  
but probably the only true solution.  If someone can come up with some  
reasonable syntax, it might be considered.

Second is to have the compiler create a true dependency tree based on what  
variables are accessed.  This would most likely involve creating a custom  
object format (and linker), and is akin to full escape analysis.  This is  
*very* unlikely to happen unless someone wants to do all the work on their  
own.

For now, there are probably workarounds you can use to alleviate the  
problem. I can't really say how you can apply them without some example of  
your code.

There is also the issue of a cryptic error message.  "Cyclic dependency in  
module test" gives you almost no information.  This is an issue I hope to  
solve, when I have some spare time.  I have already tried to solve it but  
ran into some severe bugs, but I can work around those bugs for now.

-Steve


More information about the Digitalmars-d mailing list