Probably a basic mistake, but the cause is eluding me. I am trying to import a package, but I get an error saying it cannot be found or imported.
First I set the current directory to the parent directory of the package, and this does not work.
Second, the docs say that the parent folder of the package must be added to the matlab path. I tried this, and still no luck.
It is not due to using plot as the package name as I get the same error when trying to import analysis.
What I can do is to import using: import plot.* or import analyse.* and then go on to use the functions in the packages, but I want to use the namespaces (i.e. not use .*).
Edit
I'm having this problem on both versions I have installed: 2015b and 2016a.
The answer is that, somewhat counterintuitively, you don't need to call import at all. The docs state that
The parent of the top-level package folder must be on the MATLAB path.
Which is what your addpath(pwd) does and then state that (emphasis is mine):
All references to packages, functions, and classes in the package must
use the package name prefix, unless you import the package.
Meaning at this stage you should be able to call
analyse.testFunc
If you were to import analyse.testFunc you would then be able to call testFunc without prefacing it with the namespace but since you want to retain the namespace the answer is to not call import at all.
Related
I have a set of Swift Packages that I'm writing (ex: CUIExpandableButton), that I'd like to roll up into another Swift Package called CrystalUI. The overall goal is to write a set of packages that get bundled into a single package. However, I want to make it so people can just have one import
import CrystalUI
instead of a series of import statements
import CrystalUI
import CUIExpandableButton
import PreviewKit
...
Is it possible to re-expose an existing library as part of the parent library?
Looks like #_exported Is what I was looking for. Found this article that explains it. It's an unsupported method but it's also used in Alamofire so I think it's safe.
I'm having trouble using the Backendless plugin for Flutter.
I include
import 'package:backendless_sdk/backendless_sdk.dart';
(as per the instructions) and can then use e.g. Backendless.UserService. But if I try to generate a user to register, e.g.:
var user = new BackendlessUser();
user.setEmail("info#example.org");
user.setPassword("password");
Backendless.UserService.register(user);
I get an error Undefined class 'BackendlessUser' on the first line. This class is defined in src/modules/user_service.dat, which is exported by src/modules/modules.dartlike this:
library modules;
export 'cache.dart';
...
export 'user_service.dart';
which in turn is imported by backendless_sdk.dart like this:
import 'package:backendless_sdk/src/modules/modules.dart';
I would have thought that it would get imported indirectly by the import of backendless_sdk.dart, but apparently not. When I import it explicitly (with the same import statement, but now in my own code and not just indirectly in backendless_sdk.dart), I get a warning Don't import implementation files from another package. But it's not an implementation file; it's exported as part of the public API (at least that's what I understand the export statement to mean).
The Dart tutorial for creating packages suggests to place the export statements directly under lib, not in lib/src, so I'm wondering whether this is an error in the structure of the plugin, or whether I'm doing something wrong.
I'd be grateful both for a solution to this particular problem and also for pointers to how I can better understand packages, libraries, imports and exports in dart; unfortunately I don't find the language specification particularly helpful in this regard.
(The error and the warning are the same whether I use flutter analyze or IntelliJ IDEA.)
The problem has been fixed in the 0.0.3 version of the plugin. Please update the backendless_sdk version in your pubspec.yaml.
You can include the only one import now:
import 'package:backendless_sdk/backendless_sdk.dart';
Please also note, that there are some changes in the syntax. So for your example you should use:
var user = new BackendlessUser()
..email = "info#example.org"
..password = "password";
Backendless.userService.register(user);
Thanks for using Flutter SDK and pointing out this issue.
It's indeed the problem in the structure of the plugin. The Backendless team is aware of it and this problem will be fixed in the next release of the plugin.
For now you can import explicitly and suppress the warning.
I came out to scala programmin from Java so it's not clear to me how we should use relative imports in Scala and what is the exact name lookup rules? Suppose I have the following:
pack.age
|
|----MyClass.scala
com.age
|
|---AnotherClass.scala
I need to import MyClass.scala into AnotherClass.scala. Since Scala supports only relative imports I wrote the following:
import _root_.pack.age.MyClass
and it worked fine. But when I tried to delete _root_ from there, there was no compile time error either.
import pack.age.MyClass
works fine as well.
So, what is the package name lookup rules in Scala?
I believe there is an order of operations here. If you had package.age.MyClass within com.age (ie. com.age.package.age.MyClass), as well as package.age.MyClass, the former would be picked up. If you wanted the latter, you would need to use the root syntax.
As there is only one place this class can be picked up from (in root), that is the package picked up.
All imports are relative, so sometimes collisions can appear. For example, if you have package com.org.project.scala then next import scala._ looks up for system package too. _root_ is implicit top package that can be utilised for simulation of absolute path.
I want to clean my code structure and put class/object files in another directories in my gatling project.
If i put all simulation class and utils class in the same directory and same package i do not need an import statement and everything works fine.
Let's say my structure is as follow :
/user-files
----/simulations
--------MySimulation.scala
----/utils
--------Router.scala
I have tried several import or naming configuration to be able to use Router in my Simulation.
Follow package naming as directories structure
Put simulations and utils class in the same package
I have also tried different style of import
//using package
import packagename.Router
//another try
import packagename.Router._
//without package name
import Router._
My attempt to search a solution on scala docs or stack overflow didn't helped me.
This is the error given after executing gatling.bat
not found: value Router
You can't do that this way: there's one single source folder, which is by default /user-files/simulations.
If you want to use folders/packages (which is a good thing), you can have a structure such as:
/user-files
----/simulations
--------MySimulation.scala
--------/utils
------------Router.scala
Then, in Scala, packages and folder hierarchy are not related, BUT it's a good practice to use the same convention as in Java.
So, you would have:
package utils
object Router
then in MySimulation:
import utils.Router
I'd like to import package com.example.abc from com.example.iop in similar manner to bash expression ../abc.
Is this possible in Scala? I've read couple of articles but they say nothing about my case.
Update: I've discovered code suitable for simple uses (I've seen it in some project while ago):
package com.example
package com.example.abc
import iop
Your updated package structure has a hint of the solution, but isn't quite right. You can live in multiple packages, including a broad parent package defined by the first package statement – subsequent statements refine the tree.
package com.foo // we're in: com.foo
package bar // we're also in: com.foo.bar
package wibble // we're also in: com.foo.bar.wibble
import frobble._ // this could be com.foo.frobble or com.foo.bar.frobble or com.foo.bar.wibble.frobble
Obviously, things can get confusing if you have multiple packages with the same name, but the compiler asks you politely to sort that out.
That is simply not possible -- same as in Java.