I am trying to use the Programming Language Foundation with Agda plfa library, however the import does not appear to be working properly.
I have cloned the repository and added the repository path to: ~/.agda/libraries and plfa to ~/.agda/defaults.
When I create a test.agda file and check a single line
module plfa.part1.Naturals where
I get an import error:
You tried to load /Users/johngfisher/Desktop/agda_test/nats.agda
which defines the module plfa.part1.Naturals. However, according to
the include path this module should be defined in
/Users/johngfisher/agda_env/libraries/plfa/src/plfa/part1/Naturals.lagda.md
The file is present in the location the import is coming from so I am unsure of why Agda is unable to find it. Any help would be appreciated.
module plfa.part1.Naturals where
defines a module named plfa.part1.Naturals
Did you mean to type
module test where
open import plfa.part1.Naturals
instead?
Related
Basically I have a lot of widgets and services and stuff, like most people do, that I need to access throughout the app. I was wondering if have a single file with an export of every single file and then just simply importing that one file in every page/file i need to access something rather than just importing specific files that the page needs, will it slow down the app or cause any issues or increase file size, etc... or will it behave the same?
Example
login_page.dart
import '1.dart'
import '2.dart'
home_page.dart
import '2.dart'
import '3.dart'
import '9.dart'
import '10.dart'
settings_page.dart
import '1.dart'
import '2.dart'
import '9.dart'
import '10.dart'
or...
all_imports.dart:
export '1.dart'
export '2.dart'
export '3.dart'
... (up until)
export '10.dart'
in every dart file:
import 'all_imports.dart'
Using 'all_imports.dart' may cause unneeded dependencies but dart knows how to handle dependencies that called but not used.
Same implementation of 'all_imports.dart' is used by flutter team on 'material.dart'
You may wish to just make simple design but when you import 'material.dart' it brings everything to the table ('about.dart', 'app.dart', 'banner.dart') and many others.
I would advise you structure your application using 'all_import.dart' pattern
actually, it dosent make a difference, lets imagine this case
in login_page.dart
import '1.dart'
import '2.dart'
here you are being explicit about the dependencies of this module/file/widget, which means it only uses what it needs. which is better for maintenance and redablity of the modules dependanices.
the other case where you have all of your imports in one file
import 'all_imports.dart'
lets see what happens here:
Dart executes the file all_imports.dart
that file is importing every module that you have listed in that file
so the import calls happend again
which means that wont affect your software's performance if you dont have an all_imports.dart file.
actulally i find that this method(the all_imports.dart) will affect your program in a bad way if any.
why? lets say we have a module A that depends on both module B and module C , you would import them this way
moduleA.dart
import 'moduleB'
import 'moduleC'
the advantages is that the module is now explicit in its dependencies and anyone who looks at this module/file in the future will know what they are.
however
the other method where you have all of your imports in a single all_imports.dart file, will cause unneeded dependencies to be loaded for a certain module
lets have the same example above, module A depends on moduleB and moduleC and you listed them in the all_imports.dart file, it will look like this
export `moduleA'
export 'moduleB'
/// some other modules that you are exporting
and in the moduleA.dart file you import it this way
import 'all_imports.dart`
now
the module A has successfully imported moduleB and moduleC which it needs. BUT, now it has all the other dependancies that it dose not need loaded for it although it only needs moduleA and moduleB.
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.
Many of the samples I have seen for angular2 have the following import statement:
import {bind} from 'angular2/di';
I am working in VS Code (with TypeScript) and it complains about not being able to find the angular2/di module.
However I do see a bind function defined in angular2/angular2.d.ts. If I change the import statement to the following, then the error goes away.
import {bind} from 'angular2/angular2';
Is the question in the title off-base and I am making some erroneous assumption?
If not, why do many samples reference one module to import the bind function from, yet I seem to be able to get it from a different module?
Most likely because you looked at versions from older alphas. Look at the angular2.ts file. Everything is exported from it. Also note that the d.ts is going to contain everything to resolve types in your IDE and at compilation time. What import does is actually importing the .js files.
Create a sample web application using the Web UI (web_ui) library, e.g., mylib
open mylib.dart, make it a library:
library mylib;
import 'dart:html';
import 'package:web_ui/web_ui.dart';
part 'xclickcounter.dart';
...
open xclickcounter.dart, remove imports and insert:
part of mylib;
web/out/mylib.dart and web/out/xclickcounter.dart get messed up:
The included part ''xclickcounter.dart'' must have a part-of directive
Classes can only mixin other classes
Mixin can only be applied to class
... more errors follow
What am I doing wrong? Please help :(
Edit: if I don't edit generated sample code, wdc will generate code that falls into separate libraries:
web/out/xclickcounter.dart => x_click_counter
web/out/mylib.dart => mylib_html
Does it mean that if we use web_ui we should not create our own libraries and wdc will do this for us automatically?
Update: if I don't use any library name, similar to what generated sample code does, and only rely on the library names generated by xdc in web/out/... files, I still run into trouble when importing my two components into a 3rd file. Dart Editor will produce the following warning:
The imported libraries 'compa.dart' and 'compb.dart'
should not have the same name
The workaround is to name your libraries based on what xdc produces in web/out/... files, that is:
compa.dart => x-comp-a
compb.dart => x-comp-b
After explicitly placing components into libraries like these the Dart Editor warning disappears.
I managed to add a relative path dependency in my app
name: myapp
description: A sample app
dependencies:
mylib:
path: ../mylib
and then import it in my source code
import 'package:mylib/mylib.dart';
However, the name 'mylib' is taken from the library package pubspec and if I want to change it (for example 'mynewlib'), I have to change the name everywhere (pubspec AND dart source code)
It also prevent having 2 packages with the same name (yes I know, weird, but I don't control what people put in pub.dartlang.org). What I'd like to do is something like
name: myapp
description: A sample app
dependencies:
mylib:
path: ../mylib
name: mynewlib
and have in source code
import 'package:mynewlib/mylib.dart';
However I cannot find the proper syntax and whether that's possible or not. (Sample code ready for testing is here: https://github.com/alextekartik/dart-test/tree/master/lib_test). To note that here I'm not talking about library name but package name (and naming the package mylib can be confusing)
There is no way to define another name for a package itself (as far as I know - if there is, I'd be interested too).
However, as a workaround, you could rewrap it. For example, let's assume you have two "mylib" packages.
Create a new library application "mylib1". There, you import the first "mylib" and reexport it using export. Create another library application "mylib2" for the other "mylib". Then you have different package names to use in the same application.
Yes, it is kinda awkward, but as long as there is no better way...
You can resolve name conflicts at import with:
import 'package:mylib/mylib.dart' as Foo;
This will create a top level name to access the library API:
Foo.bar();