I've been trying to make a library in Dart and import it in my project. Though for some reason it won't do it.
Here's how it looks:
It says it can't find the library, though the path is correct. I also tried a bunch of other paths:
SmartCanvas.dart
SmartCanvas/SmartCanvas.dart
SmartCanvas
SmartCanvas/SmartCanvas
./SmartCanvas/SmartCanvas.dart
../SmartCanvas/SmartCanvas.dart
./SmartCanvas.dart
../SmartCanvas.dart
./SmartCanvas
../SmartCanvas
Note: The project I'm trying to import this library into is located somewhere totally different on my harddrave (my dropbox folder.)
Anyone knows what I should use as path, or how I can import the library properly?
Thanks!
#import expects a full path or correct relative path to a .dart file that has the #library line.
Here is an example from working code:
https://github.com/johnmccutchan/DartVectorMath/blob/master/test/console_test_harness.dart
At the top you see #import('../lib/vector_math_console.dart');
which is located:
https://github.com/johnmccutchan/DartVectorMath/blob/master/lib/vector_math_console.dart
Chopping off the github url prefix, we are left with:
test/console_test_harness.dart
lib/vector_math_console.dart
The import line uses the correct relative path from test/ into ../lib/ to find vector_math_console.dart (the library).
HTH,
John
Try this for windows
#import('/c:/users/pablo/pablo\'s documents/projects/smartcanvas/smartcanvas.dart');
To import local libraries in dart, I'd recommend using the the path dependency in the pubspec.yaml. This is a much cleaner approach then embedding absolute paths in the dart code.
Read about it here: https://www.dartlang.org/tools/pub/dependencies.html#path-packages
Related
In this issue a recommendation is made to define this setting field:
"typescript.preferences.importModuleSpecifier": "relative"
In order to switch VSCode's auto-import behavior from absolute to relative. This:
import { Logo } from 'src/components/Logo';
becomes:
import { Logo } from '../../components/Logo';
Which is the desired auto-import behavior for us.
However, by changing this setting the auto-import mechanism starts ignoring the tsconfig.ts and instead of importing packages:
import { Button } from '#scope/base-ui';
it also imports files relatively:
import { Button } from '../../../packages/src/base-ui';
Is there a way to enjoy the best of both worlds?
"typescript.preferences.importModuleSpecifier": "shortest"
This will pick an absolute import (including tsconfig-defined paths) if one is available that has fewer path segments than the relative path. If no absolute path is shorter, VS Code will use the relative path.
There's a "project-relative" option now.
Prefers a non-relative import only if the relative import path would leave the package or project directory. Requires using TypeScript 4.2+ in the workspace.
See https://code.visualstudio.com/docs/getstarted/settings
Given a dart package organized as follow
/example
|_______/foo
|________________/pubspec.yaml (and stuff)
|________________/main.dart
|_______/baz
|________________/pubspec.yaml (and stuff)
|________________/main.dart
/lib
|_______/foo
|________________/foo.dart
|_______/baz
|________________/baz.dart
/test
|_______/foo
|________________/foo_test.dart
|_______/baz
|________________/baz_test.dart
but pub.dev gives me
0/10 points: Package has an example
> No example found.
See package layout guidelines on how to add an example.
but I didn't find the documentation very helpful concerning my case
which brings me to the question in the title:
How to correctly organize multiple examples on a dart package?
You can add a README.md file inside your example folder, as flutter_mobx package.
look: https://pub.dev/packages/flutter_mobx/example
I want to use Bourbon with Neat and Bitters for my next project. I have installed all three but I have no idea how to proceed.
Do I use the three folders separately in my project folder or do I need to add the different imports to _bourbon.scss so I have all imports in one main file?
For instance, there are button.scss, clearfix.scss and hide-text.scss in the Bourbon (in addons) and Bitters (in extends) folder, aren't these going to conflict when used together?
All help is appreciated :)
You have to import the files of the plugins (bourbon, neat and bitters) into one main file. Button.scss, clearfix.scss and hide-text.scss won´t conflict.
This is how I organize the project that im currently working on:
- project
|--css
|--base //(Bitters)
|--bourbon
|--neat
|--application.sass
|--application.css
|--js
|--img
|--index.html
In application.sass this is my initial code:
#import 'bourbon/bourbon'
#import 'base/base'
#import 'neat/neat'
So I import Bourbon, Bitters and Neat in my main .sass file so I can easily start using them. You can start changing the default settings in base/_variables.scss
Check this video for more info: http://www.youtube.com/watch?v=8ItNE_DX6Cc
Here's what I'm currently using, which I think gets the job done, but there's got to be a better way:
func isWindows() bool {
return os.PathSeparator == '\\' && os.PathListSeparator == ';'
}
As you can see, in my case all I need to know is how to detect windows but I'd like to know the way to detect any platform/os.
Play:
http://play.golang.org/p/r4lYWDJDxL
Detection at compile time
If you're doing this to have different implementations depending on the OS, it is more useful to
have separate files with the implementation of that feature and add build tags to each
of the files. This is used in many places in the standard library, for example in the os package.
These so-called "Build constraints" or "Build tags" are explained here.
Say you have the constant PATH_SEPARATOR and you want that platform-dependent, you
would make two files, one for Windows and one for the (UNIX) rest:
/project/path_windows.go
/project/path_unix.go
The code of these files would then be:
path_windows.go
// +build windows
package project
const PATH_SEPARATOR = '\\'
path_unix.go
// +build !windows
package project
const PATH_SEPARATOR = '/'
You can now access PATH_SEPARATOR in your code and have it platform dependant.
Detection at runtime
If you want to determine the operating system at runtime, use the runtime.GOOS
variable:
if runtime.GOOS == "windows" {
fmt.Println("Hello from Windows")
}
While this is compiled into the runtime and therefore ignores the environment,
you can nevertheless be relatively certain that the value is correct.
The reason for this is that every platform that is worth distinguishing needs
rebuilding due to different executable formats and thus has a new GOOS value.
Have you looked at the runtime package? It has a GOOS const: http://golang.org/pkg/runtime/#pkg-constants
It's 2022 and the correct answer for go 1.18+ is:
At runtime you want:
if runtime.GOOS == "windows" {
// windows specific code here...
}
If you need to determine the filesystem path separator character
Use: os.PathSeparator
Examples:
c:\program files
/usr/local/bin
If you need the Path List separator as used by the PATH environment variable
Use: os.PathListSeparator
Examples:
/usr/local/bin:/usr/local:
"C:\windows";"c:\windows\system32";
Since this is an older question and answer I have found another solution.
You could simply use the constants defined in the os package. This const returns a rune so you would need to use string conversion also.
string(os.PathSeparator)
string(os.PathListSeparator)
Example: https://play.golang.org/p/g6jnF7W5_pJ
I just stumbled on this looking for something else and noticed the age of this post so I'll add a more updated addition. If you're just trying to handle the correct filepath I would use filepath.Join(). Its takes all of the guesswork out of os issues. If there is more you need, other than just filepath, using the runtime constants (runtime.GOOS & runtime.GOARCH) are the way to go: playground example
I tested in Go 1.17.1 which really worked for me.
package main
import (
"fmt"
"runtime"
)
func main(){
fmt.Println(runtime.GOOS)
}
Output:
darwin
With regards to detecting the platform, you can use Distribution Detector project to detect the Linux distribution being run.
The first answer from #nemo is the most apropiate, i just wanted to point out that if you are currently a user of gopls language server the build tags may not work as intended.
There's no solution or workaround up to now, the most you can do is change your editor's lsp configs (vscode, neovim, emacs, etc) to select a build tag in order to being able to edit the files with that tag without errors.
Editing files with another tag will not work, and trying to select multiple tags fails as well.
This is the current progress of the issue github#go/x/tools/gopls
I'm just trying to begin develop a game in Marmalade (6.3). But when I have made my new sources (.cpp, and .h) and added them to the mkb, and then trying to run my program, then I got an error which says that Unable to find file.cpp in path(s). It's for all of my files except the files (game.h, game.cpp, main.cpp) which were made by Marmalade when I have chosen the new 2D game project. Should I add my .cpp and .h files to anywhere else?
Thanks
It is difficult to give a categorical answer without more info. However my guess is that you've copied and pasted from an example and not understood about the syntax of the files section. Basically:
files
{
(foo)
humbug.cpp
)
The "(foo)" might look very innocent, but it actually says that humbug.cpp is actually in directory foo - relative to the mkb file. It is common practice to actually use "(source)" and put all the source files in a directory of that name - making the source layout a bit neater.
Naturally if you have (source) and don't put the files actually in directory source, they won't be found. My guess is that is what you are seeing.
Just to clarify previous answer, The format of files directive is like this -
files
{
(<Path relative to MKB>,<Alternate Path>)
["Name of the parent Group in VS/XCode project","Name of the subparent group"]
fileName.cpp
fileName.h
}
for example I have two files SoundManager.h and SoundManager.cpp in System folder of Source, while MainMenu.h and MainMenu.cpp in Source/UI. Now the files directive would be -
files
{
(Source/System)
["Source","System"] #This part is not required, it's just to arrange your files in IDE project
SoundManager.h
SoundManager.cpp
(Source/UI)
("Source","UI")
MainMenu.h
ManinMenu.cpp
}