SLX Update Policies

• We do not automatically delete links to old versions of SLX when we post updates.  We keep links to old versions on this page for at least six months.

• If you are adversely affected by an update, you can revert to an earlier version of SLX.  There are, of course, two reasons for which you could be adversely affected.  First, from time-to-time, our updates close loopholes or eliminate algorithmic ambiguities.  If your programs are affected by such changes, you should should carefully reexamine your use of the affected features.  Second, notwithstanding our best efforts to test software updates, on rare occasion, we may introduce a new problem in the process of fixing an old one.  In either case, you should email us descriptions of any update-induced problems you experience.

• We post updates that include extensive changes on our new "Testers" page. Such changes carry a higher than normal risk, and unless they're issued in direct response to a problem you've reported, you may choose to avoid installing them.

Documentation Updates

Copies of the Foreword, Chapter 1, Chapter 2, and Chapter 5 of Simulation Using SLX, a new book about SLX, are now available for downloading.  (Revised 12/18/09)  Click here to download the PDF files into your Wolverine\SLX\Doc folder.

The Latest Version of SLX

Release AY201 incorporates the following fixes:

1.  Explicit issuance of a "return" from an initial property is now handled properly.  Such statements normally are not required, since an initial property always returns to the creator of an object being initialized.  Prior to this fix, explicit returns caused incomplete cleanup of the initialization process, which could lead to subsequent catastrophic failures.

2.  A problem with concatenation involving concatenation of string arguments to a procedure when the length of the concatenated result was greater than 256 bytes has been fixed.  Note that string arguments must always be declared as string(*); i.e., the length of such arguments is inherited from a procedure's caller.  Thus when constructing a concatenation involving such an argument, the SLX compiler does not know the maximum length of the concatenation result.  Under such circumstances, it arbitrarily assumes a maximum length of 256.  Prior to this update, results of length greater than 256 were improperly handled, leading to run-time crashes.

Release AY171 incorporates the following fixes:

1.  A compiler problem that could cause selection of the wrong method when multiple methods having the same name, but different calling sequences for different classes were used has been fixed.

2.  A compiler error with the handling of qualified variables names in wait until statements, e.g.,

    wait until (MyModule::Counter > 10);

has been fixed.

Release PR251 incorporates the following fix:

(SLX2 Only) A code generation bug has been fixed for ranked sets in which one or more ranking attributes is an abstract member of an abstract class.

Release PR221 incorporates the following fix:

A code generation bug in 64-bit SLX has been fixed.  The error arose for integer-valued third and fourth arguments to SLX library functions written in C++ and to user-provided DLLs when fetching these arguments required a level of indirection.

Release PR131 incorporates the following fix:

(SLX2 Only) A problem with report properties at multiple levels of within a class hierarchy has been fixed. Note that report properties are processed in child-to-parent order. For example, if a child class has a report property, and its parent class has a report property, the child class's report property is invoked before the parent class's report property. If the child class's report property executes a return statement, the parent's report property is not invoked.

Release PR071 incorporates the following improvements:

1.  (SLX2 Only) A problem with error recovery from attempting to instantiate an abstract class has been fixed.

2.  SLX's memory allocation code has been revised to reduce fragmentation.  As a result, memory requirements for many applications that use large amounts of memory will be reduced.  It is possible, although unlikely, that some applications may see slight increases in memory requirements.

3.  MAJOR LOOPHOLE CLOSED!  For some time, SLX has included a compile-time warning message that is issued when the terminate, yield, yield to, fork, advance, wait, wait list=, or wait until verbs are issued in class properties, e.g., "initial", or during object creation.  These verbs have long been considered illegal in these contexts.  The warning message states that the warning may be changed to an outright error at some future time.  That time has come.

In addition, run-time checks are now inserted to handle cases that SLX cannot handle at compile-time.  For example, if a fork is issued several levels of call below an initial property, depending on the order in which the procedures comprising the chain are compiled, SLX may not "see" the offense at compile-time.

There are two good reasons why this change has been made.  First and foremost, class properties and object creation are designed to execute without delays, e.g., wait until or advance, and without creation of additional pucks, e.g., forks.  In the worst case, violations of these restrictions can cause SLX to crash, quite possibly even compromising error recovery.  Second, even if a way could be implemented to allow such operations, the semantics would be very obscure.  Consider the use of a fork statement in an initial property or a procedure called from an initial property.  By definition, a fork operation increments the use counts of all objects and procedures that lie along the call path from the root object (or the main program) to the point of occurrence of the fork.  This must be done, because the puck created by the fork operation can also return up the call chain.  Having two pucks return as a consequence of implicit execution of an initial property is something that few users would anticipate or try to exploit.

The bottom line is that closing this loophole is necessary, even though SOME PROGRAMS MAY HAVE TO BE REVISED.

Release AR151 incorporates the following improvements:

1.  Object creation counts are now maintained as 64-bit integers. In all previous versions of SLX, these counts were maintained as 32-bit integers, which could overflow if vast numbers of objects were created.

2.  A new built-in function, SetSLXWindowCaption(), has been added to allow users to dynamically override the caption of SLX's main (outermost frame) window.  The calling sequence is as follows:

    SetSLXWindowCaption("My Caption");

Note that under commercial versions, the name of the SLX licensee (obtained from the active Wolverine security key) is appended to the user-supplied caption, e.g., the caption will read something like

    My Caption - XYZ Widget Company

Release AR031 incorporates the following fix:

A compiler problem with ranked sets containing three or more string ranking attributes has been fixed.  Ranked sets with fewer than three string ranking attributes were compiled properly.

Release EB281 incorporates the following changes:

1.  (SLX2 ONLY) An "Implements" operator has been added to allow a program to determine at run time whether the object to which a pointer points supports a given interface.  Consider the following example:

    interface MyXface    { ... };

    ...

    pointer(something)    p;

    ...

    if (p Implements xface1)    // TRUE if the object to which p points implements MyXface

        ...

2.  (SLX2 ONLY) A problem with looping through sets of interfaces has been fixed.

3.  The SLX IDE now remembers the size and location of the main SLX window across invocations.

Release EB101 incorporates fixes an order-dependent problem in declarations of SLX2 interfaces.  Prior to this release, processing of interface variables that followed the first abstract method declaration of an interface were incompletely processed.  This allowed some errors that should have been diagnosed at compile-time to slip through undetected, and in most cases, it led to run-time errors.  If all interface variables were declared prior to the first method of an interface, everything worked OK.

Release EB011 incorporates final cleanup of the additions and corrections made in Release AN271 (below).

Release AN271 includes the following improvements:

1.  (SLX2 only) A problem with pointers to abstract attributes has been fixed.  Consider the following example:

abstract class c1

    {

    abstract int    count;

    };

class c2 subclass(c1)

    {

    concrete int    count;

    };

...

pointer(c1)    c;

c = new c2;

c -> count = 99;

The last statement makes direct reference to an abstract member of abstract class c1.  The reference is valid because c points to an object of class c2, which includes a concrete definition of "count".  Such references were previously mishandled.

2.  Several problems attributable to completely recover from syntax errors have been fixed.

3.  Type checking for inline initialization of pointers has been corrected, e.g.,

    pointer(x)    p = new y;

Is now properly diagnosed at compile-time.

4.  "Throws" issued in "catch" blocks are now handled properly.  This a catch block can trap an error, take corrective action, and throw a different exception to a higher level catch block.

5.  (SLX2 only) compile-time checking for type errors in the use of interfaces has been improved.

Release AN041 includes the following improvements:

1.  A memory leak resulting from the failure to automatically decrement the use counts of control pointers has been fixed.

2.  A flaw in the validation of concrete implementations of abstract methods has been fixed.  The flaw resulted in issuance of compiler error messages for code that was in fact correct.  The problem required at least a three-level class hierarchy:

    A.  A grandfather class containing an abstract method

    B.  A parent class containing a concrete realization of the abstract method

    C.  A child class inheriting from the parent class.

3.  A number of improvements have been made to the SLX debugger, making it easier to step into and out of object properties, e.g., "initial" properties.

Release EC020 includes the following improvements:

1.  Security key interrogation has been changed in such a way that SLX communicates directly with the key drivers, rather than using a client/server protocol which relies on a server launched at boot time.  The new mode of operation speeds up key interrogation and makes it more reliable.

2.  A problem with Remote Desktop has been resolved, allowing launching SLX from "another" machine.

3.  The debugger's ability to step into and out of class properties has been further enhanced.

Release OV270 includes the following improvements:

1.  The SLX debugger's Calls & Expansions window is now able to show the flow of control into the creation and initialization of objects.

2.  Try/Catch processing has been significantly reworked to better handle recovery from SLX errors.

3.  SLX now properly handles invocations of functions loaded from Windows system DLLs.  In previous releases of SLX, all DLL functions were presumed to use the CDECL calling sequence.  In 32-bit versions of Windows, system calls use a different calling sequence.  SLX now handles both calling sequences.  (In 64-bit Windows there is a single, standard calling sequence, so this problem did not exist in 64-bit Windows.)

4.  (SLX2 ONLY) A problem with initialization of arrays derived classes has been fixed.

Release CT140 includes the following improvements:

1.  Steps have been taken to reduce failures to recognize Wolverine security keys.  Such failures were already rare on most systems, and such henceforth be quite rare.

2.  Forward references to attributes of hierarchical classes are now properly handled in all contexts.

3.  A problem with the "diagnose" statement in 64-bit SLX has been fixed.

Release CT010 incorporates the following changes and improvements:

1.  Input errors that are trapped via try/catch now properly reset I/O status so subsequent input operations are not trapped as recursive input.

2.  A class of spurious warnings sometimes issued for multiply-defined symbols has been eliminated.

3.  Compile-time warnings for "batch" jobs are now summarized in batch output files (unless the /quiet or /silent command-line option is used).

Release EP160 incorporates the following changes and improvements affecting SLX2:

1.  The compiler's hardening and softening, as appropriate, of requirements for supplying methods has been further refined.  For example, a class that is a subclass of a class containing abstract methods or a class that implements an interface, which by definition contains abstract methods, is required to supply concrete versions of the abstract methods only if the class is instantiated.  If the class is never instantiated, no complaints are issued for abstract methods for which concrete implementations have not been defined.  This facilitates construction of skeletal class hierarchies in the early stages of project development.  Conversely, a number of instances have been fixed in which SLX failed to complain about required methods at compile-time, resulting in run-time errors.

2.  A problem with ranked sets of an interface has been fixed.

Release EP080 incorporates the following changes and improvements affecting SLX2:

1.  The compiler's requirements for supplying concrete versions of abstract methods have been relaxed to greater facilitate "stubbing in" method implementations.  In previous versions of SLX, the compiler always flagged expressions such as "ptr -> SomeMethod()" if a program contained no method named "SomeMethod".  If "ptr" was a pointer to an abstract class, and the class had no subclasses, it was impossible to invoke "SomeMethod;" thus SLX complained about an error that could not possibly occur.

2.  Forward referencing attributes of a subclass when the subclass is used in a ranked set or "retrieve" statement is now handled properly.  Such forward references were not implemented in prior versions of SLX, but SLX's checks for such references were incomplete.  In certain contexts, this resulted in improperly compiled code.  These contexts could occur fairly frequently in the 64-bit version of SLX and far less frequently in the 32-bit version.

Release UG250 incorporates the following changes and improvements affecting SLX2:

1.  SLX-generated header (.h) files for DLL functions now handle subclassing properly.

2.  A number of problems with the "retrieve" operator have been fixed.  These problems occurred when processing sets of interfaces.

3.  Numerous improvements have been made to abstract/concrete pairing, overridable/override pairing

4.  (SLX2 only) The "super::" qualifier now "looks back" beyond a class's immediate ancestor class.  For example, assume that class3 is a subclass of class2, which in turn is a subclass of class.  If the notation

    super::SomeVariable

is used within class3, and SomeVariable is defined in class1, the SLX compiler will allow the reference.  In previous versions of SLX, SomeVariable had to be defined in class2; i.e., "super::" was interpreted as being a containing class's immediate ancestor class.

5.  When applied to classes and methods, the abstract, concrete, overridable, override, and protected prefixes no longer propagate to members and variables within the classes/methods.  These prefixes must now be applied to individual variables and methods.

6.  It is now possible to have more than one actions, destroy, clear, final, and/or report property in a class hierarchy.  Multiple initial properties have always been supported.

Release UG040 incorporates the following changes and improvements:

1.  (SLX2 only)  Compile-time method selection algorithms have been updated.

2.  (SLX2 only)  The memory footprint of child objects has been significantly reduced.  In prior releases, each level of inheritance added unnecessary overhead to an object's total size.  This problem affected execution only by increasing memory requirements.  No other errors occurred.

3.  (SLX2 only)  Java-like extension of interfaces is now supported:

    interface xface1

        {

        ...

        }

    interface xface2

        {

        ...

        }

    interface xface3 extends(xface1, xface2)

        {

        ...

        }

In the above example, xface3 inherits all the abstract methods and abstract variables declared in interfaces xface1 and xface2.

4.  "throw" statements for which there is no corresponding "catch" statement no longer result in an SLX "uncaught throw" error.  Rather, when an uncaught "throw" is encountered, the message sent by "throw" is displayed, and the program is terminated.  Previously, the message was preempted by SLX's "uncaught throw" message.

5.  "throw" statements executed inside SLX properties, e.g., an "initial" property, are now handled correctly.  In prior releases, SLX had difficulty connecting such "throws" with their corresponding "catches," resulting in bogus "uncaught throw" errors.

Release UL210 incorporates the following changes and improvements:

1.  Recursive execution of "read string=" is now detected and prohibited.  The only way this can happen is if evaluation of an argument to a "read string=" statement invokes a lower-level procedure that in turn executes a second "write string=" statement.

2.  Interface variables can no longer be declared to be static or constant.  Accessing interface variables is performed by adding class-specific offset to a pointer.  Static and constant variables are stored in shared, static locations; thus, additive indexing will not work for them.  This error previously went undetected, resulting in unpredictable behavior.

Release UL060 fixes problems with the computation of test statistics for SLX's implementations of the Kruskal-Wallis and Mann-Whitney U tests.

Release UN240 of SLX closes two loopholes with respect to method invocation.  In both cases the SLX compiler failed to detect the necessity for pointer qualification in certain contexts.  Invocations such as

    MyMethod();

were allowed, when

    SomePointer -> MyMethod();

was required.  Qualification is required when a method or any lower-level methods it calls make unqualified references to members of their containing class.  (In such cases, you need to specify the instance of a class to which a method is to be applied.)

