I have written some code and I want to provide it in a package, but I want to also expose it to package consumers as a worker. For this purpose I have created a wrapper class, that runs an isolate internally and using the send command and listeners communicate with the Isolate to provide the functionality.
The problem arises when I want to use this wrapper class from bin or web directory: the Uri provided is interpolated from the directory of the running/main Isolate instead of from the package root. For bin it is packagename|bin/ and for web it is packagename|web.
I would like to export this class to the consumers so they can chose an easier approach than to construct their own Isolate, but I am not sure how to specify the main file that will be used in spawnUri.
Is there a way to specify the file so it will always be resolved to the correct file regardless of where the main Isolate is run from.
Structure:
// Exports the next file so the class in it will be package visible
packageroot -> lib/package_exports_code_that_spawns_isolate.dart
// This file should contain URI that always resolve to the next file
packageroot -> lib/code_that_spawns_isolate.dart
// The main worker/Isolate file
packageroot -> lib/src/worker/worker.dart
Thanks.
To refer to a library in your package, you should use a package: URI.
Something like:
var workerUri = Uri.parse("package:myPackage/src/worker/worker.dart");
var isolate = await Isolate.spawnUri(workerUri,...);
It's not perfect because it requires you to hard-wire your package name into the code, but I believe it's the best option currently available.
The Isolate.spawnUri function doesn't (and can't) resolve a relative URI reference wrt. the source file that called it - nothing in the Dart libraries depends on where it's called from, that's simply too fragile - so a relative URI isn't going to work. The only absolute URI referencing your worker is a package: URI, so that's what you have to use.
Related
I have a service with in I have several modules and in the main file I am importing most of my modules like below.
from base_client import BaseClient
import request_dispatcher as rd
import utils as util
In one of the functions in main I am calling the dask client submit. When I try to get the result back from future object it give me modulenotfound error as below
****ModuleNotFoundError: No module named 'base_client'****
This is how I define my client and call the function
def mytask(url, dest):
.....
client = Client(<scheduler ip>)
f_obj = client.submit(mytask, data_url, destination)
How exactly can I make these modules available to scheduler and workers?
When you do submit, Dask wraps up your task and sends it to the worker(s). As part of this package, any variables that are required by the task are serialised and sent too. In the case of functions defined inline, this includes the whole function, but in the case of functions in a module, it is only the module and function names. This is done to same CPU and bandwidth (imagine trying to send all the source of all of the modules you happen to have imported).
On the worker side, the task is unwrappd, and for the function, this means importing the module, import base_client. This follows the normal python logic of looking in the locations defined by sys.path. If the file defining the module isn't there, you get the error above.
To solve, copy the file to a place that the worker can see it. You can do this with upload_file on a temporary basis (which uses a temporary directory), but you would be better installing the module using usual pip or conda methods. Importing from the "current directory" is likely to fail even with a local cluster.
To get more information, you would need to post a complete example, which shows the problem. In practice, functions using imports from modules are used all the time with submit without problems.
In my dart project projectxyz, I have a dart class declared in in myclass.dart. In main.dart, Android Studio gives two ways, both work, but I did not understand what are the pros and cons of each method:
import 'myclass.dart';
or:
import 'package:projectxyz/myclass.dart';
What is the difference in these two approaches?
That depends on how the main file itself is invoked (and where it's located).
I'll assume the main.dart library is inside the lib/ directory, because otherwise you wouldn't have the two options for importing myclass.dart.
If you invoke the main file with a file: URI, then the relative import of myclass.dart will also be imported with a file: URI. Since Dart uses the import URI to distinguish different libraries, if someone else imports myclass.dart using a package: URI, then it will be treated as two different libraries introducing different classes with the same name.
It used to be that running dart lib/main.dart would treat that as a file: URI. The Dart parser has gotten smarter about that, and now it recognizes that an entry point library in a lib/ directory should have been a package: URI, and replaces the entry point URI with package:projectxyz/main.dart.
After that, it makes no difference whether you use myclass.dart or package:projectxyz/myclass.dart.
Really, there is no difference between the two. Saying import 'myclass.dart' is high-level sugar for import 'package:projectxyz/myclass.dart';.
On the other hand, import 'myclass.dart' is easier to read and understand, and generally looks better. It also decreases confusion as to where exactly your code is being imported from, as anybody who reads this statement knows to look for the file elsewhere in your project. Because of this, you should try to use this form wherever possible.
I want to get access to external YAML file which I specify through command-line argument:
java -jar target/app-thorntail.jar -s./test.yaml
This file I need to use to get my custom properties tree by SnakeYaml.
You can use #Inject #ConfigurationValue for your custom properties, and you can #Inject a ConfigView to read the entire configuration tree. I believe that should be enough for your usecase. This approach will also provide correct values in case multiple configuration files are used.
I'm not sure if you can get access to the file itself, except maybe provide a custom main method and parse the command-line arguments yourself.
In my code, there is a place where I need to take different actions based on the input class type.
So I write two lines to check an input object's class type.
debugPrint("Let me know the next action: $action");
debugPrint((action is LoadPomodorosAction).toString());
And the output is
I/flutter (24128): Let me know the next action: Instance of 'LoadPomodorosAction'
I/flutter (24128): false
What does this mean?
The object 'action' is "Instance of 'LoadPomodorosAction'" and at the same time its class type is not LoadPomodorosAction .
how do I adjust my code so that I can know the class type of action?
I was suspecting that maybe there is something wrong with runtimetype. But how do I get to know the runtimetype?
I've tried replicating your issue and I'm not able to reproduce it. But to explain your inquiry, here is a complete details about the difference between the relative path and absolute path when used in imports as discussed in this SO post:
package imports
'package:... imports work from everywhere to import files from
lib/*.
relative imports
Relative imports are always relative to the importing file. If
lib/model/test.dart imports 'example.dart', it imports
lib/model/example.dart.
If you want to import test/model_tests/fixture.dart from any file
within test/*, you can only use relative imports because package
imports always assume lib/.
This also applies for all other non-lib/ top-level directories like
drive_test/, example/, tool/, ...
lib/main.dart
There is currently a known issue with entry-point files in lib/*
like lib/main.dart in Flutter.
https://github.com/dart-lang/sdk/issues/33076
Dart always assumed entry-point files to be in other top-level
directories then lib/ (like bin/, web/, tool/, example/,
...). Flutter broke this assumption. Therefore you currently must not
use relative imports in entry-point files inside lib/
See also
How to reference another file in Dart?
Previously, this bug was posted in GitHub as an issue between relative and absolute path. It seems that this was resolved per this GitHub post.
I am trying to display some Images which are in my local folder. I am getting the image name from a server through JSON. Based on that, I am constructing the Image path dynamically. However, the final image path will be changed by SC build tools. I know that we can use sc_static() in css or view's specifications to map it to the final path. How can I achieve that mapping (to final path from local path) while programmatically constructing my url.
Any ideas, suggestions and thoughts?
sc_static is not a javascript function, but rather a convention used to tell Abbot (Sproutcore's build tool, written in ruby) to replace it at runtime with a path pointing to the resource passed as first argument to sc_static.
Note that this substitution is done by Abbot when the page is refreshed (in dev mode) or when the app is built (in prod mode). It is not a js function at all (use Chrome inspector to see it by yourself).
If you want to use sc_static in JS you can define all resource references as such:
YourApp.loadingIcon=sc_static('loading.png');
YourApp.greenIcon=sc_static('green.png');
and then reference the
YourApp.loadingIcon , YourApp.greenIcon
variables in your code.
Finally I found the answer with the help of my friends. sc_static is not javascript function it is a function targeted for build tools(Abbot) of Sproutcore to replace the actual production path after build. Hence we can not use sc_static in programming.
If we want similar function we have develop our own.