I want to program a custom version of the predicate cumulative/2 (or at least a similar predicate in terms of functionality). I looked for the sources of CLP(FD) library and I was now wondering whether it could be a good idea to modify that library (only by adding new things) in order to incorporate the new my_cumulative/2 but with the library's private predicates available to do so.
I want to add the following features:
I want the task planner to be preemptive (meaning that planned tasks can be "splitted" in several time intervals).
Apart from being cumulative, I want it to be multi-resource (meaning that instead of [limit(3)] I could have, for instance, [limit(2),limit(3),limit(1)]; where each limit corresponds to a different resource)
I want to add priorities to each task, so that higher priority tasks have more "decision power" and can't be left unscheduled by lower ones.
I want the solution "not-schedulable" to be a possible solution for a task.
This idea came to me when I was trying to add a custom operator /\ to calculate intersections (like-wise \/ denotes unions) and I saw that there actually is one already defined in clpfd.pl but not made part of the module.
For a start, you should try to express your constraints in terms of exported library predicates. If you need to use a private predicate of the library, you can call it with its module prefix (like clpfd:some_predicate(...)). Private predicates may change without notice, but they can be useful if you want to experiment with some things, and you can ask for more public predicates etc. on the SWI mailing list when you have found out which ones are useful to you. To calculate intersections with public predicates, you can use for example: X in 0..5 #/\ X in 0..2, fd_dom(X, Dom). You can use (#\/) for unions.
You can define a new module and within it use the reexport/1 and reexport/2 directives to reexport the full CLP(FD) library or just part of it. In this new module, you can add new stuff or override the existing one if necessary.
Related
In the change and swap move selector, I would like to only consider moves that involve entities in conflict as they are more likely to improve the heuristic score.
How should this be done? What classes and interfaces do I have to reuse/extend? I looked at ScoreDirector and PhaseLifecycleListener.
A MoveFilter might do that (if it's not in phase or solver cached as it changes ever step). See the course scheduling example and docs for how to use a filter.
I wouldn't recommend it though, as you still want to move non-conflicting entities at times. You might just want to focus more on those conflicting lectures. So I would keep a vanilla move selector in the mix.
The move filter isn't perfect either - the Guided Local Search feature (not yet available) is a better way to deal with this.
However, given the other question about the model and similar cases I 've seen, I 'd say moves are not your problem. A better model will make all these kinds of move tweaking obsolete.
Lately I need to do an impact analysis on changing a DB column definition of a widely used table (like PRODUCT, USER, etc). I find it is a very time consuming, boring and difficult task. I would like to ask if there is any known methodology to do so?
The question also apply to changes on application, file system, search engine, etc. At first, I thought this kind of functional relationship should be pre-documented or some how keep tracked, but then I realize that everything can have changes, it would be impossible to do so.
I don't even know what should be tagged to this question, please help.
Sorry for my poor English.
Sure. One can technically at least know what code touches the DB column (reads or writes it), by determining program slices.
Methodology: Find all SQL code elements in your sources. Determine which ones touch the column in question. (Careful: SELECT ALL may touch your column, so you need to know the schema). Determine which variables read or write that column. Follow those variables wherever they go, and determine the code and variables they affect; follow all those variables too. (This amounts to computing a forward slice). Likewise, find the sources of the variables used to fill the column; follow them back to their code and sources, and follow those variables too. (This amounts to computing a backward slice).
All the elements of the slice are potentially affecting/affected by a change. There may be conditions in the slice-selected code that are clearly outside the conditions expected by your new use case, and you can eliminate that code from consideration. Everything else in the slices you may have inspect/modify to make your change.
Now, your change may affect some other code (e.g., a new place to use the DB column, or combine the value from the DB column with some other value). You'll want to inspect up and downstream slices on the code you change too.
You can apply this process for any change you might make to the code base, not just DB columns.
Manually this is not easy to do in a big code base, and it certainly isn't quick. There is some automation to do for C and C++ code, but not much for other languages.
You can get a bad approximation by running test cases that involve you desired variable or action, and inspecting the test coverage. (Your approximation gets better if you run test cases you are sure does NOT cover your desired variable or action, and eliminating all the code it covers).
Eventually this task cannot be automated or reduced to an algorithm, otherwise there would be a tool to preview refactored changes. The better you wrote code in the beginning, the easier the task.
Let me explain how to reach the answer: isolation is the key. Mapping everything to object properties can help you automate your review.
I can give you an example. If you can manage to map your specific case to the below, it will save your life.
The OR/M change pattern
Like Hibernate or Entity Framework...
A change to a database column may be simply previewed by analysing what code uses a certain object's property. Since all DB columns are mapped to object properties, and assuming no code uses pure SQL, you are good to go for your estimations
This is a very simple pattern for change management.
In order to reduce a file system/network or data file issue to the above pattern you need other software patterns implemented. I mean, if you can reduce a complex scenario to a change in your objects' properties, you can leverage your IDE to detect the changes for you, including code that needs a slight modification to compile or needs to be rewritten at all.
If you want to manage a change in a remote service when you initially write your software, wrap that service in an interface. So you will only have to modify its implementation
If you want to manage a possible change in a data file format (e.g. length of field change in positional format, column reordering), write a service that maps that file to object (like using BeanIO parser)
If you want to manage a possible change in file system paths, design your application to use more runtime variables
If you want to manage a possible change in cryptography algorithms, wrap them in services (e.g. HashService, CryptoService, SignService)
If you do the above, your manual requirements review will be easier. Because the overall task is manual, but can be aided with automated tools. You can try to change the name of a class's property and see its side effects in the compiler
Worst case
Obviously if you need to change the name, type and length of a specific column in a database in a software with plain SQL hardcoded and shattered in multiple places around the code, and worse many tables present similar column namings, plus without project documentation (did I write worst case, right?) of a total of 10000+ classes, you have no other way than manually exploring your project, using find tools but not relying on them.
And if you don't have a test plan, which is the document from which you can hope to originate a software test suite, it will be time to make one.
Just adding my 2 cents. I'm assuming you're working in a production environment so there's got to be some form of unit tests, integration tests and system tests already written.
If yes, then a good way to validate your changes is to run all these tests again and create any new tests which might be necessary.
And to state the obvious, do not integrate your code changes into the main production code base without running these tests.
Yet again changes which worked fine in a test environment may not work in a production environment.
Have some form of source code configuration management system like Subversion, GitHub, CVS etc.
This enables you to roll back your changes
I have a project in which I am organizing my variables/tags using categories like "PartA", "PartB", "Data", "HMI", and of course the requisite "Debug".
So a few examples of random tags would be:
Debug.ReadWriteTimer
HMI.ReportViewerMode
Data.IndexResult
Data.ActiveDirectory
PartA.InspectionResult
But I have several variables that I am using across the program as logistical devices, such as counters, indices, and (non-debug) timers, that don't really fit in the the few categories that I listed above.
I've considered the following but none of those seem to fit either:
Global.tagname
Program.tagname
Devices.tagname
What is a clear and logical naming convention for program-level "tools" like these that would be instantly recognized by someone looking over the tag database for the first time?
(Context for the curious: this particular project is created using a machine vision software called Cognex Designer, which utilizes the C# language in an interface that is the illegitimate child of RSLogix and LabVIEW.)
misc, shortcut of miscellaneous, is/was often used to categorize items that couldn't be put in other categories.
This is if you must use a category, otherwise the lack of category perfectly describes the miscellaneous property of a variable.
I've decided to use "App", short for Application, as the category for these items. I believe it's clearer than "Program" and not easily confused with scope, like "Global", and the abbreviation will help alleviate confusion with .NET's Application object.
In a program that I'm responsible for, we want to start keeping track of milestones. These milestones are quite simple and consist of a unique identifier, the project they're assigned to, a description, and a date that they should be accomplished by (or not, if there's no concrete due date).
We use a slightly modified Model-View-Presenter architecture, and currently I'm passing this list around through the presenters, but it seems fairly clunky, so I was wondering:
What's the best way to make this list available to all the presenters/views that need it?
We're using VB.NET 3.5, and I was toying with the idea of making this a shared property of the main presenter, but it does seem like that adds some unnecessary coupling.
I agree with Oded about keeping it as you have it, but if you insist on having it the way you describe, you could consider implementing it (the collection) as a singleton.
Have a read through this article
I am using HP Exstream (formerly Dialogue from Exstream Software) version 5.0.x. It has a feature to define and save boolean expressions as "Rules".
It has been about 6 years since I used this, but does anybody know if you can define a rule in terms of another rule? There is a "VB-like" language in a popup window, so you are not forced to use the and/or, variable-relational expression form, but I don't have documentation handy. :-(
I would like to define a rule, "NotFoo", in terms of "Foo", instead of repeating the inverse of the whole thing. (Yes, that would be retarded, but that's probably what I will be forced to do, as in other examples of what I am maintaining.) Actually, nested rules would have many uses, if I can figure out how to do it.
I later found that what one needs to do in this case is create user defined "functions", which can reference each other (so long as you avoid indirect recursion). Then, use the functions to define the "rules" (and, don't even bother with "library" rules instead of "inline" rules, most of the time).
I'm late to the question but since you had to answer yourself there is a better way to handle it.
The issue with using functions and testing the result is that there's a good chance that you're going to be adding unnecessary processing because the engine will run through the function every time it's called. Not a big issue with a simple function but it can easily become a problem if the function is complex, especially if it's called in several places.
Depending on the timing of the function (you didn't say whether it was a run level, customer level, or specific to particular documents), it's often better to have the function set a User Boolean variable to store the result then in your library rules you can just check the value of the variable without having to run through the function every time.