Thanks for your help, you're not late, we are still struggling. We have already experienced a behaviour like yours: sometimes, compiling a class with "f" flag allows to go one step ahead (compiling others). Though it doesn't work for all our classes...I've posted the errors into another message: there must be at least a bug in the compiler, which I hope is not difficult to solve.
Max "Jack Stevenson" <[EMAIL PROTECTED]> ha scritto nel messaggio news:[EMAIL PROTECTED] > Max, > > I am late to this thread buy I may have something that helps. > > We faced a problem like this a while ago, similar, our structure grew large > with lots of dependencies, and some circular references and very similar > symptoms as you in general. > > We seem to have solved in now. > > We compile using the command > > d $System.OBJ.CompileAll("f") > > It took a lot of effort to narrow down the problem. > > One of the most annoying to find was using 'Select *' in queries. Apart > from it being bad form anyway, it seems to cause problems in the compile, > and doesn't report a proper error. > > Apart from that we just went looking for all our errors and removed a lot of > old 'unused/unneeded' classes and dependencies. > > It was an incremental process finding one error fixing it then compiling all > again then finding the next error and repeating until the compile was clean. > > We still have one error reporting at the end, unassociated to the class that > has the problem, but it does not seen to be causing a problem (that we can > find). > > I recommend turning logging on when doing the compile in Terminal so that > you can go back and look over the compile output and see what the errors > are. > > Once there is an error even small that class does not compile properly then > anything that is dependant on it will not compile, expanding exponentially. > > We now as part of our process run a full compile after all new development > to ensure that no unexpected compile errors have been introduced. It is > easier to fix them as they are produced rather than going back later and > finding them all. > > I hope this helps, and good luck, it is a frustrating problem. > > Jack Stevenson > Senior Product Development Manager > Mtivity > London UK > +44 (0) 207 801 6211 > > > "Max Sebastiani" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > Hello again! > > > > > > > > I would suggest you use the following format for $system.OBJ.Compile: > > > > > > Do $system.OBJ.Compile( class, "bruy" ) > > > > > > > ,,we have been using "r-bkvu" until now, and also tried a lot of > > combinations, no results. > > > > > From the documentation (Do $system.OBJ.ShowFlags()), "b" will compile > > > subclasses; "r" compiles all classes that are dependency predecessors; > > > "u" avoids compiling up-to-date classes (albeit as you say sometimes you > > > need "f", the opposite); and "y" finds dependencies within SQL (and I > > > don't remember seeing that one before!) > > > > > > > The "y" is something new, I really need it! Our problems are 99% with SQL. > > Although I just tried, no visible changes to the results (with 5.07). :-( > > > > I'm thinking about moving all our queries apart, into different classes > > which somehow will be compiled later. But it's a disaster, we have about > 150 > > of them... > > Also, having good tests is difficult, we always have to start with an > empty > > database, or the tests will be influenced by what we have compiled before. > > > > I understand that it's a complicated issue to solve for ISC, but a > compiler > > which doesn't know how to compile its classes is a big limitation for OO > > enterprise projects. We need to scale to about 1000 classes by the end of > > the year, and now I'm seriously starting to worry about it. > > > > Max > > > > > >
