Compiling issues since 2009.1

[Dawn Wolthuis]

I have had repeated issues with compiling superclasses of a
%ZEN.Component.page and in other cases IIRC since we upgraded to
2009.1 and have not nailed down the issue enough to pass along an
incident. Since no one is around on the MV list, I thought I'd ask
here before I spend more time on it, hoping someone can tell me just
what compiler options should be set in Studio.

I have Compile Dependent Classes checked and that used to work.

One symptoms: Compile superclass, but the subclasses look like they
are compiling, but they don't work until I individually compile them.

It seems that in this and other cases a real compile is not being
forced. What can I do to tell it that I really do want to compile a
class so that it doesn't decide maybe I don't need to do so? I know I
have this problem with compiler options of ckbo1. I think I also have
it when not optimizing properties. Is that relevant to whether or not
it decides to do a compile of a dependent class?

Please advise. How do you set your compiler options so they work?
Might this be an issue for [language = mvbasic] and not for others
(otherwise I would expect more folks to have had this same issue)?
Thanks for any suggestions before I try to dive in and nail this down
so that I can once again compile without fear of messing up everything
in a namespace (when changing a superclass or a persistent class, for
example).
--
Dawn M. Wolthuis

Take and give some delight today

[Derek Day]

I would just skip optimizing properties -- in this type of application
I seriously doubt it will help any.

If you post the compiler output it might help. I'm not sure what you
mean by "look like they are compiling"

One other flag that I use in pre-2010 versions is -u, this flag affects
incremental compiling(so -u prevents incremental compiles); the class
compiler cannot always detect JavaScript changes when doing incremental
compiles. From what I have seen the improvements in speed of the 2009.1
compiler over previous versions make the incremental compile a less
significant benefit anyway.

HTH
Derek

Dawn Wolthuis wrote (10/16/09 10:02 AM):

[Bill McCormick]

The order of compilation was changed in Zen elements for optimization
purposes. I strongly recommend contacting support as I suspect your
problems are coming from custom or composite components. We have new
recommendations here but I can't type them in an iPhone right now

Bill


On Oct 16, 2009, at 10:02, "Dawn Wolthuis" <dw...@tincat-group.com>
wrote:

[Dawn Wolthuis]

Sometimes (not every time, so I'm not sure if it is a change in
compiler properties or what) when I compile a page that is a
superclass, it shows all of the subclass pages compiling, but after
the compile is done and you run one, it bombs until I go in and open
that one and click to compile it. Until this release, I have not had
to dive into the compiler options at all. I have only changed it from
the default to Compile Dependent Classes and then used Studio for
typical compiles. I have messed things up repeatedly since 2009.1,
however, simply by compiling a %Persistent class or a Zen page
template class. I now know that the oddities we experienced before
were caused by me doing compiles that were not taking in some way, but
I do not know how to fix it yet. Having the compiler stop working for
you is not one of those happy upgrade side-effects, but it has been
sporadic enough not to know where to start other than flipping various
compiler options on and off so far.

The compiler output is just fine in the output window. Other pages
stop working until they are hand-compiled. Thanks for any more clues.
I have turned the optimize properties back to off and will see if/when
I hit this again. Thanks. --dawn

[Dawn Wolthuis]

Ah, very good to know. OK, so there is somewhere that I can get these
new recommendations that will make compiling work again -- does anyone
have a link or a list of them handy? Thanks for your help. --dawn

[Bill McCormick]

I asked Derek to make a posting.

Bill


On Oct 16, 2009, at 10:33, "Dawn Wolthuis" <dw...@tincat-group.com>
wrote:

[Dawn Wolthuis]

I searched through the doc and found this, something I read earlier
but did not understand well enough. Some questions below:

Class Compiler Changes
Generator Method Ordering
In classes containing method generators,

[dawn] We have not written method generators into any Zen pages. Do we
have any by inheritance or might we have some of which we are unaware?
Is [CodeMode = objectgenerator] the if and only if criteria for
determining if something is a method generator?

if any generator depends on information about the state of other
methods in the class, it needs to indicate this to the class compiler.
This is done is including the GenerateAfter keyword in the properties
of the referring generator method. The keyword is followed by the
names of the methods that must be compiled before this generator is
run.

Class Inheritance Order
There is a new class keyword that determines how to resolve a common
member when doing multiple inheritance. This keyword is called
Inheritance and it can be set to “left” or the default, “right”. If a
class inherits from two superclasses that have a common member, say a
method called X(), in classes A and B, for example:

