Changes between Version 37 and Version 38 of ReviewHeuristicLab3.3.0Application
- Timestamp:
- 03/17/10 14:19:53 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ReviewHeuristicLab3.3.0Application
v37 v38 79 79 * 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? 80 80 * 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? 81 * ~~The execution state of an engine (e.g. Execution Time, Log...) is not persisted or restored correctly.~~ 82 * swagner: Fixed storing and loading of an engine's execution time and state in r2933. The log is not stored and loaded at the moment, as it is not persisted in an engine but is only generated and shown in the view. 83 * ~~Dropdown-boxes for crossover and mutation operator selection are empty.~~ 84 * swagner: They are empty as long as no problem has been selected as an algorithm cannot know a priori which crossover and mutation operators are allowed. 81 85 82 86 83 === Priority: LOW ===