Free cookie consent management tool by TermsFeed Policy Generator

Changes between Version 300 and Version 301 of ReviewHeuristicLab3.3.0Application


Ignore:
Timestamp:
05/07/10 09:06:12 (14 years ago)
Author:
gkronber
Comment:

Removed obsolete issues

Legend:

Unmodified
Added
Removed
Modified
  • ReviewHeuristicLab3.3.0Application

    v300 v301  
    8686
    8787=== Priority: HIGH ===
    88  * The plugin management GUI is not finished.
    89  * Closing the Optimizer while the global scope view is shown (user defined algorithm) and expanded throws `ArgumentException` in `HeuristicLab.Core.Views.ScopeView.Dispose()`.
    90    * swagner: Could not reproduce this exception in r3502.
    91  * Exception in `BestQualityMemorizer` because the actual name of the quality parameter is not updated. (To reproduce open a new user defined GA and then load a problem that changes the actual name of the quality parameter and then start the engine.)
    92    * swagner: Setting parameters automatically does not work in user defined algorithms. In a user defined algorithm all parameter settings (values, actual names, etc.) have to be set manually by the user.
    9388 * Read-only parameters would be nice (similar to the data items of `HeuristicLab.Data`)
    9489
    9590=== Priority: MEDIUM ===
    96  * Breakpoints should be visually emphasized.
    97    * swagner: At the moment, breakpoints are marked red in the `OperatorTreeView` and will be visually emphasized in the `OperatorGraph` visualization in the next version. Where else should they be emphasized?
    9891 * It seems strange now that operators have the property `Breakpoint`. It is more usual to set breakpoints on invocations/calls of operators. Also isn't the engine responsible for breakpoints?
    9992   * swagner: As in HL 3.2 the `Breakpoint` property is implemented in operators and can be changed in the GUI of an `OperatorGraph`. Additionally, I decided to add a checkbox to each operator in order to be able to mark breakpoints there as well (this was not possible in HL 3.2). If an operator is marked as breakpoint, an engine stops its execution after this operator has been processed. I agree that it would be more intuitive to store it in some other location, which operators are currently breakpoints. However, I do not immediately know where. Any suggestions?