Class User.C Extends (A, B)

By default, C will get the implementation of X from class B, the
rightmost superclass takes priority over the other superclasses. This
can cause problems if class A has another method that uses X() to
perform some work and C does not expect to suddenly get an unrelated
implementation of X from class B instead.

[dawn] We have %Persistent first and then a subclass of %MV.Adaptor,
which has never been a problem. I would hope that if we continue to
specify as we were, that it would not get messed up, but maybe the
default behavior is no longer the same as the behavior was before? Any
clues?

Are there other compiler changes for classes that would change the
default behavior for a compile?
thanks. --dawn

Beginning with this version, class C can specify the inheritance order
using the inheritance keyword. In this example, the desired behavior
is obtained by specifying “left” as the value of the keyword.
Remove The cXXXXid and cXXXinheritedid Nodes From ^oddCOM
To increase speed of class compiler and reduce the amount of data it
uses, the cXXXXid and cXXXXinheritedid keyword nodes from ^oddCOM.
These keywords were internal to the class compiler and should not have
been used by any customer code.
However, if an application does need these values, it can call
resolveIds^%occInherit(class,.inheritedid,.id) to return the values
the system used to have.


On Fri, Oct 16, 2009 at 9:40 AM, Bill McCormick

[Derek Day]

I am not sure where this should go in the Community pages -- perhaps under Custom Component NOTES... but I wanted to get this out today per Bill's request and Dawn's questions.

Thanks to Sue K for the draft on which this article is based.

Also note, the DependOn keyword is documented, but existing documentation discourages the use of the System keyword. Please feel free to ask here or via the WRC if you have any specific questions or concerns.

Best Regards,
Derek Day

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The following is a working draft of documentation that is being added to the product. Note that
one of the former uses of the System flag was to help prevent accidental compilation of system
classes, if you use the keyword you should be careful that you have not mapped any system classes
into your application namespace (if those classes are not already mapped using package names
beginning with %). In addition CACHELIB should generally only be mounted read-only to
prevent any accidental modification of the compiled state of the system library classes.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Compile Order for Custom Component Classes

You might encounter compile order issues when a Zen page references a composite or custom component. The [typical] symptom of a compile order issue is when you receive a compile-time error message that you can fix by simply recompiling your code. In these cases, to prevent error messages and compile the application correctly, your build procedure must compile the classes in order beginning at the lowest level class and working upward, as follows:

   1.      Custom components. These are the lowest level classes for the compile order, so compile them first.

   2.      Composite components. These might reference custom components, so compile them after any custom components.

   3.      Pages. These might reference composite or custom components, so compile pages last, after you have already compiled custom and composite components.

There are several ways to prevent issues with compile order in Zen applications:

    * [Many people consider it good practice and] InterSystems recommends that you place custom component classes in one package, composite components in a second package, and Zen page classes in a third package [and so on]. Ensure that your build procedure compiles these three package in the proper order, from the lowest to the highest level, by invoking separate commands to compile each package individually. [This can of course be extended following the basic principle of separating compile groups into different packages].

    * [Use a different naming convention or only one package], but provide the DependsOn keyword in higher-level classes that need to reference lower-level classes. This is easiest to achieve when there are a small number of classes and not much layering of references to other classes. Simply place a DependsOn statement at the beginning of each higher-level class definition that references a lower-level class. The DependsOn value must identify the package and class name of the lower-level class. For example:

      Class MyPackage.MyZenPage Extends %ZEN.Component.page 

                                [ DependsOn = MyPackage.myCustom ]

      {

      /* Here is the rest of the class... */

      }

    * [It is also possible to use a different package naming convention] if you assign the classes to separate compile groups. You can do this by adding the System keyword in the lower-level classes to sort them into compile groups, as follows:

  

       1.            Set custom component classes to [System=3] so these are compiled first.

       2.            Set composite components to [System=4] so these are compiled next.

       3.            Provide no System keyword or value for the remainder of the application classes, so these are compiled last.

      You can set the System keyword in Studio, using Expert mode. From the Studio toolbar choose Tools > Options > Environment > Class. Select Exert mode and click OK. In the Studio Inspector window, a parameter called System becomes available. Setting the value for this property to 3 or 4 has the desired result. A value of 0 is the default value; it is the same as having no System value set for the class.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

      Caution:

      InterSystems strongly recommends you do not use the value 1 or 2 for the System keyword.
      Values larger than 4 are not supported and the Studio Inspector does not allow you to choose them.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Bill McCormick wrote (10/16/09 10:19 AM):

