I'm trying to make a DXL program that looks the IN-LINKS of a given object.
I will explain myself better: in my system, the links goes from SW to SYS modules, and for the SW modules I need to see some things about the SYS attributes linked to software. But for the SYS modules I need to see diferent things from these attributes.
Besides, due to requirements I need to differentiate the two cases (SW and SYS), so I connot check what I need only with the software OUT-LINKS (in other words, I have to enter systems, look at some things, say that I m in systems and check the IN-LINKS.
I have tried to do something like I would do in SW, but nothing.
In SW, i check the OUT-LINKS with:
for SW_object in SW_module do {
for OUT_link in SW_object -> "*" do {
/* TODO: make the comprobations */
}
}
and this works, but for SYS:
for SYS_object in SYS_module do {
for IN_link in SYS_object <- "*" do {
/* TODO: make the comprobations */
}
}
This code only works if the SW module linked is previously opened. But I can't open this module previously because I don't known which is this module.
Is there a better way or does anyone have any ideas how to do this?
Thanks
)
You are looking for link references (type LinkRef). Check the DXL manual at https://www.ibm.com/support/knowledgecenter/SSYQBZ_9.6.1/com.ibm.doors.requirements.doc/topics/dxl_reference_manual.pdf, chapter "Links"->"Finding Links"->"for each incoming link".
Syntax:
for LinkRef in Object tgtObject<-(string linkModuleName) do {
...
}
Perhaps you should read the complete chapter "Finding Links" to be aware of more specific cases like links from baselines, information about echoed links etc.
Related
I'm trying to open an image from memory with the default image viewer on Linux.
The class is part of the share_plus package. I can't figure out how to define the required UrlLauncherPlatform property.
I want to use it like this:
SharePlusLinuxPlugin(urlLauncher).shareXFiles([XFile.fromData(img)]);
I have googled this class, didn't find any usage examples.
From the source code on Github, it looks like shareXFiles() has not been implemented on Linux. To quote:
Future<ShareResult> shareXFiles(
List<XFile> files, {
String? subject,
String? text,
Rect? sharePositionOrigin,
}) {
throw UnimplementedError(
'shareXFiles() has not been implemented on Linux.',
);
}
The same is true for the shareFiles() method.
Aside from that, there is usually no need to call SharePlusLinuxPlugin directly. The Share class is configured in such a way that it automatically detects the platform that it is running on
Let's say I have my NixOS configuration.nix set up as follows:
{config, pkgs, ...}:
{
services.openssh.enable = true;
}
I now want to have a second file called networking.nix which sets my hostname based on an argument.
{config, pkgs, hostname, ...}:
{
networking.hostName = hostname
}
Is this possible? How can I include the file. I already tried doing it by using imports = [ ./networking.nix { hostname = "helloworld"; } ]; but that didn't work.
Thanks.
A 'NixOS configuration file' is simply a module that doesn't define options, so there is really no distinction. A configuration.nix file is just a module, and typically it does not define any options, so it can be written in the abbreviated form.
Defining options is the normal way for NixOS modules to pass information around, so that's the most idiomatic way to go about.
However, if you really must, for some very special reason, because you're doing very unusual things with NixOS, you can put arbitrary functions in imports. But you shouldn't, because it doesn't work well with the module system's custom error messages and potentially other aspects that rely on knowing where a module is defined. If you do so, do make sure it is an actual function. In your case, that would imply modifying the first line of networking.nix to make it a curried function:
hostname: {config, pkgs, ...}:
Not very pretty in my opinion. Although it is very explicit about what is going on, it deviates from what is to be expected of a NixOS module.
I encountered this problem today and came up with a fairly simple solution recommended in the manual.
foobar.nix
{ lib, withFoo ? "bar", ... }:
# simple error checking to ensure garbage isn't passed in
assert lib.asserts.assertOneOf "withFoo" withFoo [
"bar"
"baz"
# other valid choices ...
];
{
# ...
}
configuration.nix
args#{ ... }:
{
imports = [
# ...
(
import ./foobar.nix (
args
// { withFoo = "baz"; }
)
)
# ...
];
}
This is ideal for 'one off' options in your configurations.
You should be able to use the _module.argsoption [1] to do that. So your configuration.nix would be like:
{config, pkgs, ...}:
{
_module.args.hostname = "ahostname";
services.openssh.enable = true;
}
However where the values are very simple it will probably be much easier to just set them directly, e.g. just define networking.hostname in configuration.nix. This section of the manual re. merging and priorities may be helpful also [2].
Further discussion:
The value of _module.args is indeed applied to all imported configurations (though the value will only be used in modules that directly refer to it, such as the pkgs value, the ... represents all the values that aren't referenced).
For passing arguments to modules it seems a good approach to me, but from your comments perhaps a different approach might be more suitable.
Another solution could be to flip the relationship in the imports: rather than a single common config that passes multiple different arguments instead multiple different configs import the common configuration. E.g.
$cat ./common.nix
{ services.openssh.enable = true; }
$cat ./ahostname.nix
{ imports = [ ./common.nix ]; networking.hostname = "ahostname"; }
The NixOS config in this Reddit comment looks like it uses this approach. There are quite a few other NixOS configurations that people have shared publicly online so you might find some useful ideas there. The points in the answer from Robert Hensing are very useful to bear in mind as well.
However it's hard to say what might be a better solution in your case without knowing a bit more about the context in which you want to use it. You could create a new SO question with some more information on that which might make it easier to see a more appropriate solution.
In compiling languages like C we have a preprocessor that can be used to skip parts of program without compiling them, effectively just excluding them from the source code:
#ifdef SHOULD_RUN_THIS
/* this code not always runs */
#endif
So that if SHOULD_RUN_THIS is not defined, then the code will never be run.
In node.js we don't have a direct equivalent of this, so the first thing I can imagine is
if (config.SHOULD_RUN_THIS) {
/* this code not always runs */
}
However in node there is no way to guarantee that config.SHOULD_RUN_THIS will never change, so if (...) check will be performed each time in vain.
What would be the most performant way to rewrite it? I can think of
a) create a separate function to allow v8-optimizations:
function f(args) {
if (config.SHOULD_RUN_THIS) {
/* this code not always runs */
}
}
// ...
f(args);
b) create a variable to store the function and set it to an empty function when not needed:
var f;
if (config.SHOULD_RUN_THIS) {
f = (args) => {
/* this code not always runs */
}
}
else {
f = function () {} // does nothing
}
// ...
f(args);
c) do not create a separate function, just leave it in place:
if (config.SHOULD_RUN_THIS) {
/* this code not always runs */
}
What is the most performant way? Maybe some other way...
i personally would adopt ...
if (config.SHOULD_RUN_THIS) {
require('/path/for/conditional/module');
}
the module code is only required where needed, otherwise it is not even loaded in memory let alone executed.
the only downside is that it is not readily clear which modules are being required since your require statements are not all positioned at the top of the file.
es6 modularity adopts this dynamic module request approach.
PS use of config like this is great since, you can for example, use an environment variable to determine your code path. Great when spinning up, for example, a bunch of docker containers that you want to behave differently depending on the env vars passed to the docker run statements.
apologies for this insight if you are not a docker fan :) apologies i am waffling now!
if you're looking for a preprocessor for your Javascript, why not use a preprocessor for your Javascript? It's node-compatible and appears to do what you need. You could also look into writing a plugin for Babel or some other JS mangling tool (or v8 itself!)
If you're looking for a way to do this inside the language itself, I'd avoid any optimizations which target a single engine like v8 unless you're sure that's the only place your code will ever run. Otherwise, as has been mentioned, try breaking out conditional code into a separate module so it's only loaded if necessary for it to run.
I'm fairly new to Golang; previously used Python.
I am having difficult time to apply bufio in the object.
type fout struct {
filename string
fo File
bfo Writer
}
func (a *fout) init() {
a.fo,_:=os.Open(a.filename)
a.bfo:=bufio.NewWriter(fo)
}
Basically, I like to create objects; each will have it's filename, and bufio will be used.
Can anyone help me please?
Thank you
Few things in the code sample:
Every use of a name from another package needs to be prefixed with the package name--so fo File has to be fo *os.File.
You normally declare *bufio.Writer and *os.File as pointers (see the bufio and file docs at http://golang.org/pkg)
You want plain =, not :=, for assigning to attributes like a.fo and a.bfo.
Don't throw away errors, particularly if you're used to exceptions, or you'll have impossible-to-debug problems. (For a trivial script for learning you can if err != nil { panic(err) }, but for real use, you almost always want to return them.)
It could also help to review the tour, pick up some tricks/advice from the various talks and blog posts, maybe walk through Go By Example (I admit I haven't persionally used it but sounds like it could be useful when getting started), look at some open-source Go code (projects on Github, the stdlib, anything), and run through the surprisingly readable spec once you're at the level where you want to know how the language really works.
imagine you have a function that creates/copies/moves files. [logic]
For the case that a file that should be copied/created already exists you would like to ask the user to overwrite the file or not.[(G)UI]
What is your approach to implement this if (G)UI and logic are completely separated?
The first thing that comes into my mind would be the MVC-pattern, but this means that I would have to use it whereever I need user interaction.
Any other suggestions?
BTW: How would you implement this in non-OO-languages?
If GUI and logic are really separated, then this question should never arise. The program should, by design, either overwrite or not overwrite based on an option which has a default value. If the GUI is available, the option can be set.
In fact, although the obvious approach is to just have at it and begin copying, you could make a first pass looking for conflicts, and checking that the target device has enough free storage. Then, if there is a problem, terminate by doing nothing, unless there is a GUI in which case you can report the problem and ask whether to proceed anyway.
If you want to have a design in which the GUI can be invoked on a file by file basis, then design the logic around that as a set of n processes each of which copies one file, and has an optional GUI available in the error reporting section. The GUI can then reinvoke the copy-one-file logic.
I can see two ways:
You have two functions, file_exists(...) and copy_file(...). The UI side always calls file_exists first and asks the user whether to copy the file is it already exists.
You have only one function copy_file(bool force, ...), that by default fails if the file exists. So UI side calls the default version of the function, check if it failed and why, if it was because the file already exists, ask the user and try again with force=true.
In a Non OO language I would implement some kind of event queue where the parent (or child, depending on your design) UI polled for events while a 'busy' flag was true. Such an event lets the other side do other work while waiting for a 'they answered' flag to come true. Of course, some timeout in both directions would have to be observed as well as mutual exclusion. Basically, imply the principles of non-blocking I/O or your favorite theory on practical lock free programming here.
There are degrees of separation .. processes can communicate. Depending on your language of choice, you have shared memory segments, semaphores .. or IPC via relational DB with primitive signals. Its hard to be more specific with such a generic question.
See my comment, a little more information is needed so an answer can be crafted that works within your language of choice.
The first thing that comes into my mind would be the MVC-pattern, but this means that I would have to use it wherever I need user interaction.
And this is a bad thing why? Separating GUI and logic is exactly what the MVC pattern is for. Don't be scared of it just because it a has a long name -- as soon as you've separated GUI and logic you have a "view" and a "controller", at least, if not a "model" -- and if your application has state, you've got a model too. You just may not have admitted it to yourself yet.
From what I can see, there are really two problems:
We have an algorithm (logic) in which we would like to defer some operations and decisions to something else (e.g. user via UI).
We would like to avoid tight coupling between the algorithm and that something else.
If we use OO languages, there are several design patters which address these two specific problems.
Template Method pattern can solve #1. It does not solve #2 very well because the typical implementation is via inheritence.
Observer pattern looks promising too.
So really it is choosing and mixing the simplest one for the needs and most suitable for the language.
In practical terms, if talk about C# for example, we can implement Template Method and Observer hybrid like this:
// This will handle extensions to the FileCopy algorithm
abstract class FileCopyExtention
{
public abstract Response WhatToDoWhenFileExists();
}
// the copy function, pure logic
public static void Copy(string source, string destination, FileCopyExtention extension)
{
if (File.Exists(destination))
{
var response = _extension.WhatToDoWhenFileExists();
if (response == overwrite)
// overwrite the file
else
// error
}
}
// This is our user-interactive UI extension
class FileCopyUI : FileCopyExtention
{
public override Response WhatToDoWhenFileExists()
{
// show some UI, return user's response to the caller
}
}
// the program itself
void Main()
{
Copy("/tmp/foo", "/tmp/bar", new FileCopyUI());
}
As a variation of the theme, you can use events, delegates or whatever the language of your choice provides.
In C, this could be a function pointer, in C++ a reference to a class I guess.
What about this approach [pseudo-code]:
UIClass
{
//
// Some code
//
bool fileCopied = false;
do {
try {
fileCopied = CopyFile(fileName);
} catch (FileExists) {
//
// Ask "File exists! Overwrite?" If "No", exit do-loop
//
} catch (FileLocked) {
//
// Ask "File Locked! Repeat?", If "No", exit do-loop
//
} catch (etc...) {
//
// etc.
//
}
} while (!fileCopied);
//
// Some code
//
}
LogicClass
{
//
// Some code
//
bool CopyFile(string fileName)
{
//
// copy file
//
}
//
// Some code
//
}