End of the UN240 Update

Release UN140 of SLX incorporates the following changes to SLX1 and SLX2:

1.  If a mean value of 708 or greater is supplied to the rv_poisson random variate generator, an error message is now issued.  Previously, large means could cause floating point exceptions.  The limit of 708 is imposed by the algorithm used.  Note that large means consume considerable CPU time.

2.  A CPU_time() function has been added to allow programs to track CPU time consumption (as opposed to other timing functions that deal with elapsed time.  The time unit is seconds.  Since the new function depends on Windows to distinguish between elapsed time and CPU time, the accuracy of returned values is considerably less than that returned by the real_time() function.  The latter offers roughly one microsecond accuracy.

3.  A new function, SLXIsCompiling() has been added.  This function returns a value of TRUE if called at compile-time, e.g., during the expansion of a statement or macro.  The primary use of this function is to decide whether to use the "run_time" or "compile_time" option of the "diagnose" statement in code that can be executed either at compile-time or run-time.

4.  Several issues with placement of #define directives have been fixed.

The following improvements have been made to SLX2 concrete method definitions supplied to fulfill the requirements imposed by implementing an interface:

1.  A few legal cases that were incorrectly disallowed are now accepted.

2.  Consistency checking of returned values and formal parameter lists is now more rigorous.  (Loopholes have been eliminated.)

End of the UN140 Update

Release UN040 of SLX incorporates the following changes to SLX1 and SLX2:

1.  Information displayed is the SLX debugger's "Uses of Object x" windows has been improved.

2.  The option for trapping of "dangling object destruction" now persists across SLX sessions.  The option can be turned on and off by clicking "Trap" and checking/unchecking the option in the "Trap Unusual Conditions" box.  Consider the following example:

    if (MyPointerFunction() -> x > 0.0)

        ...

If the pointer returned by MyPointerFunction() is the last pointer to an object; i.e., the object's use count is 1, upon completion of the evaluation of the "if" expression, the use count of the object will go to zero, and the object will be destroyed.  This form of reference is a dangling reference.  SLX assumes that implicit object destruction in dangling references is unintentional, and therefore issues a warning message by default when this happens.  The default behavior can be overridden.  This has always been the case; however, the setting of the option did not persist across SLX sessions.

The following change has been made to SLX2:

Initialization of the various levels of inheritance hierarchies has been standardized.  Note that there are three ways in which an object can be initialized:

1.  Class members can be initialized in-line, e.g., "int i = 1000;".  Wolverine discourages the use of this form.

2.  Local class instances can be initialized in-line, e.g.,

    Widget MyWidget = { 1, 2, 3 };

Wolverine strongly discourages this form of initialization in all but very carefully controlled circumstances, because it is error-prone.  Reordering the declarations of class members or inserting new members necessitates revision of inline initialization lists.  Do not use this form!

3.  Class members can be initialized in an "initial" property.  This is the preferred approach.  Since an "initial" property comprises executable statements, this approach is the most powerful way to initialize class members.

The three forms of initialization are executed in the following order:

1.  In-line initializations of form 1 are processed first, in bottom-to-top order; i.e., a parent is initialized before and of its descendants.

2.  In-line initializations of form 2 are processed next, in bottom-to-top order.

3.  Initial properties are executed in bottom-to-top order.

The motivations for this approach are as follows:

1.  Bottom-to-top order makes sense, because a parent class doesn't "know about" all of its potential children, while a child object "knows" about its ancestors and can use attributes of its ancestors in its own initialization.

2.  Processing initial properties last makes sense, because executable code can be constructed to examine and react to initial values specified by both forms of in-line initialization.

Finally, note that the rules for initializations of form 1 may change in the future.  To date, SLX has always processed such initializations all at once at object creation time.  In other languages, such as C/C++, initializations can be interspersed among executable statements, possibly affecting expressions used as initial values.  In this approach, initializations are treated as executable statements.  In SLX, unlike C/C++ and other languages, all variables have well-defined initial values.  SLX's policy of separating declarations from executable statements and processing declarations before executable statements was adopted to avoid double initialization of variables (default first, and then specific).  Consider the following example:

    pointer(Widget)    MyWidget = new Widget;

In the current version of SLX, MyWidget is initialized once, unless the "allow breakpoints on declarations" option is enabled, in which case it is initialized twice, first to NULL and (later) to the specified expression.  In the future, when initializations are treated as executable statements, all variables such as MyWidget will be initialized twice.

End of the UN040 Update

Release UN020 of SLX incorporates the following change to SLX2:

A bug in the compilation of initial properties for multiple levels of a class hierarchy introduced in Release AY290 has been fixed.  Under certain circumstances, the AY290 version of SLX skipped compilation of one or more levels of a hierarchy.

The following change applies to both SLX1 and SLX2:

Use counts for constructs such as

    return MyFunc() -> MyMethod();

are now properly stored.  In all previous versions of SLX, the SLX compiler would sometimes neglect to generate code to decrement a use count, potentially resulting in long-term accumulation of very large use counts and consequently, the inability to destroy objects that could have been destroyed if use count arithmetic were correct.

End of the UN020 Update

Release AY290 of SLX incorporates the following changes to SLX2:

1.  A potentially serious loophole has been closed in both SLX1 and SLX2.  It has always been illegal to execute statements that can cause a puck to lose control of execution, e.g., advance, wait until, yield, terminate, etc., during the execution of a class property, e.g., initial, final, report, etc.  Attempts to use the forbidden statements within the context of a class property have always been flagged as errors.  Unfortunately, the SLX compiler failed to detect the execution of such statements when it was obscured by being executed in lower-level functions called from class properties.

SLX now detects such errors.  For the time being, SLX issues warnings for such errors, but in month or so, these warnings will be changed to compile-time errors.  Treating them as warnings will give users a chance to correct problems at their own pace.  These warnings should be taken very seriously, as they have the potential for corrupting the SLX run-time environment.  If you're in the habit of running with compile-time warnings suppressed, you should reenable compile-time warnings and check out your production applications.

2.  The use of "ME -> ..." is now accepted without complaint when it is necessary to disambiguate references that occur within an SLX2 class hierarchy.

3.  The rules for SLX2 method qualification, interfaces, etc., have been further refined.  In almost all instances, constructs that should have been allowed but weren't are now properly recognized and allowed.  In a few instances, loopholes have been closed.

4.  Calling functions that return values without storing or otherwise using returned results is no longer flagged with a warning message.  Such usage is commonplace in C/C++, and for SLX users, the warnings had become a bit of a nuisance.

End of the AY290 Update

Release PR190 of SLX incorporates the following changes to SLX2:

1.  A number of refinements have been made to visibility of class members across modules and within nested subclasses.  Most of the refinements make things visible that were formerly (incorrectly) invisible.  A few changes close loopholes.

2.  An updated version of Proof3D.slx, the SLX interface for generating P3D trace streams, is included.

End of the PR190 Update

Release PR140 of SLX incorporates the following changes to SLX2:

1.  Error checking for compatibility between arguments passed from a child class to a parameterized parent class has been tightened up. Prior to this change, some forms of erroneous use went undiagnosed.

2.  Prior to this release, several diagnostic messages relating to subclass hierarchies were displayed with the wrong source code highlighted.  In most cases, an error involving use of a parent class name, where the reference occurred within a child class, resulted in the definition of the parent class being highlighted when the reference within the child class should have been highlighted.

3.  A number of restrictions on access to parent class members from within child classes have been removed.

End of the PR140 Update

Release PR060 of SLX incorporates the following changes:

1.  In the event of a usage error, the "resume" statement (for resuming interrupted pucks) could produce diagnostic messages that incorrectly identified the source of the error. In such cases, source code for the statement following the resume statement could be highlighted. Source highlighting for such errors has been fixed.

2.  (SLX2 Only) A number of problems with unqualified method invocations have been cleaned up. Methods are usually invoked using pointer notation, e.g., "ptr -> MyMethod()" or dot notation, e.g., "someobject.MyMethod()"; however, there are a number of contexts in which no qualification is necessary. For example, a method invoked from within the actions property of an active object class, with the understanding that the method is applied to the active instance of the class.

End of the PR060 Update

The AR190 release of SLX incorporates a number of significant changes that affect SLX2 users.  Because of the scope of these changes, we recommend that you install the AR190 release with caution.  If you're using SLX1, and you need to update your copy of SLX, you should download the AR010 release below.

Release AR180 incorporates a number of changes in the rules for using subclasses, inheritance, and interfaces.  Some rules have been relaxed, while others have been tightened.  A number of loopholes have been plugged.

The changes are as follows:

1.  "Pass-through" of abstract methods now occurs by default.  For example, if class A includes an abstract method M, and class B is a subclass of class A, and class C is a subclass of class B, and the concrete instantiation of method M is to be supplied in class C, no declarations of method M are required in Class B.  In the past, pass-through for class B required defining method M as abstract or even "concrete abstract".  The latter notation was used to make explicit the notion that M was concrete in the sense that it implemented a method required by A, but abstract in the sense that the ultimate implementation of M was passed on to C.  SLX allowed "abstract" as shorthand notation for "concrete abstract" in such contexts.

2.  A class that includes abstract methods must now be defined as an abstract class.  Failure to do so will result in compiler warning messages and an implicit application of the "abstract" prefix to the  class.  Note that non-abstract methods in an abstract class must now be explicitly declared as concrete.

3.  If a class implements a method, all of its subclasses inherit that implementation.

4.  A number of shortcomings in pointer promotion/demotion for pointers to interfaces have been overcome, including interface inheritance.

5.  An problem with the architecture of subclassing has been fixed.  When a class is subclassed, SLX constructs the subclass as a concatenation of the parent and child classes.  Thus the offsets of all members of a subclass are known at compile time.  Prior to release AR180, all such offsets were determined at the end of pass 1 of compilation, i.e., after SLX has seen an entire program.  The problem with this approach was that during pass 2 of compilation, the size of a parent class could be increased.  This could happen with local arrays with fixed bounds, which are implemented by appending the array data region onto the end of a class.  It could also happen in complex code generation contexts requiring the use of temporary cells, which also are appended onto the end of a class.

The solution to this problem was to detect implicit expansion of parent classes and to update the offsets of members of their child classes.  All of this works fine, but has (for the time being, at least) forced creation of a new rule: forward references to members of subclasses are not allowed.  If forward references were allowed, code embodying uncorrected member offsets could be generated.  (The code would be generated using offsets known at the time the code was compiled, but subsequently discovered to require adjustment to account for parent class expansion.)

If this restriction proves to be too severe a limitation, we will consider a way of getting around it.

6.  A problem with the use of try/catch in unusual contexts has been fixed.

7.  SLX2 now accepts "try," "catch," and "throw" as synonyms for "_try," "_catch," and "_throw."

8.  Command-line launches of SLX now implement a "three strikes and you're out" approach to security key interrogation.  If no key is recognized, SLX will wait five seconds and try again.  This approach was implemented to deal with simultaneous or near-simultaneous launching of multiple SLX runs.

9.  A loophole in the "sealed" prefix has been closed.  (In some contexts, it was possible to override a sealed method.

End of the AR190 Update

The AR010 release of SLX incorporates the following updates:

1.  Recursive entry to SLX file output routines now works properly.  Recursive entry occurs when a arguments supplied to a "write" statement are calls of procedures that in turn execute their own "write" statements.  While this is almost always an error, this technique can be used meaningfully; thus it is not treated as an error.  Recursive entry to output routines for non-file output have always worked correctly.

2.  Summaries of compilation errors that occur when SLX is launched in command-line mode now properly identify the source files in which the errors occurred.  Previously, only the first such file was identified.

3.  (SLX2 ONLY) A number of shortcomings in the implementation of pointers to interfaces have been overcome, including the following:

A.  Sets of interfaces are allowed, with full support of all set operations.

B.  Pointer promotion and demotion when assigning values to interface pointers and fetching values from interface pointers now work properly.

C.  Casts of interface pointers are supported.

Consider the following example:

    interface LimitedMembership    // empty interface

        {

        };

    class widget1 implements(LimitedMembership)

        {

        ...

        };

    class widget2 implements(LimitedMembership)

        {

        ...

        };

    set(LimitedMembership)    RestrictedSet;

    ...

    pointer(widget1)    w1 = new widget1;

    pointer(widget2)    w2 = new widget2;

    pointer(LimitedMembership)    lm;

    place w1 into RestrictedSet;

    place w2 into RestrictedSet;

    for (w1 = each widget1 in RestrictedSet)    // widget1 objects only

        ...

    for (lm = each LimitedMembership in RestrictedSet)    // either widget1 or widget2

        if (...)

            w1 = lm;        // assignment allowable if lm points to a widget1 object

Note that the LimitedMembership interface defined above is empty.  Normally interfaces are used to specify abstract methods that must be supplied in concrete form by any class that implements the interface.  In this example, the LimitedMembership interface is used solely as a way of distinguishing a group of classes.

In this example, RestrictedSet can contain widget1 and widget2 objects, but objects of no other classes.  Prior to SLX 2, sets could contain either objects of a single class or of all classes.  The use of interfaces allows fine-tuning the specification of exactly which classes of objects a set can contain when a set must contain objects of multiple classes.

The EB250 release of SLX incorporates the following update affecting SLX2:

A compiler error recovery problem with set operators has been fixed.  Prior to this change, the SLX compiler failed to completely clean up when certain types of set operator errors were encountered.  Such errors resulted in internal errors resulting in "Notify Wolverine" errors.

The EB170 release of SLX incorporates the following update affecting SLX2:

A compiler problem that caused spurious complaints when pointers to interfaces were used as class arguments has been fixed.  Note that this change affects only SLX2.

The EB040 release of SLX incorporates the following update affecting SLX2:

An SLX interface can now contain abstract declarations of variables.  Any variable so declared must be instantiated in all classes declared to implement the interface.  An example is included in the SLX\Samples\SLX2 directory.

The EB040 release of SLX incorporates the following update affecting both SLX1 and SLX2:

A number of minor improvements have been made to debugger display windows.

The AN270 release of SLX incorporates the following update affecting SLX2:

Subclasses that lacked an "initial" property, but were based on ancestor classes, one or more of which did have an "initial" property caused an internal compiler "inside an initial property" switch to become stuck.  The end result was that operations that are disallowed inside an initial property, e.g., time advance, were disallowed in contexts, e.g., class methods, in which they should have been permitted.  The sticky switch has been fixed.

The AN270 release of SLX incorporates the following update affecting both SLX1 and SLX2:

The Auto-Save Modified Source and Auto-Apply External Edit options set in a previous SLX run were improperly processed in the next run; i.e., they were incorrectly read from SLX.ini.  The problem has been found & fixed.

The AN250 release of SLX incorporates the following updates:

1.  Sets of child class objects can now be ranked on inherited attributes, i.e., attributes defined in ancestor classes for the child class.  Note: This is an SLX 2 feature.

2.  The executable files for SLX 1 and SLX 2 have been merged into a single file.  In order to force SLX into SLX 2 mode, place a #define statement of the following form into any programs that require SLX 2:

    #define SLX2 ON

Note that SLX2 is currently in beta test.  When the beta testing period ends, Wolverine will be charging an upgrade fee to existing SLX 1 users whose licenses are older than one year.  Further details about SLX 2 are available on the Testers page.

The AN210 release of SLX incorporates the following updates:

1.  The debugger now displays tab characters contained in string variables as blanks.  Formerly, tab characters consumed no space in variable displays, causing displayed string contents to run together.  This was inconvenient when strings were used to contain tab-delimited data.

2.  Random crashes that occasionally occurred when recompiling programs have been eliminated.

3.  A number of changes that were required for SLX 2 have been incorporated.  These changes should have no affect on existing SLX 1 programs.

The CT309 release of SLX incorporates the following fixes:

1.  Recursive entry into "write string" is now handled properly.

2.  The procedure "build_mean_ci" in stats.slx has been revised to take into account roundoff errors that could lead to run-time exceptions.

End of the CT309 Update

The EP259 release of SLX incorporates the following fixes:

1.  Objects whose use counts go to zero as a consequence of emptying a set are once again destroyed as expected.  Recent changes made to production versions of SLX in anticipation of SLX 2.0 introduced this error.

2.  A loophole in the processing of #define statements contained in imported files has been fixed.  Because this loophole has been closed, programs that previously compiled properly may no longer do so.  Consider the following example:

File A:    import "FileB.slx"

                import "FileC.slx"

                module A1

                ...

File B:     #ifdef SOME_SYMBOL

                ...

                #endif

                module B1

                ...

File C:    #define SOME_SYMBOL...

                module C1

                ...

At the outset of compiling a program, SLX determines the depth-first order in which the files comprising the program should be processed.  It does so by scanning the root file up the occurrence of its first module for occurrence of any import statements.  If import statements are encountered, they are processed recursively in depth-first order.

Along the way, any #define statements and #ifdef statements are processed in the expected manner.  This allows for #ifdef-controlled import statements.  Prior to this release of SLX, the SLX compiler retained some #defined symbols encountered in the import scan that should not have been retained.  In the example above, SOME_SYMBOL is #defined in File C during the import scan.  The #ifdef SOME_SYMBOL statement in File B should evaluate to false, since File C is compiled after File B (depth-first order).  SLX's failure to discard the definition of SOME_SYMBOL after the import scan resulted in the "ifdef statement in File B evaluating to true.  Note that the order of compilation is File B, File C, File A.

End of the EP259 Update

The EP049 release of SLX incorporates the following fixes:

1.  A problem with method selection involving precursor modules has been fixed.

2.  An error in the SLX compiler's error recovery code has been fixed.  Under certain circumstances, the compiler had difficulty recovering from undefined labels

The UG209 release of SLX incorporates a number of fixes to the SLX debugger and brings SLX into line with other Wolverine products.

The UN089 release of SLX incorporates the following changes:

1.  Error checking for Set operations performed from within user DLL functions has been improved.

2.  A new keyword, cstring, has been added for use in definitions of DLL function formal parameters.  The cstring keyword indicates that an SLX string is to be passed to a DLL function as a NUL-terminated (C/C++-style) string, e.g.,

        procedure DLLproc2(cstring s1, cstring s2) dll="mydll.dll";

A:  Substring expressions cannot be passed as cstrings.  The reason for this restriction is that SLX appends a NUL character to the ends of strings passed as cstrings.  If a substring were to be passed in this manner, the NUL character would overwrite the first character to the remainder (if any) of a string.  Concatenated strings are allowed.

B:  A value of NULL can be passed as a cstring.  This usage is common in C/C++ to designate the absence of an optional string.  SLX pointers other than the NULL constant cannot be passed in this manner, since SLX does not support pointers to strings.

C:  The cstring keyword cannot be used outside DLL function declarations.

D:  The semantics of passing SLX strings in the absence of the cstring keyword remain unchanged.  They are passed as string descriptors.

3.  Comments that begin with "/*NaturalDocs" (inserted into SLX source code by the NaturalDocs system) are now shown in a distinctive color.

4.  Two obscure problems, one that could cause compile-time crashes, and another that could cause run-time crashes, have been fixed.

End of the UN089 Update

The AY159 release of SLX incorporates the following corrections and improvements:

1.  Umlauted characters in input data are handled properly. Umlauted characters have their high bit set, while most ASCII characters do not. Hence, proper handling of international text requires using unsigned characters, and SLX was inconsistent in its use of signed/unsigned characters.

2.  A debugger crash that could arise when certain combinations of debugger windows were activated, including at least one watched variable window, has been fixed.

3.  pow(x, i) and pow(x, y) now always yield values of 1 if i or y are zero.  In the past, under certain circumstances, values of zero could be returned.  The new definition is consistent with standard mathematical definitions.  Note that if i or y is zero, x is not examined.

End of the AY159 Update

The PR229 release of SLX incorporates the following corrections and improvements:

1.  A problem with run-time error recovery has been fixed.  The problem arose as a consequence of recent changes made to add _try / _catch / _throw support to SLX.  The specific context for which this error was reported was a subscript range error, although the error was probably not limited to this context.

2.  A debugger problem with tracking local pointers has been fixed.  If the object / procedure in which a local pointer was being tracked was destroyed / returned, an exception resulted when updating the tracked pointer window.  SLX had code to handle this situation, but Windows was making screen update requests before SLX had the opportunity to mark the local pointer's containing object / procedure as having been destroyed.

3.  Identical string lengths are no longer required for string variables used as attributes of classes accessed with universal pointers.  Consider the following example:

    class widget10

        {

        string(10)    name;

        int               i;       

        };

    class widget20

        {

        int               i;       

        string(20)    name;

        };

    main()

        {

        pointer(*)    u;

        u = new widget10;

        print (u -> name)    "The name is _\n");

        }

4.  A problem with "report" windows has been fixed.  Under certain circumstances, a report window (a debugger window that monitor's an object's report) could fail to display the requested report.  An unchanging blank window would result.

Prior to Release PR229, "u -> name" would have been flagged as an error, because "name" in "widget10" and "name" in "widget20" had differing lengths. Since length is no longer included in compatibility checks for common attributes, this example is now legal.

Note that the two versions of "name" are located at different offsets within their host classes.  The SLX compiler constructs offset tables for common attributes accessed with universal pointers, so the offset is chosen depends on the class of object to which "u" points.  Such access has a cost of two additional instructions, when compared to normal access of object attributes.

End of the PR229 Update

The PR139 release of SLX incorporates the following improvement:

File "open" operations that fail due to file access are now retried up to five times, with a 1-second delay between retries.  Background: occasionally when a file is written and closed, an attempt to reopen the file may fail.  The causes for such failures are not fully understood.  Among the theories that have been advanced is the possibility that background file-indexing programs may temporarily "grab" the file.

We have seen file access failures occur even when "open" operations are carefully preceded by "CanAccessFile()" calls that theoretically verify file accessibility.  "CanAccessFile()" is described in the PR019 Update, immediately below.

The retry mechanism has been tested by an SLX user who was experiencing file access problems, and it seems to have cured his problem.  We are cautiously optimistic that this will be the case for others, although no other users have reported such difficulties.

End of the PR139 Update

The PR019 release of SLX incorporates the following additions and changes:

1.  A new function has been added to query the ability to access a file:

2.  An extremely rare storage management problem has been fixed. The problem was discovered during Q/A testing, and no users are know to have been affected.

End of the PR019 Update

The AR319 release of SLX incorporates the following additions and changes:

1.  A number of problems with _try/_catch have been fixed.

2.  A new class, SLXExceptionInfo, and a new function, GetExceptionInfo(), have been added to provide information to a _catch block.  The following example illustrates the use of these new features:

The AR259 release of SLX incorporates the following additions and changes:

1.  Comparisons of boolean expressions using the "<", "<=", ">=", and ">" comparison operators are now flagged with "questionable usage" compile-time warnings.  Constructs such as

    if (FALSE < TRUE)

        ...

and

    if ((a < b) <= (c > d))

        ...

are now flagged.

2.  A problem with the "window =" option of the filedef statement has been fixed.  The "window =" option is used to define an output window, e.g.,

3.  The memory statistics available through the Help menu (Memory Usage, Memory Details, and Free Memory Details) can now be displayed in the SLX log window by a running program.  The built-in functions for doing so are:

    SLXMemoryUsage("user-supplied title");

    SLXMemoryDetails("user-supplied title");

    SLXFreeMemoryDetails("user-supplied title");

4.  Exception handling has been implemented in a style loosely pattered after C++, except that SLX uses a single "catch" clause, within which an error code and message can be examined.  Consider the following code sketch:

    int                 code;

    string(100)    msg;   

    _try

        {

        [statements that may cause an exception, including lower-level calls]

        }

    _catch(code, msg)

        {

        [actions taken in response to an exception]

        }

Exceptions of two forms are handled, SLX-generated exceptions and user-thrown exceptions.  User-generated exceptions are thrown using the _throw statement:

    _throw(error_code, "message");

SLX-generated exceptions use negative error codes, so error codes for user-thrown exceptions should be greater than or equal to zero to avoid confusion.  A list of SLX-generated exception error codes is located at the top of module SLX_system1.  You can peruse this list by compiling any SLX program, clicking on Browse, Flat Source, Modules, SLX_system1.  Errors such as division by zero, NULL pointer references, and array bound violations can all be trapped using try/catch.  All-told, there are approximately 70 different types of SLX-generated exceptions.  By carefully examining the error code passed to a catch clause, you can decide whether or not to handle any given exception.  If you opt to not handle an exception, you can simply throw it to a higher level from within a catch clause.  Ultimately, if an exception is thrown beyond a top-level try clause, the exception is treated by SLX as an execution error.

Exception handling is optimized for performance of the no-exception case. The overhead of using a try/catch block when no exception occurs is exactly one unconditional branch instruction that branches around the catch clause.  When an exception occurs, a fairly elaborate algorithm interrogates tables built at compile-time to ascertain which, if any, try clause includes the point at which the exception occurred.  Thus, mainline logic should not be implemented using throws, because they are inefficient.

5.  A bug in SLX's CPU time monitoring facility involving user-supplied DLL functions has been fixed. 

End of the AR259 update

The AR199 release of SLX incorporates fixes to two obscure problems:

1.  The GetCommandLine() function failed when used in a macro or statement definition.

2.  When procedures inside a class ("member" functions) were declared to be "static", the static property incorrectly propagated to the procedure's arguments, if any, and was interpreted as the default storage class for all local variables within the procedure. The propagation of "static" to the procedure's arguments was wrong, and the use of "static" as a default for all of a procedure's local variables was questionable. The problem has been resolved by ignoring the static keyword in this context.

In C++, static member functions are allowed, but with the restriction that they can access only static variables of the class in which they reside. SLX enforces this restriction by noting member functions that make references to non-static variables of their host class. Invocations of such functions must be qualified by supplying a pointer, e.g.,

    ptr -> MemberFunc(args);

Such qualification is required to specify the instance of the class whose local variables are referenced.

Consider the following example:

class widget

    {

    int            i;

    static int    j;

    procedure fetch_i() returning int

        {

        return i;    // fetches an instance-specific value

        }

    procedure fetch_j() returning int

        {

        return j;    // fetches a static value common to all instances

        }

    };

    pointer(widget)    w;

    int                      wi, wj;

    w = new widget;

    wi = w -> fetch_i();    // valid qualified invocation

    wj = w -> fetch_j();    // unnecessary qualification

    wi = fetch_i();            // illegal unqualified invocation

    wj = fetch_j();            // valid unqualified invocation

Of the four calls immediately above, only the third is illegal, because fetch_i()  refers to "i", which is local to individual instances of "widget". SLX allows "fetch_j()" to be called with or without qualification. If a qualifying pointer is supplied, it is effectively ignored.

End of the AR199 update

The AR049 release of SLX incorporates a fix to code generation for the "?" operator.  The following case was corrected:

    xstring = (a < b) ? "a" : "b";

Only instances in which single-character, constant strings were used failed.  This may seem odd, since this is a much easier case than most such string expressions.  However, because of their widespread use, operations involving single characters are given special treatment, and in the case of the recently added "?" operator, the special treatment was incorrect.

The EB119 release of SLX incorporates massive changes to the internal mechanisms by which macros and defined statements are expanded into the final text processed by the SLX compiler.  These changes, described in paragraph 4, below, have been very thoroughly tested.  Nevertheless, you are advised to backup your current copies of slx32.exe and slx64.exe before applying this update.

The EB119 release of SLX incorporates the following additions and changes:

1.  A problem with error recovery for subscript range errors has been fixed.

2.  A debugger display problem arising from extremely long source code lines has been fixed.

3.  An obscure problem with mysterious, asynchonous, "dangling" <NULL> objects has been fixed.

4.  A pair of new string delimiters has been introduced.  Theses delimiters are intended for use with the "expand" statement, but can be used with ordinary SLX string constants as well.  The rules are as follows:

A.  The start-of-string delimiter is |", and the end-of-string delimiter is "|.

B.  The string between these delimiters includes all characters, including invisible tab characters and linefeeds, and "normally" quoted strings.  The inclusion of linefeed characters implies that a string using the new delimiters can span multiple lines without requiring any special actions.  If you supply a |" start-of-string delimiter, but forget the "| end-of-string terminator, SLX will gobble up the remainder of the source file before complaining about an unterminated string.  This is an error that anyone using the new form of string will make sooner or later; however, such errors are clearly pointed out by SLX and are easily corrected.  The notational convenience outweighs the risks.

C.  Within a |"..."| string, escape sequences, e.g. "\n", are interpreted only if they fall outside any normally quoted string inside the |"..."| string.  Escape sequences that fall inside normally quoted strings are passed through verbatim, with the understanding that they will be processed when the text produced by the expand statement is processed later.

Consider the following example using "old" notation:

expand(#condition, #variable)

End of the EB119 Update

The EB059 release of SLX incorporates the following additions and changes:

1.  A compiler error recovery problem involving undefined symbols has been fixed. The problem occurred when there were multiple instances of the same symbol, at least one of which was private, and at least one of which was undefined. When SLX encounters a use of a symbol that is private to another context, it searches to find another definition that is public. The error recovery problem arose when the public instance found was undefined. The compiler attempted to use symbol information not present for an undefined symbol.

2.  The SLX debugger's internal step count was recently changed from a 32-bit counter to a 64-bit counter.  (Some users with long-running programs were experiencing wrap-around problems with this counter.) Due to an arithmetic error, in some contexts, it became possible to become stuck in single step mode.

3.  A problem with the SLX debugger's displaying of pucks forked from the "system" puck has been fixed. The "system" puck is in control when a program's modules are initialized. Static instances of classes whose initial properties include forks create pucks that are siblings of the system puck. (Note from JOH: I think this usage is pretty rare, but I found a context in which it was useful, and I'm the one who encountered the debugger display problem.)

End of the EB059 Update

The EB029 release of SLX incorporates the following additions and changes:

1.  SE.exe has been converted into a stub program that invokes SE32.exe. SE.exe has been obsolete since SLX was split into 32- and 64-bit versions, SE32.exe and SE64.exe, two years ago. You should use SE.exe only if you have hard-to-change procedures or scripts that invoke SLX. If you continue to invoke SE.exe, you will henceforth have to make sure that SE32.exe is included in the same folder as SE.exe.

2.  SLX now supports non-English characters, e.g., German characters with umlauts. SLX now conforms to the Code Page 1252 standard, which supports most European languages.

4.  SLX's storage management algorithms have been tweaked to greatly reduce the probability of memory fragmentation. Under normal circumstances, the only way memory fragmentation can occur is through the use of variably-dimensioned arrays. For example, assume that a program allocates 1000 10,000-byte arrays and later releases them. When a block of memory is freed, SLX combines any contiguous blocks of free memory that are created into a larger block of free memory. Any 10,000-byte free block that is both preceded and followed by memory that is in use will remain a 10,000-byte "hole" in memory. If the program subsequently allocates 1000 10,016-byte arrays, none of the 10000-byte blocks of free memory will be useful for filling a request for allocating 10,016 bytes. If the sizes of variably-dimensioned arrays gradually creep upward over a long period of time, massive fragmentation can result.  To preclude this, SLX now rounds memory requests for variably-dimensioned arrays to the next higher power of two.  In most cases, this results in less efficient us of memory in the short term; however, it greatly reduces the probability of long-term fragmentation.

5.  A "Help, Free Memory Details" display has been added to reveal further insights into memory allocation.

6.  SLX now supports the C/C++ "? :" ternary operator. Consider the following example:

    i = j <= k ? j : k;

The "j < k ? j : k" expression is evaluated by testing the condition "j < k".  If this is condition is true, the value of the expression is "j"; otherwise it's "k".

Note that "? :" operators can be nested, e.g.,

    i = j < k ? j < l ? j : l : k;

Nested "? " operators are very hard to read, so if you feel the need for doing so, you are highly advised to use parentheses to improve readability, e.g.,

    i = j < k ? (j < l ? j : l) : k;

End of the EB029 Update

The AN239 release of SLX incorporates the following additions and changes:

1.  A problem with very complex wait until expressions that resulted in hardware exceptions has been fixed. "Silent" error did not occur. Failures were always spectacular.

2.  A number of obscure problems with detecting recursive entry into class properties have been fixed. For example, if a class's report property invokes reports for other classes which in turn recursively invoke the original report property, the error is detected and diagnosed.

3.  .RTS files can now be used in the "import" statement, e.g.,

    import "mylib.rts"

Source code in .RTS files is hidden and cannot be stepped into using the SLX debugger. If you need to provide SLX code to third parties for use in their models, but do not want to divulge source code, supplying .RTS files will work. Note that it is possible to generate .RTS files for incomplete programs. For example, a main program is not required.

Warning! This feature has received only limited testing. We hope those of you who are interested will try this new capability and try top break it! Let us know about your experiences.

4.  A number of debugger "display" features have been cleaned up.

5.  The Help, Memory Details display has been enlarged to give more details on numbers and sizes of blocks of free memory under the control of SLX's memory manager. This information may be useful in identifying memory fragmentation issues; however, memory fragmentation is extremely rare in SLX, due to its language architecture and memory allocation strategies.

The AN079 release of SLX corrects two rare problems with processing of user-defined statements and macros.  Both errors resulted from SLX failing to fully recover from user errors.

The EC158 release of SLX corrects problems with qualified names used for invoking procedures defined in classes.  This is a further elaboration of the improvements described in the EC108 release of SLX, described immediately below.

The EC108 release of SLX incorporates the following additions and changes to SLX:

1.  The rules by which "::" symbol qualification is performed have been relaxed.  Consider the following example:

public module m1

    {

    procedure p()

        {

        }

    ...

    m2::p();        // invoke the version of function p in module m2

    }

public module m2

    {

    procedure p()

        {

        }

    ...

    m1::p();        // invoke the version of function p in module m1

    }

SLX previously required that the symbols used to the left and right of the "::" qualification operator be previously defined.  In the example above, this is impossible.  In the example above, "m2::p()" is a forward reference to a procedure defined in m2.  If the order of the two modules is reversed, "m1::p()" is a forward reference.

The SLX compiler has been revised to defer the processing of symbol qualification to the second pass of compilation, after all definitions have been seen by the compiler.  Using this improved approach, the above example is legal.

There are still some constructs in which qualified forward references are disallowed.  For example, if a qualified, named constant is used to specify an array dimension or a string length, it cannot include a forward reference.

2.  A new command-line option is now available for batch-mode generation of RTS (Run-Time SLX) files, e.g.,

    se32 /genrts myrun.rts myprog

The above command compiles myprog.slx and generates an RTS file named myrun.rts.

3.  When SLX is invoked from the command line or another program, the symbol "BATCHRUN" is automatically defined, allowing the following:

#ifdef BATCHRUN

    (Perform actions appropriate to non-interactive operation.)

#else

    (There's a live user out there; act accordingly.)

#endif

4.  SLX's algorithms for annotating and highlighting source code have been significantly revised.  This improves the appearance of the annotations, and it prevents the occasional "streamin" errors that were formerly caused by such things as unterminated string constants.

End of the EC108 Update

The OV188 release of SLX incorporates several additions to command-line invocation of SLX.

1.  Symbols that are tested in #ifdef and #ifndef statements can be defined by using the new /# option:

    se32 /#mysymbol1 /#mysymbol2 /run myprog

Note that SLX offers onl;y limited support of C/C++'s #define, #ifdef, #ifndef, and #else statements.  Symbols can be defined and tested, but not used to perform substitutions.  In other words, the actual values assigned are ignored.

2.  The new /stdout option causes SLX to write its standard output to the standard output of the command stream.  The principal use of this option is to allow redirection of standard output:

    se32 /run /stdout myprog >>logfile.lis

3.  SLX now returns a negative return code if a required security key (dongle) is not detected.  This allows an application that launches (using CreateProcess(), for example) SLX to detect its failure to execute.

End of the OV188 Update

The EP178 release of SLX incorporates two changes.

1.  The "read string=x" statement will now take the err= exit in the event that the end of string x is reached before the end of the list of input variables is reached.  Previous versions of SLX treated this condition as a fatal error.

2.  Some minor improvements have been made to memory usage accounting and exception handling in the 64-bit version of SLX.

End of the EP178 Update

The EP098 release of SLX incorporates two changes.

1.  Resolution of conflicts between local variable names and procedure names has been improved.  This change affects the 32- and 64-bit versions of SLX.

2.  In the 64-bit version of SLX, conversion of integer arguments to floating point for the log() and log10() built-in functions has been fixed.  The 64-bit version of SLX uses two kinds of floating point arithmetic.  The vast majority of floating point arithmetic is performed using SSE hardware, which is typical of most 64-bit applications.  However, a handful of math/trig functions run faster using X87 machine instructions, so SLX-64 compiles such functions into X87 instructions.  In these rare cases, implicit mode conversion from integer to floating point was working improperly.

End of the EP098 Update

The UG208 release of SLX incorporates minor changes to security interrogation.

End of the UG208 Update

The UG178 release of SLX fixes a problem with the GetLocalTime function in the 64-bit version of SLX.  Although no changes have been made to SLX-32, it is being reissued to keep the two versions in sync.

End of the UG178 Update

The UG148 release of SLX fixes a problem in the 64-bit version of SLX that prevented full exploitation of its 64-bit address space.  Although no changes have been made to SLX-32, it is being reissued to keep the two versions in sync.

End of the UG148 Update

The UG068 release of SLX fixes a memory allocation bug in the 64-bit version of SLX that prevented full exploitation of its 64-bit address space.  Although no changes have been made to SLX-32, it is being reissued to keep the two versions in sync.

End of the UG068 Update

The UL088 release of SLX fixes a problem with compiler register allocation involving complicated combinations of control variables and built-in functions.  This problem caused "Please notify Wolverine" messages.

End of the UL088 Update

The PR218 release of SLX incorporates the following fixes and improvements:

1.  C/C++-style casts for ints and doubles are now provided, e.g.

    MyFunc((int) x, (double) i);

2.  The first, last, successor, and predecessor set operators can now be used to specify a object whose attribute is used in a wait until statement, e.g.,

    wait until ((first widget in MySet) -> attrib > 10.0);

Note that in the above example, the first operator is not treated as a control variable; i.e., a change in the contents of MySet will not trigger reevaluation of the wait until statement.  Only changes in "attrib", which must be a control variable, will do so.

The example above is equivalent to the following:

    w = first widget in MySet;

    wait until (w -> attrib > 10.0);

3.  Saving checkpoint IDs in arrays now works properly.  Prior to this release, statements such as the following failed:

    check[i] = SLXCheckpoint(&x);

4.  An code generation error for the ceil operator has been fixed.  Prior to this fix, the ceil operator could fail in certain complicated contexts, e.g.,

    MyPointer = position(ceil(x)) in MySet;

5.  SLX now permits the same symbol to be used both as a module name and as an enumerated type.

End of the PR218 Update

The PR018 release of SLX incorporates the following fixes and improvements:

SLX now ignores backslashes when reading or writing string data.  SLX still processes backslashes in "picture" formats used with the "print" and "write" statements.

Prior to this change, backslashes in string data were processed as character string escape sequences.  If you tried to read a file name containing backslash characters into an SLX string, the backslash characters were "eaten" by SLX and did not appear in the string.

End of the PR018 Update

The AR138 release of SLX incorporates the following fixes and improvements:

1.  Recent changes to SLX's exception handler have greatly improved SLX's ability to diagnose execution errors such as overflow, division by zero, etc.  However, one revision to code that determines the source code associated with compiler-generated instructions could under certain circumstances result in asynchronous run-time failures when a 5-second periodic screen update was performed during a long run.  The circumstances leading to such problems were complex and not necessarily reproducible, since there was a real-time component.  This problem has been fixed.

2.  The exception handler for SLX-64 has been further enhanced to accommodate peculiarities of the 64-bit versions of Windows.

3.  A register allocation problem with cat= has been fixed.

End of the AR138 Update

The AR108 release of SLX incorporates the following fixes and improvements:

1.  The previous release of SLX (EB268) incorporated a number of code generation changes to take advantage of more modern CPUs.  Unfortunately, one such change made use of machine instructions introduced around 2003.  Several users with CPUs of 2003 or earlier vintage experienced difficulties.  The changes have been rolled back to be compatible with older hardware.

2.  A code generation problem has been fixed for expressions of the following form:

    global_pointer -> local_pointer -> attribute

3.  The SLX compiler now is able to resolve conflicts in which the same symbol is used as a module name and an enumerated type constant.

End of the AR108 Update

The EB268 release of SLX incorporates the following fixes and improvements:

1.  Code generation and run-time support for "wait until" have been further improved. Programs that make heavy use of wait until may exhibit 0-10% improvements in execution speed, depending on exactly what forms of wait until are used.

2.  Run-time support for time advances has been improved. Programs that perform large numbers of time delays will run 0-10% faster.

3.  Code generation has been improved to assure that diagnostic messages for floating point exceptions more accurately indicate offending operations. (This change affects only the 32-bit version of SLX. The floating point hardware used by SLX-64 generates inherently precise exceptions, so no software tricks are required to get good messages.) Prior to this change, it was possible for an exception such as floating point overflow to be recognized not at the point of occurrence, but at the next floating point operation. The user who reported this problem had a program that generated an exception at the bottom of a loop, but the exception was recognized at the top of the loop in the next iteration. While this reflected the way the hardware actually worked, it was extremely confusing.

4.  A minor problem with floating-point code generation for procedure calls has been fixed.  In certain circumstances, SLX failed to flush the contents of the floating point register stack across procedure calls.  There were several possible consequences when this happened.  First, if lower-level procedure calls also exhibited the same problem, the floating point register stack could have been exhausted.  This would have resulted in a run-time register stack overflow exception.  This error could not have occurred "silently."  If it happened, you would have known.  Second, if you placed a breakpoint in code in which the floating point register stack was non-empty, if the breakpoint was hit, and you resumed execution, a floating point register stack underflow exception would have occurred.  This is because SLX recognizes breakpoints only at points at which computational registers are all empty.  The debugger resets the floating point hardware, resulting in an empty register stack.  When execution resumed, and a value no longer on the stack, but presumed to be on the stack was popped from the stack, by definition a stack underflow exception would occur.

One consequence of fixing this problem is that code generated for floating point expressions containing function calls will now store intermediate results in memory (properly so), in situations where this was formerly not done.  The additional stores and loads can result in 1-bit differences, compared with the old style of code generation.  Such differences cannot be avoided.  Some programs may be affected by 1-bit differences.  One of the programs in our customer program test suite does exactly that.  Results are almost identical, but measurably different.

5.  The "retrieve" statement now properly resolves conflicts between names used both as class names and element names.

6.  Input buffer overruns are now detected and result in run-time errors. Prior to this improvement, SLX did not detect input record truncation performed by underlying C++ library routines.

7.  A preliminary version of Proof3D.slx is now available for users who want to use SLX to generate trace streams for Proof 3D.

8.  SLXDLL.h has been updated to reflect changes in SLX's run-time support. In particular, the internal structure of SLX sets has changed somewhat to resolve conflicts between 32- and 64-bit SLX. This change affects only users who are using C/C++ DLLs that manipulate SLX sets.

End of the EB268 Update

The AN148 release of SLX incorporates the following fixes and improvements:

1.  A problem with user-callable checkpoint/restore has been fixed.

2.  SLX's now treats "dangler errors" as non-fatal.  SLX now issues warnings that can be disabled through the Trap dialog.  Consider the following example:

    new widget -> MyMethod(x, y, z);

In this example, "MyMethod" is a method of the "widget" class.  The "new" operator creates a potentially dangling reference.  If "MyMethod" does not create any references to the  created widget, the widget will automatically be destroyed, because its use count will be zero.  Previously, SLX's philosophy was that dangling references were always unintentional.  This precluded the use of object creation purely for side effects, with immediate destruction at the end of such statements.

3.  SLX's handling of very complex wait until conditions has been improved to eliminate some overhead.  The benefits of this change will be observable only in models that make very heavy use of complicated wait until statements.

End of the AN148 Update

The OV217 release of SLX fixes a compiler problem with boolean expressions that include string comparisons for equality and occur in an if/else context.  While this might sound relatively common, in practice, the exact circumstances required to generate the problem were unusual.

End of the OV217 Update

The CT047 release of SLX incorporates some cosmetic changes and a handful fixes to rare problems encountered by a single user.

End of the CT027 Update

The UG287 release of SLX incorporates the following additions/changes:

1.  A "Compilation Error/Warning Limit" item has been added to the Options menu.  When compilation of a program elicits more than the specified number of error or warning messages, the compilation is terminated.  By default, the count is set to 200.

2.  Several changes have been made to improve detection and recovery from compile-time and run time errors.

End of the UG287 Update

The UG067 release of SLX incorporates the following fixes:

1.  Under certain circumstances, out produced by "print" statements of the form

    print (mystring)    "xxx_yyy";

could contain blank characters before and/or after the "_" substitution field, rather than producing the expected string of contiguous characters.  This error has been fixed.

2.  Recovery from math library errors has been improved in the 64-bit version of SLX.

End of the UG067 Update

The UL267 release of SLX fixes the following problem:

Assignments of the form

    s = substring(x, i, 1);

Are now handled properly when "s" is a static or global variable.  This was a code optimization bug.

End of the UL267 Update

The UL237 release of SLX includes the following improvements:

1.  A loophole in the "augment" statement has been closed.  Prior to this fix, attempts to augment a class from within a precursor module could cause unpredictable results.  SLX now requires that both the original class definition and any "augment" sections applied to the class both be contained in non-precursor modules.  It has always been the case that an augmented class be contained in a non-precursor module.  The requirement that any "augment" statements be placed in non-precursor modules is new.

SLX compiles all precursor modules before compiling any non-precursor modules.  Therefore, a class contained in a precursor module cannot subsequently be augmented, because its definition is frozen.  Likewise, a class defined in a non-precursor module cannot be augmented from within a precursor module, because it's impossible to freeze an addition to a class that hasn't yet been compiled.

2.  The coloring scheme used in SLX's development environment has been extended to highlight string constants in a brownish red color.  If you don't like this new feature, let us know, and we'll make it optional.

3.  A rare case involving the use of string variables as case selectors in "switch" statements has been fixed.

4.  A number of rare code generation problems have been fixed in 64-bit SLX.

5.  A number of debugger features have been cleaned up.

End of the UL237 Update

The UN297 release of SLX includes the following improvements:

1.  Pointer values returned by DLL functions are now validated by SLX.  Returned pointers that never were valid or were once valid, but no longer point to a "live" SLX object are trapped.

2.  A key detection issue with .RTS files has been fixed.  This fix affects only OEM versions of Proof.

End of the UN297 Update

The UN087 release of SLX provides a further correction to the problem addressed in Release AY317.  The fixed problem involved comparisons of equality where both comparands were strings whose lengths were unknown at compile time, but were equal at run time, and the comparison was made in a "branch if TRUE" context.  Note that since "if" statements always use "branch if FALSE," one of the few contexts in which this error could occur was a "switch" statement for which the case selector was a string variable, and one or more case labels were either string variables or named string constants.  While perfectly valid, this usage is somewhat rare, so very few users should be affected by this error.

The AY317 release of SLX fixes a problem with string equality/inequality comparisons where both comparands were strings of unknown and unequal length.  In certain contexts, SLX did a comparison that effectively always assumed equal comparand lengths.

The AY177 release of SLX fixes two problems.

 1.  A problem with single character substrings has been fixed.  This problem was the result of compiler optimizations implemented earlier this year for string operations.

2.  An error recovery problem resulting from using the same name in multiple definitions that included a mixture of private/public attributes has been resolved.

 The AY047 release of SLX fixes a problem with "show-and-go" watchpoints in the SLX Debugger. (The SLX Debugger has an option to show all changes to a watched variable, but continue executing. Normally, execution pauses each time a watched variable changes.)

The PR057 release of SLX is the result of recompiling SLX using more aggressive C++ optimization options.  Programs that rely heavily on SLX run-time support that is written in C++, e.g., input/output support, will see faster runtimes.  This release also incorporates fixes to some SLX Debugger problems. 

The AR137 release of SLX includes the fixes described below. 

Note: The AR137 release replaces the AR087 release previously issued on the Testers page.

1.  The "Sticky Indentation" and Smart Indentation" options have been restored.  These options disappeared as a result of RichEdit incompatibilities exposed in the AR087 release.

2.  A number of problems with unusual combinations of class "destroy" and "final" properties have been resolved.  SLX now detects and prevents recursive entry into a "destroy" property.  (This can happen if code within a "destroy" property attempts to destroy the same object for which the "destroy" property is invoked.)

3.  DLL functions can be declared as returning string results.  This is a notational convenience within the SLX program that calls such functions.  Note, however, that string results are returned via an N+1st C/C++ argument that is tacked onto the function's actual argument list, if any.  This notation is necessary, because C/C++ functions must access a string descriptor that contains the maximum allowable length of a string result and the address of where the string's text is stored.

=== End of the AR137 Update ===

The EB237 release of SLX includes the additions and enhancements described below. 

Note: The EB237 release corrects problems in and replaces the EB227 release issued previously.

This release is a finalized version of the EB167 release previously published on the Testers page.  It incorporates fixes to all outstanding issues.

This release will provide a substantial increase in performance for many SLX users.  The increase you will see depends on exactly what your program does.  We have seen increases ranging from 2-3% to as high as 30%.  The most dramatic speedups are in the following areas:

1.  Programs that make heavy use of set membership queries (the "is_in", "is_no_in", and "contains" operators) will see substantial increases in performance, due to improvements in the underlying algorithms and SLX's code generation.

2.  Programs that include large numbers of calls of short procedures will run faster.  Short procedures containing large string variables, e.g., "string(200) MyString" will run much faster.  However, bear in mind that SLX macros and user-defined statements provide an easy way to generate sequences of SLX statements.  In-line, macro-generated code runs considerably faster than short procedures.  For example, functions such as "DegreesToRadians" should be implemented using macros rather than procedures.

Procedure invocation and object creation require initialization of all local variables to known states.  Typical procedures and objects have many variables that must be zeroed.  In previous releases, SLX's run-time support zeroed out entire instances of objects and procedures when the instances were allocated.  Beginning with this release, zeroing and other forms of initialization are performed by carefully tailored sequences of compiler-generated instructions.  For example, in previous releases of SLX, string variables were zeroed in their entirety, when in fact, zeroing string header information would have sufficed.  (Setting a string's length to zero implies that no characters can be fetched from the string.)

3.  A number of commonplace special cases of string operations have been sped up.  For example, extraction of substrings of length 1 is now performed by in-line machine instructions, rather than by general-purpose run-time support.  Programs that do lots of parsing of ASCII input data will run much faster.

The following additions have been made to  SLX's Options menu:

1.  "Show Wait Until Statistics" enables collection of statistics characterizing the efficiency with which "wait until" statements operate.  Statistics include the total number of "wait until's" executed and the average number of attempts per success.  Low ratios of attempts to successes indicate that a program is using "wait until" effectively.  For example, consider a ratio of 2.  This indicates that a typical "wait until" consists of one FALSE (blocking) condition followed by success when the control variable(s) in the "wait until" change.  High ratios are indicative of "control variable abuse."  Consider a "wait until" statement that causes 1,000 pucks to wait.  If the "wait until" is used to enforce one-at-a-time logic, when the condition becomes TRUE, all 1,000 pucks will re-execute the "wait until".  It is very likely that one will succeed, and the remaining 999 will have to wait again.  Obviously, this sort of operation is very costly.  In such cases, you should use managed queues, in which reevaluation of blocking conditions is done less frequently.

2.  "Show is_in / is_not_in Statistics" enables collection of statistics on the efficiency of these operators.  Statistics include the total number of interrogations and the average number of iterations per interrogation.  The iteration count should be between 3 and 4.  If you see values greatly exceeding 4, let us know, because this is an indication of less than desirable performance.

3.  "Status Refresh Frequency" allows you to specify the frequency with which screen data is refresed as a program runs.  By default, the screen is refreshed every 5 seconds.  If you don't like having the screen refreshed, try specifying a large value, e.g., 5000 seconds.  Updated displays include all debugger windows, the Calls & Expansions window, and the status bar at the bottom of the screen.

=== End of the EB237 Update ===

The AN267 release of SLX includes the additions and enhancements described below. 

1.  SLX now generates more efficient code for arithmetic operations.  Some Math/trig-intensive applications may now up to 7-8% faster.

2.  64-bit SLX now uses SSE instructions, rather than "legacy" (X87) instructions, for nearly all floating point operations.  Exceptions to this rule include math/trig functions, e.g., cos(x),  for which legacy hardware provides machine instruction implementations, but SSE hardware does not.  As a result of this change, some result of some arithmetic operations will differ in their lowest bits when compared to the corresponding operations using solely legacy hardware, so some small differences in output should be expected.  We have made this change for two reasons: (1) SSE is the native floating mode in 64-bit Windows, so generating SSE instructions speeds up the interfaces between SLX and C++ run-time support code, which uses SSE instructions by definition; and (2) it's almost always a good idea to avoid the use of "legacy" features whenever possible.

3.  A number of loopholes have been closed.  The use of the same name as both a variable and a procedure (method) within a class is no longer allowed.  Such usage could be allowed in theory, but a number of complicated restrictions would be required.  Since the restrictions would be difficult for us to describe and difficult for SLX users to remember, we opted to totally disallow this usage.

4.  A new command-line option, "/background" has been added.  This option forces SLX to run at background priority.  Since virtually all SLX applications are CPU-bound, running an SLX model at foreground priority makes it difficult to perform other tasks while the model is running.  Running at background priority greatly reduces interference with other tasks; however, some degree of interference will still be noticeable.  A "Run at background priority" option has been added to the bottom of the "Options" menu.

=== End of the AN267 Update ===

The EC186 release of SLX includes the fixes described below. 

1.  A problem with constant boolean variables, e.g. "constant boolean Myswitch = TRUE", has been fixed.  The problem was caused by faulty handling of the "constant" specification.

2.  A problem with editing very large (greater than 2**31-1) floating-point output numbers with no fractional digits has been fixed in the 64-bit version of SLX.

3.  A problem with very complex object destruction has been fixed in the 64-bit version of SLX.

=== End of the OV306 Update ====

The OV306 release of SLX includes the fixes described below. 

1.  A rare, random problem with creation of Run-Time SLX (RTS) files has been fixed.  The problem depended on random memory contents and was both extremely rare and not strictly reproducible.

2.  A minor problem with source code annotation has been fixed.  This problem affected onlt the appearance of source code.  It had no effect on program execution.

=== End of the OV306 Update ====

The OV216 release of SLX includes the fixes and enhancements described below. 

1.  SLX's status bar (at the bottom of the SLX window) has been improved.  The total amount of memory acquired from Windows is now shown, and for long-running programs, the status bar is updated every five seconds.  The periodic updates and memory status display are useful in detecting infinite loops and memory leaks.

2.  SLX's performance monitor now does a better job of attributing time spent in run-time library functions to the points from which the functions are called.  For example, "Find Object in Set" used to appear as a large consumer of CPU time in many programs.  While accurate, such information wasn't very useful.  SLX now "charges" such CPU time consumption to the SLX statements that invoke the "Find Object in Set" function.  For most library functions, source attribution has been improved; however, for some functions that are used in a wide variety of contexts, e.g., memory management, source attribution is impossible.

One consequence of these changes is that most programs will show flatter CPU usage profiles, since peaks that used to appear for library functions are now spread out over potentially many points-of-call.

3.  A new keyword, "XML_NOBREAKS", has been added to the open and filedef statements.  This keyword defines a file as an XML file in which all data between two successive < ... > fields is returned as a single character string, ignoring blanks, tabs, commas, quotes, and any other punctuation.  Consider the following input record:

    <Names>Jim Tom Peter</Names>

If the above record is read with only the "XML" keyword in effect, "Jim", "Tom", and "Peter" are returned as individual (blank-separated) items.  If "XML_NOBREAKS" is in effect, "Jim Tom Peter" is returned as a single string.

4.  A problem affecting certain forms of wait until has been fixed in 64-bit SLX.  32-bit SLX was not affected.

=== End of the OV216 Update ====

The OV146 release of SLX includes the fixes and enhancements described below. 

1.  Several problems with XML "< ... >" fields that span multiple lines in an XML file have been fixed.

2.  Code generation and run-time support for most forms of string assignment and comparison have been significantly improved.  Many string operations, which were fast to begin with, have doubled in speed.

=== End of the OV146 Update ====

The OV086 release of SLX includes the fixes and enhancements described below. 

1.   Support has been added to make it easier to read XML files:

A.  SLX's "open" and "filedef" statements now support an XML keyword:

    filedef MyXML input options=XML name="Myfile.xml";     // XML specified in a file definition

    open MyXML input options=XML name="Myfile.xml";     // you can specify XML here, too

B.  The following rules apply to reading from XML files:

1.  For each read, leading whitespace (blanks, tabs), if any, is skipped.

2.  If the first character of an input field is "<", SLX reads everything from the "<" character up to and including the terminating ">" character.  The text between "<" and ">" can contain anything.  SLX does not detect the presence of any keywords within the text, nor does it apply any special handling to quoted strings.  In short, "< ... >" fields are returned in their entirety.  Note that if a "< ... >" field is too big to fit in the string variable into which it is read, it is truncated to the declared length of the string variable.  This is normal under SLX and is not considered an error.

3.  Because "< ... >" fields begin with a "<", they can be read only into SLX string variables.

4.  Some "< ... >" fields are followed by raw data.  Consider the following example:

        <Altitude>5000.0</Altitude>

An SLX program that reads the "<Altitude>" field can read the value "5000.0" directly into a floating point variable.  Note that "<" is interpreted as a delimiter when a program is reading from an XML file.  It terminates an input field exactly as a blank or comma would.  Thus, the next read following the read of "5000.0" will start with the "<" character that begins the next field.

5.  The following code fragment illustrates a typical approach for reading an XML file:

filedef MyXML input options=XML name="Myfile.xml";

    read file=MyXML end=end_of_file (token);

        print (token) "Skipped: _\n";

        read file=MyXML (altitude);

        print (altitude) "Altitude = _.___\n";

Note that the code fragment above doe not explicitly look for "</Altitude>" keywords.  In most cases, it's easiest to ignore such items.  The simplest way to structure an SLX program for reading an XML file is to use one giant "switch" statement.  SLX string comparisons are very fast.  On a reasonably fast PC, a typical string comparison might take 10-20 nanoseconds.  However, if a program has to handle a large number of keywords, a more efficient approach may be advisable.  If you're writing a program that only looks for 20 keywords, it's probably not worth worrying about efficiency unless you're reading enormous files.

The first and safest thing you can do to improve efficiency is to place the most frequent cases at the top of the "switch" statement.  (SLX cycles through the cases in order.)  The second thing you can do, which is somewhat riskier, is to exploit any knowledge you have of the context in which keywords appear.  If an occurrence of a given keyword establishes a context in which only a limited number of keywords can be supplied until a keyword that terminates the context is encountered, you can add an inner loop and "switch" statement that processes that context.  Finally, and riskiest, if you have knowledge of the order in which optional keywords can appear, you can supply if/else logic that reacts to the presence of the optional keywords in the order in which they are known to occur.

2.  Support for attaching and detaching files to SLX's built-in "stdout" has been improved.  You can use explicit "open" and "close" statements to attach files to stdout.  Prior to this release, stdout was considered to be a file that could never be closed.  SLX would allow you to attach files to stdout, but would effectively ignore any explicit "close" operations.  Thus, output files so attached would remain open until the end of execution instead of being closed when you though they should be.

3.  The dialog box for reading from the keyboard now includes a button that allows you to terminate execution.

4.  Warning and error messages issued at times containing ten digits to the left of the decimal point, but less than 2147483648.0 could cause unpredictable failures arising from flawed editing of the time.  This problem has been fixed.

=== End of OV086 Update ====

The CT166 release of SLX includes the fixes and enhancements described below. 

1.  Updates on this page are now identified by operating system type (32-bit or 64-bit) rather than being identified as SLX-32 or SLX-64.  Updates for 64-bit systems include both SLX-64 and SLX-32, while updates for 32-bit systems include only SLX-32.

2.  The documentation and sample files for using DLLs in conjunction with SLX have been updated.  SLXDLL.PDF are located in the SLX\Doc folder, and the sample files are located in SLX\DLLs.  Note that SLX now assumes Microsoft standard alignment of data.  Doubles must be 8-byte aligned.  On 64-bit systems, pointers must be 8-byte aligned.  SLX formerly required only 4-byte alignment of doubles.  You can generate proper header files for your DLLs by compiling the SLX program that uses them and then clicking File, Write DLL Header File.  This has always been the recommended approach, since it guarantees agreement between SLX and your DLL functions.

3.  Problems with #ifdef have been fixed.  In addition, SLX source code following a false #ifdef is now shown in a gray color with strike-through annotation.

4.  Supplying more than one argument to the abs() function is now properly diagnosed as an error.  Previously, any arguments after the first argument were silently ignored.

5.  A problem with file qualifications in SLX "import" statements has been fixed.  By definition, SLX has always assumed and continues to assume that partially-qualified files names are relative to the directory containing the source code containing the import statements.  SLX constructs the full file name by appending the partially-qualified file name to the directory containing the SLX source code.  If the file cannot be found, SLX next attempts to treat the partially-qualified file name as relative to the directory containing the root file of a compilation.  This is the case that is fixed in this release of SLX.  Previously, when SLX found an imported file using the second step described above, it "remembered" the fully-qualified file name incorrectly.  This had no effect on program execution; however, if you tried to open such a file (to set a breakpoint, for example), the SLX Debugger was unable to detect the fact that the file had already been compiled.

6.  Several lingering 32-bit dependencies in SLX-64 have been fixed. 

The EP276 release of SLX includes the following fixes and enhancements:

1.  A number of DLL-related features have been improved.  "Write DLL Header" in the File menu now generates .h files that can be used when compiling under either a 32-bit or 64-bit environment.  The slxdll.cpp "starter" library and slxdll.h files, both located in the DLLs folder, have been revised to reflect changes into SLX and to achieve consistent operation on 32- and 64-bit platforms.

2.  A code generation problem with "position(1) in set" when the set is empty has been fixed.  This problem produced access violations, so you needn't wonder if any "silent" failures might have occurred in your code.

3.  A "describe" verb has been added, allowing you to supply textual descriptions for variable names, macro names, and defined statement names.  Supplied descriptions are kept in a program's symbol table, and the information is displayed when you right click on a variable name and then click on "About".  This feature is especially useful if you're writing macros and statement definitions that are used by others.  See the file assoc4x.slx in the Sample folder.

4.  A new option, "invocation", has been added to the diagnose statement, e.g.,

    diagnose invocation "You have specified the wrong kind of widget";

When executed, this form of the diagnose statement highlights the invocation of a macro or defined statement and displays the specified message beneath the invocation of the macro or statement.  Previously, the diagnose statement was limited to diagnosing the caller of a procedure, e.g., "diagnose caller", or diagnosing a function argument or macro/statement operand.  For an example, see assoc4x.slx.

The EP186 release of SLX includes the following fixes and enhancements:

1.  Recursive creation of objects is now permitted.  For example, if you're building a tree, it might be convenient to recursively create children of a given node from within the class's "initial" property.

Recursive object creation was allowed in earlier releases of SLX, however, when class arguments were recently converted to static memory allocation (to reduce the size of parameterized class instances), recursive allocation was no longer possible, because it would lead to overwriting the single, shared copies of a class's arguments.  SLX now generates code to push and pop class arguments, thereby making recursive allocation once again possible.

2.  Improvements have been made to compile-time semantic error recovery.

The EP086 release of SLX includes the following fixes and enhancements:

1.  Handling of destruction of nested objects has been improved.  Suppose that an object of class widget contains a local instance of an object of class inner_widget named Joe.  Each widget object has a use count, and each "Joe" inside each widget object has its own use count.  The use count of each "Joe" object starts out at 1, because containment in an outer object is a use.  The use count of a Joe object can be increased by placing it in a set or storing pointers to it.  When a widget object is destroyed, the use count of its Joe object is reduced by 1, and if the Joe object's use count goes to zero, it is released.  If the Joe object's use count is not reduced to zero, it cannot be released.  All of this works properly and has for a long time.  Given the architecture of SLX use counts, there really is no other way such behavior could be handled.

When a widget object is destroyed, but its Joe object cannot be destroyed, the Joe object should be severed from its containing widget.  Until this release, such severing was improperly done.  While this had no effect on program execution, it could cause all kinds of confusion for the SLX debugger, which under certain circumstances, could attempt to access information about a Joe object's containing widget, even though the widget object had been released.   Released objects are, of course, frequently recycled.  Thus a situation could arise in which a currently extant widget was interpreted by the SLX debugger as the widget containing multiple prior instances of Joe objects.

The problem has been remedied by properly severing the connection between Joe and its containing widget if the widget is destroyed.  One unavoidable ramification of severing is that after severing, a widget's Joe object is can no longer be known as "Joe", because "Joe" has meaning only in the context of a widget object.  After severing, each Joe object is known to the SLX debugger as inner_object n, where n is the inner_object's instance ID.

2.  The SLX debugger's ability to display large numbers of objects and pucks has been greatly improved.  Assume that you're using the debugger, and the program you're debugging has 100,000 objects.  In the past, opening the debugger's "All Objects" window took a very long time.  Beginning with this release, all SLX debugger windows that use Windows ListView controls, e.g. "All Objects", "All Pucks", etc., are implemented as so-called "virtual lists".  For such lists, SLX maintains all data internally (as it always has anyway), and provides upon demand from Windows only the information to be made visible within a window.  So, for example, even though there are 100,000 objects that could be displayed, overhead is incurred for only a small fraction of them.

In addition, you can now type the first few letters of items in the column by which a list is sorted, and the list will very quickly scroll to the closest match.  (A biniary search is performed.)

3.  The SLX menu bar now includes a "Find" item, available when a program is being debugged.  Clicking on this item brings up a dialog box that allows you to quickly locate objects or pucks by name/number.

4.  A number of 64-bit-specific code generation problems have been repaired.

Release AY226 has been posted on the Testers page.

Release AY226 of SLX includes the following updates:

SLX's on-line help has been updated.  The latest versions of Chapters 1 and 2 of Simulation Using SLX are included in this release. 

A problem with constant Boolean expressions has been fixed.

"Dangling" pointer references are now handled properly for set membership operators ("is_in", "is_not_in", and "contains").  "What is a dangling reference?" you ask.  A dangling reference is a reference to an object that is contextually transitory, that is, it's a reference that disappears automatically.  The following code contains three examples of dangling references:

        print "It's a miracle!\n";

In each of the first three statements of main, a widget is created, but immediately disappears, because there are no further references to it.  SLX assumes such usage is unintentional and treats it as a run-time error.  The first statement of main is an example of the error that is corrected in this release.  Prior to this fix, SLX failed to decrement the use count of the created object.  This had several undesirable effects.  First, it was impossible to destroy such objects, because their use counts were always too high.  Second, if you tried to display all uses of such objects with the debugger, the debugger would complain that it couldn't find all the alleged references.  Finally, dangling references went undetected.

The set membership example shows how the new operator caused problems.  There are other ways in which similar problems could arise with set membership operators.  For example, the use of a pointer-valued procedure to specify the object whose set membership was to be tested also caused problems.  When a pointer value is returned by a procedure, the use count of the object to which the pointer points is incremented within the procedure.  This is necessary, because the procedure has no knowledge of how the returned pointer value will be used, and the use of the object really does go up by 1 for a very short period of time.  What was missing was the immediate decrementing of the object's use count by the caller during evaluation of the set membership operator.

Release PR246, located on the Testers page, incorporates a fix to the "retrieve" statement.  Under certain rare circumstances, entries in the data structures traversed by the retrieve statement could become cross-linked, resulting in one of two very bad things: access violations or infinite loops.  You needn't worry about whether this bug may have affected you in the past.  If it did, the chances are extremely high that you would have noticed it.

Releases AR136, PR036, and PR126 of SLX includes some improvements to SLX's I/O subsystem.  See details on the Testers page.

Release AR236 of SLX includes a performance upgrade and closes a loophole that existed in the use of SLX methods.

The hashing algorithm used for determining set membership has been improved.  An example was brought to our attention in which a highly stylized, repeated pattern of object addresses caused undesirable clustering that lead to reduced performance.  The hash algorithm has been tweaked.  This change has no effect on anything other than performance.

The loophole that existed in the use of SLX methods is illustrated below:

Release AR076 of SLX fixes a problem with constant Boolean expressions and includes a major retooling of algorithms used in wait until processing.

An SLX user recently provided us an example in which a Boolean expression containing a constant comparison, e.g., "if (... 1 == 1 ...)" was incorrectly compiled.  To shed further light on the problem, we used our RCG tool for testing Boolean expression evaluation.  "RCG" stands for random code generation.  The RCG tool is an SLX program that generates SLX source code containing large numbers of Boolean expressions with randomly selected terms.  In each case, the correct answers are computed by the RCG tool, and comparisons is generated, comparing the actual values computed by the SLX program when it runs with the pre-computed correct values.  This simulation-inspired approach allows us to test thousands of cases very quickly, change the random number seed, and test thousands more.

While we were at it, we ran the corresponding utility for testing "wait until" statements and found that in certain rare cases with very complex comparisons, ands and ors (all three required) nested in particular forms failures could occur.  The failure rate was extremely low, but non-zero.

Release AR076 incorporates retooled algorithms.  While this release has passed many thousands of tests, it is what we call a "foundation shaker", so we have taken the unusual step of posting the update here, rather than on the normal SLX Updates page.

Release EB286 of SLX fixes a problem with the successor and predecessor operators when used with indirectly referenced sets.  Consider the following example:

In the above example,  the SLX compiler was confused by "in *testSet_p" in the last statement.  The compiler keeps track of primary and secondary types of expressions, but not tertiary types.  In this statement, the primary type of "*testSet_p" is pointer, and its secondary type is set; i.e., it is a pointer(set).  The interesting question here is "set of what?"  Since "of what" is determined by values assigned to "testSet_p" at run-time, the compiler should have assumed "set(*)", and generated code to validate the assignment of the successor operator into "c".  Unfortunately the algorithm for doing so had a bug that resulted in a spurious compile-time error message.  The algorithm has been corrected.

Release EB246 of SLX includes the following additions/updates:

1.  DLL header files produced by the SLX compiler for DLL functions returning pointer values specified C/C++ keywords in the wrong order,

e.g.,

    EXTERN_C EXPORT struct obj CDECL *retptr();

SLX now generates the proper syntax, e.g.,

2.  Consider the following wait until statement:

    wait until (ptr -> count > 0);

SLX requires that at least one variable in a wait until expression be a control variable.  In the above case, either "ptr" or "count", or both, must be a control variable.  If neither are control variables, the SLX compiler will complain.  The variable "count" can be an element of more than one class.  The particular version of "count" that is used is determined by the type of "ptr".  We recently encountered a situation in which "count" was a member of two different classes.  In one class, it was a control variable, and in the other class, it was not.  When the non-control version of "count" was used in a wait until statement (an error), the SLX compiler was confused by having previously seen the control version of "count", and the compiler failed to diagnose the error.  Under such circumstances, the behavior of the wait until statement was unpredictable.

The compiler's algorithm for resolving multiple definitions of class elements now properly recognizes the presence/absence of "control".

3.  Run-time support for wait until has been further tweaked to resolve an additional ambiguity of the sort described in the UG045 UN305 updates.  As a result of the tweak, users may notice slight differences in results, due to reordered processing of delayed pucks.  This problem should be very rare.  For example, our rather extensive suite of test programs was unaffected by this change.

Release EB166 of SLX includes the following additions/updates:

1.  A complex and presumably rare problem with boolean expression evaluation has been fixed.  The following example illustrates a context in which the error occurred:

procedure myfunc(boolean arg)

    {

    ...

    }

procedure xxx()

    {

    int    i;

    i = 1;

    while (i <= 10)

        {

        if (i == 3)

            break;

        myfunc(i != 3);                // boolean argument is an expression

        print (i)        "i = _\n";

        }

SLX evaluates boolean expressions as a sequence of conditional branches.  In a complex boolean expression, there can be many branches, all of which the compiler keeps on a list until it determines the ultimate TRUE and FALSE branch targest for the entire expression.

The problem that existed prior to this release of SLX is that the compiler failed to create a separate list for boolean procedure argument evaluation.  Thus, the lists of branches for "i <= 10" and "i != 3" became commingled, leading to incorrect branching.

2.  An error recovery problem with improperly delimited string constants has been fixed.

Release EB036 of SLX includes the following additions/updates:

The implementation of the switch statement when selecting cases of an enumerated type has been changed from a linear search to direct transfer via a compiler-generated table.  This optimization was added at the request of a user who makes use of very large switch statements that operate on enumerated types containing up to several hundred values.

The implementation of the switch statement on data types other than enumerated types remains unchanged.

Case labels for enumerated types are henceforth restricted to constant values.  Note that SLX's implementation of the switch statement for all other data types is very general.  Consider the following:

    switch (TRUE)

            {

case a < b: ...        // case label is an expression!

            break;

            ...

            }

Release AN256 of SLX includes the following additions/updates:

1.  A loophole in the use of the reactivate list= statement has been closed.  The reactivate list= statement was designed to be use only in conjunction with the wait list= statement; however, run-time support for reactivate list= failed to verify that the list upon which it was operating was legitimately constructed by wait list=.  The use of user-constructed, ad hoc lists could have disastrous consequences.  Run-time support has been improved to detect such erroneous usage.

2.  The Debugger's "smart cursor" and "right click on variable name" features have been further refined.  A number of cases in which they failed to properly recognize and provide access to lower-level information have been fixed.  Smart cursor descriptions have been refined to offer better consistency among differing contexts.

3.  A number of output formats in H7.slx, the SLX implementation of a subset of GPSS/H, have been revised to provide better output.  Any users who are using h6.slx, h5.slx, or even older files should upgrade to h7.slx

Release EC195 of SLX includes the following additions/updates:

SLX's browser window is now read-only.  To modify source code, you must open a conventional source window.  This change was made because (1) when the browser window, and an open source window contained the same source code, SLX did not apply changes made in one window to the other window, and (2) SLX never applied changes made in the browser window.  These shortcomings will be addressed in the future.

Release EC145 of SLX includes the following additions/updates:

1.  The SLXCheckpointExists function has been added to allow users who dynamically issue checkpoints and restores to test the existence of a given checkpoint.  The following example illustrates the use of the new function:

boolean    exists;

                ...

                exists = SLXCheckpointExists(ID);

2.  If a priority was specified in a fork statement, and the priority was inadvertently specified as a floating point value, the required conversion to integer produced unpredictable results.  (Priorities must be specified as integer values.)  Specification of a floating point priority now elicits a warning message, but the conversion is done correctly.

Release OV275 of SLX includes the following additions/updates:

1.  Under certain circumstances, the "retrieve" statement could fail to find objects to be retrieved from a set based on a combination of floating point attributes.  This problem has been fixed.

2.  Additional options have been added to the "for each" statement:

for (w = each widget in widget_set with w -> weight > 10)    // "with" clause selects only specified objects

for (w = each widget in widget_set after w0)    // begin searching after a specified object in a set

for (w = each widget in reverse widget_set before w0)    // begin searching before a specified object in a set (reverse order required)

for (c = each COLOR after RED)    // enumerated type iteration starting at a specified point

for (c = each reverse COLOR before GREEN)    // reverse enumerated iteration starting at a specified point

Release OV215 of SLX includes the following additions/updates:

1.  Memory management has been further improved for very large models.

2.  Additional details have been added to the Help, Memory Usage display.

3.  A problem that could cause SLX's built-in performance monitor to crash in memory-intensive applications has been fixed.

Release OV115 of SLX includes the following additions/updates:

1.  A number of enhancements have been made to SLX's memory management routines.  SLX now requests memory directly from Windows, rather than going through intermediate layers of software.  Furthermore, SLX now grabs memory from Windows in much larger chunks, so it asks for more only when it has allocated all available portions of a large chunk of memory.

2.  The Help, Memory Usage tool has been expanded to show additional information that may be helpful to users who are trying to run very large models.

3.  The performance of "wait until" reactivation of delayed pucks has been improved.  The revised algorithm produces results identical to the previous algorithm; however, it does so in a different order that is far more efficient.  Users who have large numbers of pucks piled up in wait until statements should see an improvement.  Of course, allowing large numbers of pucks to pile up in wait until statements is a bad thing to do.  Under such circumstances, one should take a more proactive approach to queue management.

4.  Some issues with respect to the debugger's state across checkpoint/restore have been resolved, resulting in better behavior.  For example, if you set a time trap, issue a checkpoint, run for a while, issue another time trap, and then restore model state to the saved checkpoint, the second time trap will be in effect after the restore.  Previously, the original time trap was restored, and the latest time trap was forgotten.

Release EP225 of SLX includes the following additions/updates:

A problem with network security keys has been fixed.  The problem was as follows:

1.  A network security key was being used.

2.  The key had permission for a "full" version of SLX, but lacked explicit permission for Run-Time SLX.

3.  An RTS file was run using a command-line invocation of SLX, e.g.,

    se /run/screen myprog.rts

Under the above circumstances, SLX failed to allow a "full" license to be used as a Run-Time license.

The set keyword of the empty set statement is now optional; i.e.,

    empty set myset;

and

    empty myset;

are now equivalent.

Release EP135 of SLX includes the following additions/updates:

A problem with the round function has been fixed.  The round function is used to round floating point values:

    x = 2.6;

    i = round(x);        // i = 3

A new statement, empty set, has been introduced:

    set(widget)    wset;

    ...

    place ... into wset;

    ...

    empty set wset;        // remove all members from wset

Note that "empty" is now a reserved word in SLX.  If you have programs that use "empty" as a variable name, you'll have to choose a different name.

Release UG195 of SLX includes the following additions/updates:

Final cleanup on the changes to set operations made in Release UG045 has been accomplished.  One last lingering problem with very large numbers of seta & objects has been fixed.

Release UG175 of SLX includes the following additions/updates:

A number of general  improvements have been made to security key interrogation.  Users who use more than one security key on the same machine should now see more logical behavior in the merger of product permissions and license dates retrieved from more than one key.

Release UG045 of SLX includes the following changes:

A further correction has been made to the changes implemented in Release UN305.  Under certain circumstances, reactivated pucks were merged into the CEC with higher importance given to original blockage chronology than to puck priorities; i.e., priorities didn't always work as expected.  As a consequence of this correction, some models will produce slightly different results.

A rare problem with sets has been fixed.  The circumstances under which the problem could arise were as follows:

1.  An object was being removed from a set, and the set was the last usage of the object; i.e., the object's use count was 1.  Note that for the use count to be 1, there could be no active pointers to the object.  Thus, the "remove" statement has to be something such as "remove first widget in myset from myset" (no stored pointer to the first widget).

2.  The object had to contain a set.  Implicit destruction of the object caused implicit destruction of the set, which in turn caused all members to be removed from the set.

3.  One of the objects in the destroyed set had to be in the same hash table thread as the original object being destroyed.  SLX uses a large hash table for quick access to (set, object) bindings.  Depending on the number of (set, object) pairs, the hash table can be quite large.  (SLX starts out with a table size of 1024 and doubles it when necessary.)  Thus the probability of condition 3 was at most 1/1024 and considerably smaller in large models.

4.  The above conditions lead to contamination of the hash table, with somewhat unpredictable consequences.  Typically, contamination would give rise to spurious complaints about objects not being in a particular set, even though the objects actually were in the set.

Release UL135 of SLX includes the following changes:

A problem with spurious privacy violations has been fixed.  Under certain circumstances, an attribute of the same name contained in multiple classes, but private in some classes

and public in others caused the SLX compiler to complain about nonexistent privacy violations.  The problem occurred when the compiler encountered a private version of an attribute from the "wrong" class.  The process of searching through multiple classes for attributes of the same name to find the "right" version was performed after privacy was considered; i.e., the search was performed too late.  The order of these two steps has been reversed, so that privacy is examined only after the "right" class is found.

Release UN305 of SLX includes the following changes:

A subtle problem with reactivation of pucks that were previously blocked in wait until statements has been resolved.  When a control variable is altered, and pucks have been delayed in wait until statements dependent on the state of the control variable, all such pucks are placed back on the current events chain (CEC) to retest their wait until conditions.  Such pucks are supposed to be placed on the CEC in their original order.  This approach guarantees that pucks previously blocked by a wait until will get to retest their blocking condition before pucks of equal priority that came in "later."  In simple queueing models, the SLX approach prevents new members of  a queue from "sneaking" by previous members.  The problem fixed in this release arose when pucks with equal move times were reactivated as a consequence of a change in a control variable.  Prior to this release, the merger of such pucks back into the CEC was done by comparing move times.  In the case of equal move times, this comparison yielded ambiguous results.  The problem has been rectified by using unique serial numbers to resolve ties, rather than move times.  Each time a new puck is created, and each time a puck comes out of an advance statement, it is assigned a new (higher) serial number.  As a consequence of removing this ambiguity, some models will produce slightly different results.  Unfortunately, there's nothing that can be done to prevent this, because we had to remove the ambiguity.

Release UN175 of SLX includes the following changes:

A number of user interface problems with SLX's performance monitor window have been fixed.  Scrolling through the lines of this window by means of up/down arrow keys and/or the PgUp/PgDn keys no longer causes disconcerting loss of keyboard focus.  Resizing and other window management functions have been cleaned up.

The SLX Debugger's smart cursor now properly handles scalar INOUT procedure arguments.  Hovering over these variables formerly caused display of incorrect data.

Release UN075 of SLX includes the following changes:

An option has been added to have SLX change modified source files any time you exit SLX.  (Take a look at the notes for Release UN025.)  You can control this option by clicking Options, Auto-Save Modified Source.  Note that this option causes saving of modified files any time you leave SLX, including occasions when you accidentally click outside SLX's main window.  The primary purpose for this option is to facilitate the use of external source file editors.  If this option is enabled, and  you temporarily switch out of SLX to edit a source file with your favorite editor, the file will be saved when SLX is suspended.  There is an obvious risk associated with enabling this option.  If you're in the habit of doing lots of experimental editing, and you're used to thinking "I can always exit and start over," you should not enable this option, because if you accidentally click outside SLX's main window, all modified source windows will be written back to their files.

A problem with display of very long strings in the SLX debugger's Local Data and Global Data windows has been fixed.

Release UN065 of SLX includes the following changes:

A column has been added to SLX's performance monitor, showing the number of bytes of code compiled for a statement.  The practical reason for including this information is that it gives you a measure of complexity of the source code.  If a line of source code is compiled into hundreds of bytes of code, and that statement consumes a lot of CPU time, there may be little you can do to improve performance, because the statement is inherently complex.  On the other hand, if a statement is compiled into a relatively small number of machine instructions but consumes large amounts of CPU time, it is because the statement is being executed many, many times.  In such cases, you may be able to rearrange your code to improve performance.  For example, you might be able to move loop-independent code out of a loop.

Release UN025 of SLX includes the following changes:

Several changes have been made to SLX's user interface.

A problem with the F2 key has been fixed.  (The F2 key is used to expunge error messages and statement/macro expansions from source code windows.)  When a window is cluttered with lots of messages, it can become difficult to edit source code.  F2 eliminates the clutter.  Under ceratin circumstances, pressing F2 could cause editing changes to be lost.  This problem has been fixed.

SLX no longer automatically saves source code files when you switch out of SLX to another application.  We have come to the realization that automatic updating of source files is just too insidious.  If you're in the habit of exiting SLX to edit source files using an external editor, you now will have to explicitly save the files if you've changed them within SLX before switching to your editor.  Most users either do all their exclusively within SLX or exclusively outside SLX.  This change affects only those who use a mixed approach.

If you make changes to a source file and save it within SLX, SLX will now refresh the source window containing the file.  If you close the window containing the source file and reopen the file, the saved version will be reread into memory.  In the past, under certain circumstances. SLX would appear to get "stuck" on the version of the source file that was most recently compiled.  To "unstick" SLX under such circumstances, you had to completely exit and restart SLX.

If you change a file outside SLX, when you return to SLX, you will by default be warned that the file has been modified, and you will be asked if you wish to replace SLX's copy with the externally changed copy.  Users who routinely edit source files with an external editor will find the default warning cumbersome, so we have added an option to suppress the warning.  You can control issuance of the warning by clicking Options, Auto-Apply External Edits.

A recent improvement to SLX in which unnecessary checks for NULL pointer were eliminated went too far and allowed some instances of NULL pointer references to go undetected, almost always resulting in run-time interrupts.  This problem has been fixed.

Release AY275 of SLX includes the following changes:

A rare problem with explicit qualification used to distinguish identically-named elements of different classes has been fixed.

For example, assume that classes widget1 and widget2 each contain the following:

    typedef enum { ON, OFF }    widget_state;

    widget_state    state_variable.

If w is a pointer(widget1), SLX had problems with constructs such as the following in certain contexts:

    w -> state_variable = widget1::ON;

This problem has been fixed.  This problem should have been extremely rare; however, it cropped up in h7.slx, a Wolverine-provided file that includes statement definitions and macros for supporting GPSS/H constructs.  Note that the in the above example, which parallels that of h7.slx, explicit qualification of ON is unnecessary, since w can only point to and object of class widget1, and the meaning of "state_variable" in this context is clear without qualification.  Further note that duplication of enumerated type definitions is usually a poor idea, anyway.  In the above example, a single definition of "widget_state" at the module level could have been used, rather than duplicating the typedef statement.  Of course, use of a single, shared typedef would also obviate the need for qualification, since there would be only one definition.

Release AY235 of SLX includes the following changes:

1.  Handling of an obscure form of "dangling" pointer references has been improved.  Consider the following example:

    i = (new widget) -> j;

Unless the initial property of widget saves one or more pointers to the created object, or places it into a set, the created object immediately disappears.  SLX has always treated the disappearance of a "dangling" reference ("new widget" in this case) as a run-time error, and it continues to do so.  However, in some cases the check for automatic disappearance was made before additional references to the object could be recorded; i.e., the test was performed too soon.  One such case was as follows:

    (new widget) -> my_method();

In this case, the test for disappearance was made prior to execution of my_method().

SLX now performs testing for disappearing references properly.

2.  The "clear" statement has always had rather obscure semantics.  This statement was adapted from GPSS/H with mixed success.  The most common use of the clear Is as follows:

    clear system;

Execution of the clear statement consists of two phases.  In the first phase, the object(s) or set(s) supplied as operands to the clear statement are cleared; i.e., the clear properties of their respective classes are executed.  In the second phase, all active pucks except the puck executing the clear statement are destroyed.  Note that SLX requires that the clear statement be executed only by a "main" puck (usually main 1/1).  This is because SLX requires at least one puck for a main program at all times.

A number of SLX users have requested a form of the clear statement that executes only phase 1, omitting phase 2.  A variant of the clear statement has been implemented to accomplish this.  By supplying the new  "object" keyword, one can request phase 1 execution only; e.g.,

    clear object qset;

Release AY115 of SLX includes the following:

The Debugger's smart cursor has been further enhanced.  If you hold the shift key down when the mouse hovers over the name of a macro or defined statement, the expansion of the macro/statement will be revealed or hidden if it's already visible.  This provides a very quick way of examining expansions.

In Release PR185, the SLX compiler's rules were relaxed to allow use of the same symbol as an enumeration constant and a class name.  This change had the unforeseen side effect of disabling detection of multiply-defined enumeration constants within the same enumerated type.  In the following example, the second (duplicate) use of OFF went undetected as a result of the change.  This problem has been fixed. 

    typedef enum { ON, OFF, OFF }    MachineState;

Release AY025 of SLX includes the following:

The Debugger's "smart cursor" is now enabled by default.

Performance monitor output has been expanded to include an additional column of subtotals.  For example, if you view performance results sorted by scope, subtotals will be shown for each procedure or class.  The example shown in the notes for Release PR135, below, has been updated to show this column.

Code that closed the loophole described in the notes for Release PR195 has been tweaked to eliminate an obscure case in which a correct construct was incorrectly flagged as a privacy violation.

Student SLX (available on the Download page) has been revised to properly enforce student version limits. 

Release PR275 of SLX includes the following:

Upon exiting, SLX now erases any checkpoint files that have been written during a run.  Since these files are valid only for the current run, erasing them causes no harm frees up disk space.

Performance monitor data captured in a file now includes a header identifying the name of the file and the date on which it was witten.

Release PR255 of SLX includes the following:

SLX's built-in performance monitor can now store its results in a file.  To do so, right click in the performance monitor window after running an experiment.  Note that results are written to a file in the same order in which they appear on the screen.  You can change the order by clicking on any of the first four column headings in the table of results.

A number of lingering performance monitor problems caused by very large models have been fixed.

The performance of SLX's user-callable checkpoint/restore feature has been significantly improved for very large models.  Prior to Release PR255, SLX stored user-callable checkpoint data in virtual memory.  For very large models, this strategy caused excessive consumption of virtual memory and lead to considerable page thrashing.  If the memory footprint of an SLX model exceeds a threshhold (currently 50MB), SLX now writes checkpoint data to disk files.

Release PR195 of SLX includes the following:

A number of  set operation problems introduced in Release PR185 have been fixed.

A loophole that existed with SLX methods has been closed.  Prior to this release, if you defined private SLX methods, their privacy could be violated by accessing them via universal pointers (pointer(*)).  Consider the following:

Release PR185 of SLX includes the following:

Additional improvements have been made to SLX's performance monitor.

The smart cursor has gotten a bit smarter.  It now can show the contents of variables that it previously couldn't display.

An obscure problem that prevented using the same variable name both as a class name and as an enumeration type has been fixed.

Performance of set operators has been improved.  These include first(), last(), successor(), and predecessor() operators.  The position() operator has also been improved, but use of position() is still potentially costly, since execution requires performing linear searches, which can take a lot of time.  On a reasonably fast machine, the time per element in a set position() search should be around one nanosecond.  Accessing a randomly selected i-th member of a 1,000-element set should take about 250 Ns.  SLX is smart enough to compare i to the size of the set and perform its search from the start of the set or backward from the end of the set.  This cuts the average search time in half.  If the members are uniformly distributed in the set, on the average a search terminates after examining one half of the potentially maximum number.  Half of half of the set implies a mean search time of 250 Ns.

Release PR145 of SLX includes enhancements and improvements to SLX's built-in performance monitor, introduced in release PR135.

The performance monitor is now capable of detecting time spent in DLL functions called by an SLX Model.  In addition, a number of improvements have been made to performance data displays, and the overhead of monitoring a program has been reduced.

Release PR135 of SLX includes one minor improvement and one very cool new feature.

The new major feature is that SLX can now monitor and display the distribution of CPU time consumed in the execution of an SLX program.  To enable this feature, click Monitor, CPU Time Consumption.  (The latter is at the bottom of the popup menu.)  A CPU Time Consumption window will appear.  The following example depicts the contents of this window after running a program:

The window shows percentages of time spent in your code and in SLX code.  For time spent in your code, the name of the file containing the code, the line number within the file, and source code (truncated if too long) are shown.  For time spent in SLX, this information is unavailable.

By default, the information is sorted by decreasing percentage.  In the above example, the largest single consumer of CPU time was SLX's internal code for allocating instances of objects procedures.  By clicking on the column headers for any of the first four columns, you can change the sorting.

The Scope column depicts the name of the procedure or object in which CPU time is consumed in your code, or a description of a function being performed in SLX code.  Clicking on a name in the Scope column of a row that shows time spent in your code will display the source code, in context and highlighted in red.  If necessary, a source code window will be created and/or placed on top of any other source code windows.

The Code Size column shows the number of bytes of machine code for compiled SLX source code.  See the description of Release UN065 (above) for details.

You can turn the CPU time consumption feature on or off at any time.  By setting breakpoints, you can restrict information collection to a desired interval of activity.  For example, if your program reads input files, runs for a while, and writes output files, and you want to see only the middle portion, you can do so by setting breakpoints.

Since this is a brand new feature that requires access and manipulation of very complex data structures, you should exercise caution when using it.  If you're actively modifying your program while testing it, be sure to save all changes before monitoring CPU time consumption.

As always, let us know your reactions.

The minor improvement is that SLX will now properly search the active Windows PATH for user-level imported files.  (User-level files are enclosed within quotation marks; system-level files are enclosed between "<" and ">" characters.)  Prior to this change, SLX would first attempt to use an imported file name as is, and if that file could not be found, SLX prefixed the file name with the directory containing the root file that was being compiled.  Although the first attempt should have found files located in directories specified in the Windows PATH environment variable, it did not.

Release PR075 of SLX includes the following improvements:

The compiler does a better job of handling illegal characters in SLX source code.  Previously, when certain low-valued ASCII characters that are not in the allowable SLX character were inadvertently entered into a source file, the compiler was sometimes unable to pinpoint their exact location in an error message.

The information displayed under Help, Memory Details has been expanded to include a line that shows the total memory consumed by dynamically-dimensioned arrays.

Release PR055 of SLX includes a very nice addition to the SLX debugger. Those of you who routinely use the debugger will enjoy this one.

If you click Options, Browser/Debugger Options, you'll see a new option, "Enable Smart Debugger Cursor".  When enabled this option will cause tooltip-style windows to pop up when the cursor hovers over a variable name during a debugging session.  At present, support is limited to displaying simple scalar variables; i.e., you still have to right click to see objects and arrays.  If you make any changes to the source code, the smart cursor is turned off until you recompile your program.  (Once you change the source code, the debugger can no longer relate symbols in your program to their run-time memory locations.)  Try this feature and let us know what you think.

Release AR245 of SLX includes the following updates:

The functionality of the SLX Debugger's "smart cursor" (see Release AR225) has been enhanced.

Release AR225 of SLX includes the following updates:

A recently introduced bug that caused multiple duplicate breakpoints to be accumulated across compilations when the Remember Breakpoints option was used has been fixed.

Release AR155 of SLX includes the following updates:

The sizes of buffers used for file I/O have been increased from 1024 bytes to 4096 bytes.  Prior to this change, reading or writing records longer than 1024 bytes produced unpredictable results.  If the 4096 limitation causes problems, we'll incorporate dynamic buffer sizing, which is what we should have done in the first place.

Release AN285 of SLX includes the following updates:

Debugger displays, notably the "watched Variables" window, now properly display null strings.  (An extraneous "garbage" character has been eliminated.)

Several problems with "#" symbols used in macro/statement definitions inside an #ifdef ... #endif block have been fixed.  In cases where the #ifdef condition was false, the presence of "#" symbols could cause improper detection of the "#endif" corresponding to the "#ifdef".

Release AN195 of SLX includes the following updates:

A number of problems with #ifdef processing when writing an RTS file have been cleared up.  In some cases, #ifdefs were evaluated out-of-sequence when an RTS file containing them was run.

Release AN115 of SLX includes the following updates:

A number of problems with #ifdef processing have been cleared up.

Release AN035 of SLX includes the following updates:

A number of debugger display update problems have been resolved.

The SLX compiler now supports C-like #define, #undef, #ifdef, #ifndef, #else, and #endif statements.  For an example, see ifdefslx.slx in the C:\Program Files\Wolverine\SLX\Sample directory after installing this update.  Note that SLX does not support any form of text substitution for #defined symbols.  (If you need to perform text substitution, you should use SLX macros or defined statements.)  The primary use of this new capability is to provide the ability to easily configure multiple versions of a model with minimal source code changes.

A new SLX-provided function, RegisterCheckpointCallback(), has been added to SLX's DLL interface.  If you are using one or more DLLs and using SLX checkpoint/restore, registering one or more callback functions allows you to take appropriate actions within one or more DLLs when an SLX checkpoint is recorded, when execution state is restored to that of a previously recorded checkpoint, or when a checkpoint is released.  The motivation for this feature is to allow you to save, restore, and release data manipulated by your DLLs outside of SLX, and about which SLX has no knowledge.  Registered callback functions are called for all checkpoint-related actions, including both those issued via the SLX Debugger and those issued under program control.  If you use this capability, you should not enable the automatic recording of a checkpoint at time zero, since the checkpoint will almost certainly be recorded prior to the first opportunity your DLLs have the opportunity to issue a RegisterCheckpointCallback() call.  Finally, note that using RegisterCheckpointCallback() requires that you (1) include a "Connect()" entry point in your DLLs, and (2) in your Connect() function, you save the address of an SLX-provided vector of pointers to functions, one of which is used to call RegisterCheckpointCallback().  After installing this update, take a look at cptcallback.slx, checkpnt.cpp, and callback.dll in C:\Program Files\SLX\DLLs.

Release EC214 of SLX includes the following updates:

A problem with the "Trap Deferred Object Destruction" debugger Trap option has been fixed.  The problem occurred when SLX was attempting to issue a warning when attempted destruction of a puck had to be deferred because the puck's use count was non-zero.  One example of how this could occur was execution of a terminate statement for a puck that was currently in a set.  In this case, inclusion of the puck in a set counts as a use of the puck, and therefore, the puck's destruction must be deferred until the puck's use count goes to zero.  The SLX compiler generated incorrect information that caused message construction to fail catastrophically.

Release EC144 of SLX includes the following updates:

A number of problems with SLXReleaseCheckpoint() have been fixed.  This function is one of several that comprise SLX's rollback feature.  Under certain circumstances, SLXReleaseCheckpoint could loop, and under others, could cause internal run-time errors resulting from attempting to free memory that had already been freed.  This update affects only those users who employ rollback.

Release EC104 of SLX includes the following updates:

Several subtle problems related to a puck's altering its priority have been solved.  These changes will cause (hopefully minor) timing changes to some models.  After upgrading to this release, you should review all results obtained.  If you find differences between new and old runs of the same model, let us know.  We'd like to examine additional examples of the problems we fixed.

Release EC024 of SLX includes the following updates:

A number of SLX compiler error recovery problems have been fixed.  While these problems could arise in a variety of contexts, the "retrieve" statement was the likeliest to cause difficulties.  This fix has no effect on correct programs.  It only improves SLX's handling of incorrectly written statements.

Release OV124 of SLX includes the following updates:

Under certain rare circumstances, SLX's user-callable checkpoint/restore functions could inadvertently release memory that was still in use, resulting in unpredictable behavior.  This problem has been fixed.  In addition, when "exempt" objects are used with checkpoint/restore (virtually always), outstanding checkpoints are now counted as uses the exempt object and show up if "usage" windows are active.  Doing this was necessary to fix problem, and it improves the consistency of the SLX debugger, since it eliminates a category of formerly hidden uses.

Release OV124 of SLX includes the following updates:

An unusual compiler register allocation problem that occurred in certain forms of the retrieve statement has been fixed.  The problem could arise in instances in which the set from which an object to be retrieved was a member of a statically allocated local or global object.

Release OV024 of SLX includes the following additions/updates:

Problems with source code highlighting for syntax errors in large/complex statement/macro expansions have been resolved.

Release CT244 of SLX includes the following additions/updates:

Miscellaneous cleanup, including further improvements to the "retrieve" statement.

Release CT144 of SLX includes the following additions/updates:

Further corrections to the "retrieve" statement have been made.

An obscure problem with "appended" methods has been fixed.  When argument names conflicted with previously defined class member names in method definitions of the form

     procedure classname::methodname(...)

the arguments (incorrectly) did not take precedence over the previously defined member names.

Release CT114 of SLX includes the following additions/updates:

A problem that cropped up in Release EP034 with the "retrieve" statement has been fixed.

A number of debugger display options have been improved.  These in no way affect the execution of programs.

Compiler Diagnostics for errors in usage of common class arguments have been improved.

Handling of network security keys (dongles) has been improved.  Formerly, if you attempted to access a network key, and your network was down, SLX would forget the network IP address of your security key, so on subsequent runs, you'd have to re-enter it or have SLX perform a network key search.  SLX now remembers the IP address.

Release EP034 of SLX includes the following additions/updates:

Support for user-define DLLs has been improved. See slxdll.pdf.

Support has been added for methods. See methods.pdf.

The capabilities of SLX's universal pointers have been expanded. See upointers.doc.

The PDF files mentioned above are located in

    c:\Program Files\Wolverine\SLX\doc

Release EP144 of SLX includes the following additions/updates:

A problem with lowering priorities of pucks currently on the current events chain has been fixed. Previously, under certain circumstances, lowering the priority of the moving puck could cause postponement of the movement of other pucks in certain circumstances.

There are no license date limitations on SLX EP144. Anyone with a valid SLX license may download and install this update.