[Dawn Wolthuis]

Thanks, Derek -- I figured this document, even if still perplexing to
me, deserves at least a response, sorry it took so long. I will be
re-reading it this weekend, but the first time I read it, I did not
come up with any obvious action items for us. It will take me some
time to zero on on the issues, I suspect, but this gives some hints
regarding what to look for. I have seen 3 different scenarios where
compiling has messed me up since upgrading to 2009.1. In one case I
had to back off from changes to a persistent class (adding a virtual
field) since it messed up all pages using that class. There is nothing
I read here the first time through that is giving me clues about
anything related to persistent classes or even on the other two
more-likely scenarios where I have had problems, so I will read it
again.

Because of other issues (not being able to cleanly delete classes from
Studio) yesterday, at the advice of the WRC, I did a $$RebuildIndex on
our development namespace

Then I executed

Do $System.OBJ.CompileAll("kyrb-lo3",.zerr)
(I did not research all of the parameters, but used what Peter said he uses)

So, I'm starting fresh and will a) cross my fingers that all compiling
will be happy now and b) look further into any specific issues I find
from here.

To be clear -- we had ZERO confusing compiling issues prior to 2009.1,
so the compiler has been a workhorse that did its job and I was not
concerned every time I clicked the compile button in Studio that I
might be messing up everyone else like I have been of late. Of course
we compile classes in an order so that components compile before pages
and such, but in the past when we got the order wrong, we understood
the scenario and fixed it. I do not yet understand what all has
changed here and what to do to keep from having such problems.

If I am understanding, it sounds like maybe we have to CHANGE OUR
SOURCE CODE(really?) in order to get accurate compiles now, rather
than simply compiling classes in the right order. Is that an accurate
understanding? Am I sounding whiny this morning or what? Apologies. I
saw the Michael Jackson film last night, so I'll add "It's all love"
thanks --dawn

[Bill McCormick]

Dawn,

Its not that we broke the compiler. We did not always report failures
in the past. I will try again to clarify this....

DependsOn is a flag that simply says this class has to be compiled
after that one. So when we build the grid for compiling classes we say
compile class A before class B. But all that means is we compile the
def first, then we do B, then we compile Class A's table code, then we
do Class B. Last thing we do is an "extra" work hanging off the class,
in the case of a Zen page this means building the schema for XML
parsing. Unfortunately if you are compiling a component in Class A -
this is too late. We already tried to parse the XDATA block in Class B
long ago and failed with an "unknown tag" type error....

The System=xxx flag works differently. It says ALL classes marked as
level 3 must be COMPLETELY compiled before we move on to System=4. The
means everything, including the schema data has been processed before
Class B <hopefully a System=4> class is attempted to be compiled.

In general this is the optimum way to define Zen Application
compilation. System = 3 would be your base pieces - components, and
such. System 4 would be templates and Zen Apps and Zen pages. Your app
should always compile cleanly if you follow this rule of thumb.


Specifically in 2009.1 we changed the order in which some things are
generated during a Zen page compile. We had to do this to build the
ability to programmatically determine what js needed to packaged and
sent out with each page based on the components referenced in that
page's XDATA block. Before we just sent the entire Zen library on each
page. In an attempt to make page loads faster we broke down the
components in to separate js and optimized logic for what packages
were needed. We also changed the order in which style data and js is
sent out in the outputted html. All this was done to improve load
times based on criteria defined in the YSLOW documentation and common
sense regarding "payload".

A default app using all standard components won't care about all this.
But if you are writing components and such it will pay off to read,
understand, and implement this


Bill McCormick
Product Manager
Development Technologies
+1 617 621 0600
bill.mc...@intersystems.com

[Dawn Wolthuis]

Thanks. Bill. I should have said that I "feel" that the compiler is broken ;-)

I know nothing of the System= type of stuff nor have we done anything
in our source code to indicate compile order. We are doing what comes
much more naturally -- compiling in the appropriate order. This has
worked until this build. I am not yet reading anything where I know
just what to do, but now that we have reindex and recompiled
everything in this namespace, I will wait to hit the next compile
issue before reading these emails with more care to see what we ought
to be doing.

One thing I am still not getting is whether we MUST add compile-order
information to our source code to get things to compile correctly, or
whether that is just something helpful we might want to do. I also do
not see what this would have to do with the issues found when
compiling a persistent class with a new MV-style virtual field (and
hence, a new .mvi file entry).

Thanks a bunch for the information. Eventually I'll catch on, knock on
wood. cheers! --dawn