I'm taking my first steps with bii. I can complete the get started tutorial with no problems. However, when I manually create a new project on github, pull it, add a main file with gtest and gmock includes, run the commend bii init within the project folder, then type bii find, I just get the following . .
INFO: Processing changes...
INFO: No deps to find on server
I worked out that if I initialize the repository with bii init -L then everything works. However, bii init --help says . .
usage: bii init [-h] [-L [LAYOUT]] [name]
creates a new biicode project
positional arguments: name Optional name of the
folder. If specified, bii will
create a new folder and initialize a project inside,
otherwise, it will try to initialize in the current
folder
optional arguments: -h, --help show this help message and
exit -L [LAYOUT], -l [LAYOUT], --layout [LAYOUT]
Optional layout. If no param is specified, it will use
the "minimal" one. Other available: CLion
Which suggests the L parameter is ignored if I do not specify a layout.
My question is what does the L parameter do with no layout specified, compared to just typing bii init with no extra params?
NOTES:
OSX 10.10.2
bii 2.7
bii init command without parameters enables working with multiple blocks at the same time within the same project.
It inits by default a classic layout. Its behaviour is explained in biicode's docs here.
To use it:
bii init to init your project and then bii new username/blockname to create the folder structure needed to use multiple blocks at the same time.
Then your code should be placed under project/blocks/username/blockname directory.
Using bii init enables working with multiple blocks like this:
cd your_project_name
bii open examples/tinythread
bii open examples/box2d
bii build
cd bin
./run_any_exectuable_here
You can also check the docs section about layouts.
Basically
$ bii init -L
is the same as
$ bii init -L=simple
Where simple is the minimal layout, that allows to edit a block directly in the project root.
Surely the command help can be improved. The resulting layout will be:
project
|-bii
| |-deps
| |-cmake
| |-build
|-bin
| |-myexe
|-main.cpp
If not using the -L option, you are creating a regular biicode project layout, which is much different, that require user blocks to be inside the "blocks" folder and all the aux folders (deps, build, cmake) will be in the project root. The typical workflow there would be
$ bii init myproject
$ cd myproject
$ git clone repo-url blocks/mybiicodeuser/myblockname
It is typical that the blockname is equal to the github repository name, and many people have a username equal for github and biicode.
Related
I am a newbie in go and go-swagger. I am following steps in Simple Server tutorial in goswagger.io.
I am using Ubuntu 18.04, swagger v0.25.0 and go 1.15.6.
Following the same steps, there are a few differences of the files generated. For instance, goswagger.io's has find_todos_okbody.go and get_okbody.go in models but mine does not. Why is that so?
Link to screenshot of my generated files vs
Link to screenshot of generated files by swagger.io
Starting the server as written in the tutorial go install ./cmd/todo-list-server/ gives me the following error. Can anyone please help with this?
# my_folder/swagger-todo-list/restapi
restapi/configure_todo_list.go:41:8: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
restapi/configure_todo_list.go:42:6: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
The first step in goswagger.io todo-list is swagger init spec .... Which directory should I run this command in? I ran it in a newly created folder in my home directory. However, from the page, it shows the path to be ~/go/src/github.com/go-swagger/go-swagger/examples/tutorials/todo-list. I am not sure whether I should use go get ..., git clone ... or create those folders. Can someone advise me?
Thanks.
This is likely the documentation lagging behind the version of the code that you are running. As long as it compiles, the specific files the tool generates isn't so crucial.
This is a compilation error. When you do go install foo it will try to build the foo package as an executable and then move that to your GOPATH/bin directory. It seems that the generated code in restapi/configure_todo_list.go isn't correct for the operations code generated.
All you need to run this tutorial yourself is an empty directory and the swagger tool (not its source code). You run the commands from the root of this empty project. In order not to run into GOPATH problems I would initialise a module with go mod init todo-list-example before doing anything else.
Note that while the todo-list example code exists inside the go-swagger source, it's there just for documenting example usage and output.
What I would advice for #2 is to make sure you're using a properly released version of go-swagger, rather than installing from the latest commit (which happens when you just do a go get), as I have found that to be occasionally unstable.
Next, re-generate the entire server, but make sure you also regenerate restapi/configure_todo_list.go by passing --regenerate-configureapi to your swagger generate call. This file isn't always refreshed because you're meant to modify it to configure your app, and if you changed versions of the tool it may be different and incompatible.
If after that you still get the compilation error, it may be worth submitting a bug report at https://github.com/go-swagger/go-swagger/issues.
Thanks #EzequielMuns. The errors in #2 went away after I ran go get - u -f ./... as stated in
...
For this generation to compile you need to have some packages in your GOPATH:
* github.com/go-openapi/runtime
* github.com/jessevdk/go-flags
You can get these now with: go get -u -f ./...
I think it's an error of swagger code generation. You can do as folloing to fix this:
delete file configure_todo_list.go;
regenerate code.
# swagger generate server -A todo-list -f ./swagger.yml
Then, you can run command go install ./cmd/todo-list-server/, it will succeed.
I am working to build an own "embeeded linux" with yocto. It is based on the SAMA5D3x-MB + SAMA5D3x-CM(RONETIX) with the SAMA5D35. I have two questions:
1.) changing the device tree
I build an image based on: MACHINE ??= "sama5d3xek"
After the generating process I found two device tree files for the 5D35 in the deploy dir:
zImage--4.1+git0+19291d7be4-r0-sama5d35ek-.dtb
zImage--4.1+git0+19291d7be4-r0-sama5d35ek-revc-.dtb
Because the mainboard is revD I am using zImage--4.1+git0+19291d7be4-r0-sama5d35ek-.dtb.
In this file only can0 and i2c1 are defined.
I like to use can1 and i2c0 as well. For that I think I need to create a own dts file and include it into the kernel build process.
So far I put the dts file at my meta-test recipe. Ideas how to copy/patch it into the kernel?
2.) changing the kernel config
I checked the kernel with
bitbake virtual/kernel -c menuconfig
because I am not using the SAMA5D2 etc. and only the console I deactivated these kernel configs. I saved the new ".config" to "my.config" into the my-recipe dir. I have a similar question like in 1 - How to patch/copy it into the kernel?
I am new to yocto and to kernel hacking. Any idea how to do it?
If you're on a recent Yocto project release, you can make use of recipetool to do most of the legwork on this. You have two options, you can use the existing recipetool commands and a small amount of manual work, or you can use the recipetool plugin in meta-mentor that provides a few kernel-specific commands to do this for you.
Layer setup
First, you'll want to have a layer to store your changes. If you've already created a layer, you can use that, otherwise we can create one and add it to our configuration:
$ yocto-layer create local 1
$ bitbake-layers add-layer meta-local
Option one: Using the recipetool plugin from meta-mentor
Setup
First, clone meta-mentor:
$ git clone https://github.com/MentorEmbedded/meta-mentor
Next, either add meta-mel to your configuration:
$ bitbake-layers add-layer path/to/meta-mentor/meta-mel
Or copy meta-mentor/meta-mel/lib into your own layer:
$ cp -a path/to/meta-mentor/meta-mel/lib meta-local/
Device tree
$ recipetool kernel_add_dts meta-local /path/to/your.dts
Kernel configuration
$ recipetool kernel_add_fragments meta-local /path/to/your.cfg
Or:
$ recipetool kernel_set_defconfig meta-local /path/to/the/defconfig
Option two: Manual
In the below section, clearly in your case, your-machine-name should be sama5d3xek. The '-m your-machine-name' passed to the recipetool commands below makes the changes in the recipe specific to your machine, rather than affecting any machine which uses that recipe. If you know that recipe is only used for your machine, then you could drop that, but it's safest to keep it, as some BSP layers use the same kernel recipe for multiple machines. For example, linux-yocto is used for many.
Device tree
Then, assuming you have a .dts handy you want to use:
$ recipetool appendsrcfile -wm your-machine-name path/to/meta-local virtual/kernel /path/to/your.dts 'arch/${ARCH}/boot/dts/your.dts'
This will create a .bbappend in meta-local and add the .dts to SRC_URI, placing it in the appropriate path in the kernel source tree. The next step is to edit the append it created and add the .dtb for your .dts to the KERNEL_DEVICETREE variable, i.e.:
KERNEL_DEVICETREE += "your.dtb"
If the kernel recipe includes recipes-kernel/linux/linux-dtb.inc, any .dtb files in KERNEL_DEVICETREE will be created from their .dts files by using the kernel's buildsystem. Some kernels do not include linux-dtb.inc, in which case you can do so yourself in the append:
require recipes-kernel/linux/linux-dtb.inc
Kernel configuration
The kernel configuration is slightly more complex, just because how the configuration is done varies slightly between kernel recipes. Some kernel recipes support configuration fragments (which are just a text file with part of a defconfig/.config), whereas others you'd have to override the configuration entirely. The 'linux-yocto' recipe can handle and use fragments, as can a few others.
To see what kernel recipe you're using (the top filename will be the one used):
$ bitbake -e virtual/kernel | grep '^FILE='
If you want to use configuration fragments, you can either manually create a fragment, or generate one:
$ bitbake -c menuconfig virtual/kernel
$ bitbake -c diffconfig virtual/kernel
The 'diffconfig' task will create a fragment with your changes from the menuconfig and print the path to it.
Then you can add it to the kernel (though again, only certain recipes will use it):
$ recipetool appendsrcfile -wWm your-machine-name meta-local virtual/kernel /path/to/your.cfg
To override the entire config, most recipes will obey and use a 'defconfig' source file, so:
$ recipetool appendsrcfile -Wm your-machine-name meta-local virtual/kernel /path/to/the/defconfig
Note: The defconfig is not generated automatic. Replace defconfig with the result of menuconfig('.config').
The devtool can be very handy if you want to generate patches for the linux-yocto kernel. Other kernel might not support devtool.
## create kernel source patch
devtool modify virtual/kernel
# make some changes
cd ~/poky_sdk/workspace/sources/linux-yocto
vi init/calibrate.c
# test before patch
bitbake -C compile virtual/kernel
# create patch
git add .
git commit -m 'some fix'
devtool update-recipe -a ~/meta-mylayer/ linux-yocto
# clean the source
rm -rf workspace/sources/linux-yocto/
see devtool for details
Related to this question, for educational purposes I tried to add a device tree to an x86 architecture (kernel 5.2.20). To enable the device tree compiler, the following additions to the configuration were needed :
CONFIG_COMPILE_TEST=y
CONFIG_OF=y
CONFIG_OF_ALL_DTBS=y
Furthermore, to enable device tree support at runtime, this was additionally needed :
CONFIG_OF_UNITTEST=y
A convenient place to check if your kernel configs are merged without problems is file
kernel-source/.kernel-meta/cfg/merge_config_build.log
Suppose you have a repository at github.com/someone/repo and you fork it to github.com/you/repo. You want to use your fork instead of the main repo, so you do a
go get github.com/you/repo
Now all the import paths in this repo will be "broken", meaning, if there are multiple packages in the repository that reference each other via absolute URLs, they will reference the source, not the fork.
Is there a better way as cloning it manually into the right path?
git clone git#github.com:you/repo.git $GOPATH/src/github.com/someone/repo
If you are using go modules. You could use replace directive
The replace directive allows you to supply another import path that might
be another module located in VCS (GitHub or elsewhere), or on your
local filesystem with a relative or absolute file path. The new import
path from the replace directive is used without needing to update the
import paths in the actual source code.
So you could do below in your go.mod file
module some-project
go 1.12
require (
github.com/someone/repo v1.20.0
)
replace github.com/someone/repo => github.com/you/repo v3.2.1
where v3.2.1 is tag on your repo. Also can be done through CLI
go mod edit -replace="github.com/someone/repo#v0.0.0=github.com/you/repo#v1.1.1"
To handle pull requests
fork a repository github.com/someone/repo to github.com/you/repo
download original code: go get github.com/someone/repo
be there: cd "$(go env GOPATH)/src"/github.com/someone/repo
enable uploading to your fork: git remote add myfork https://github.com/you/repo.git
upload your changes to your repo: git push myfork
http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html
To use a package in your project
https://github.com/golang/go/wiki/PackageManagementTools
One way to solve it is that suggested by Ivan Rave and http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html -- the way of forking.
Another one is to workaround the golang behavior. When you go get, golang lays out your directories under same name as in the repository URI, and this is where the trouble begins.
If, instead, you issue your own git clone, you can clone your repository onto your filesystem on a path named after the original repository.
Assuming original repository is in github.com/awsome-org/tool and you fork it onto github.com/awesome-you/tool, you can:
cd $GOPATH
mkdir -p {src,bin,pkg}
mkdir -p src/github.com/awesome-org/
cd src/github.com/awesome-org/
git clone git#github.com:awesome-you/tool.git # OR: git clone https://github.com/awesome-you/tool.git
cd tool/
go get ./...
golang is perfectly happy to continue with this repository and doesn't actually care some upper directory has the name awesome-org while the git remote is awesome-you. All import for awesome-org are resovled via the directory you have just created, which is your local working set.
In more length, please see my blog post: Forking Golang repositories on GitHub and managing the import path
edit: fixed directory path
If your fork is only temporary (ie you intend that it be merged) then just do your development in situ, eg in $GOPATH/src/launchpad.net/goamz.
You then use the features of the version control system (eg git remote) to make the upstream repository your repository rather than the original one.
It makes it harder for other people to use your repository with go get but much easier for it to be integrated upstream.
In fact I have a repository for goamz at lp:~nick-craig-wood/goamz/goamz which I develop for in exactly that way. Maybe the author will merge it one day!
Here's a way to that works for everyone:
Use github to fork to "my/repo" (just an example):
go get github.com/my/repo
cd ~/go/src/github.com/my/repo
git branch enhancement
rm -rf .
go get github.com/golang/tools/cmd/gomvpkg/…
gomvpkg <<oldrepo>> ~/go/src/github.com/my/repo
git commit
Repeat each time when you make the code better:
git commit
git checkout enhancement
git cherry-pick <<commit_id>>
git checkout master
Why? This lets you have your repo that any go get works with. It also lets you maintain & enhance a branch that's good for a pull request. It doesn't bloat git with "vendor", it preserves history, and build tools can make sense of it.
Instead of cloning to a specific location, you can clone wherever you want.
Then, you can run a command like this, to have Go refer to the local version:
go mod edit -replace github.com/owner/repo=../repo
https://golang.org/cmd/go#hdr-Module_maintenance
The answer to this is that if you fork a repo with multiple packages you will need to rename all the relevant import paths. This is largely a good thing since you've forked all of those packages and the import paths should reflect this.
Use vendoring and submodules together
Fork the lib on github (go-mssqldb in this case)
Add a submodule which clones your fork into your vendor folder but has the path of the upstream repo
Update your import statements in your source code to point to the vendor folder, (not including the vendor/ prefix). E.g. vendor/bob/lib => import "bob/lib"
E.g.
cd ~/go/src/github.com/myproj
mygithubuser=timabell
upstreamgithubuser=denisenkom
librepo=go-mssqldb
git submodule add "git#github.com:$mygithubuser/$librepo" "vendor/$upstreamgithubuser/$librepo"
Why
This solves all the problems I've heard about and come across while trying to figure this out myself.
Internal package refs in the lib now work because the path is unchanged from upstream
A fresh checkout of your project works because the submodule system gets it from your fork at the right commit but in the upstream folder path
You don't have to know to manually hack the paths or mess with the go tooling.
More info
https://git-scm.com/book/en/v2/Git-Tools-Submodules
How do I fix the error message "use of an internal package not allowed" when go getting a golang package?
https://github.com/denisenkom/go-mssqldb/issues/406
https://github.com/golang/go/wiki/PackageManagementTools#go15vendorexperiment
The modern answer (go 1.15 and higher, at least).
go mod init github.com/theirs/repo
Make an explicit init arg that is the ORIGINAL package names. If you don't include the repo name, it will assume the one in gopath. But when you use go modules, they no longer care where they are on disk, or where git actually pulls dependencies from.
To automate this process, I wrote a small script. You can find more details on my blog to add a command like "gofork" to your bash.
function gofork() {
if [ $# -ne 2 ] || [ -z "$1" ] || [ -z "$2" ]; then
echo 'Usage: gofork yourFork originalModule'
echo 'Example: gofork github.com/YourName/go-contrib github.com/heirko/go-contrib'
return
fi
echo "Go get fork $1 and replace $2 in GOPATH: $GOPATH"
go get $1
go get $2
currentDir=$PWD
cd $GOPATH/src/$1
remote1=$(git config --get remote.origin.url)
cd $GOPATH/src/$2
remote2=$(git config --get remote.origin.url)
cd $currentDir
rm -rf $GOPATH/src/$2
mv $GOPATH/src/$1 $GOPATH/src/$2
cd $GOPATH/src/$2
git remote add their $remote2
echo Now in $GOPATH/src/$2 origin remote is $remote1
echo And in $GOPATH/src/$2 their remote is $remote2
cd $currentDir
}
export -f gofork
You can use command go get -f to get you a forked repo
in your Gopkg.toml file add these block below
[[constraint]]
name = "github.com/globalsign/mgo"
branch = "master"
source = "github.com/myfork/project2"
So it will use the forked project2 in place of github.com/globalsign/mgo
I'm getting this error on my mac osx build.
Primer3/eprimer3 issue:
Error: thermodynamic approach chosen, but path to thermodynamic parameters not specified
From:
http://www.mcardle.wisc.edu/mprime/help/primer3/primer3_manual.htm#globalTags
PRIMER_THERMODYNAMIC_PARAMETERS_PATH (string; default ./primer3_config)
This tag specifies the path to the directory that contains all the parameter files used by the thermodynamic approach. In Linux, there are two default locations that are tested if this tag is not defined: ./primer3_config/ and /opt/primer3_config/. For Windows, there is only one default location: .\primer3_config\.
I put the primer3_config in my PATH in bin and still cannot solve this issue. I even did:
export PRIMER_THERMODYNAMIC_PARAMETERS_PATH=/Users/jared/Downloads/primer3-2.3.2/src
and
export PRIMER_THERMODYNAMIC_PARAMETERS_PATH=/Users/jared/Downloads/primer3-2.3.2/src/primer3_config
to no avail.
According to the primer3 manual:
1.5. IMPORTANT: because PRIMER_THERMODYNAMIC_ALIGNMENT=1
PRIMER_THERMODYNAMIC_PARAMETERS_PATH must point to the right location.
This tag specifies the path to the directory that contains all the
parameter files used by the thermodynamic approach. In Linux, there
are two default locations that are tested if this tag is not
defined: ./primer3_config/ and /opt/primer3_config/. For Windows,
there is only one default location: .\primer3_config. If the the
parameter files are not in one these locations, be sure to set
PRIMER_THERMODYNAMIC_PARAMETERS_PATH.
So if you download and compile primer3 form source using the Make command, to get primer3 to run globally you need to copy the executueable, primer3_core, to your path and place the configuration directory, primer3_config in that same directory or at /opt/primer3_config
cd src
sudo cp primer3_core /usr/local/bin # or /usr/bin
sudo cp -r primer3_config /opt/
I has the same issue. I had installed Primer 3 using homebrew-science which was pretty painless. https://github.com/Homebrew/homebrew-science
I did try copying the primer3_config directory into the homebrew primer3 directory, ie:
/usr/local/Cellar/primer3/2.3.4/bin/primer3_config but this also did not work.
In the end I added the PRIMER_THERMODYNAMIC_PARAMETERS_PATH configuration to the primer 3 input file, and this worked. Note that the directory name must have a trailing slash. It is the last entry in the file below which is copied from the example file in the primer3 sources.
SEQUENCE_ID=example
SEQUENCE_TEMPLATE=GTAGTCAGTAGACNATGACNACTGACGATGCAGACNACACACACACACACAGCACACAGGTATTAGTGGGCCATTCGATCCCGACCCAAATCGATAGCTACGATGACG
SEQUENCE_TARGET=37,21
PRIMER_TASK=pick_detection_primers
PRIMER_PICK_LEFT_PRIMER=1
PRIMER_PICK_INTERNAL_OLIGO=1
PRIMER_PICK_RIGHT_PRIMER=1
PRIMER_OPT_SIZE=18
PRIMER_MIN_SIZE=15
PRIMER_MAX_SIZE=21
PRIMER_MAX_NS_ACCEPTED=1
PRIMER_PRODUCT_SIZE_RANGE=75-100
P3_FILE_FLAG=1
SEQUENCE_INTERNAL_EXCLUDED_REGION=37,21
PRIMER_EXPLAIN_FLAG=1
PRIMER_THERMODYNAMIC_PARAMETERS_PATH=/usr/local/Cellar/primer3/2.3.4/bin/primer3_config/
=
Then run it like this:
$ primer3_core < example2
I just installed mogenerator+xmo'd on my development machine and would like to start playing with it. The only instructions I could really find online were from a previous SO post, and those don't work with XCode 4 (or at least ⌘I doesn't pull up metadata any more and I don't know how).
So to get things up and running, is all that needs to happen to add xmod in the .xcdatamodeld's comments (wherever they are) and the classes will be generated/updated on save from then on?
While trying to find this answer myself, I found MOGenerator and Xcode 4 integration guide on esenciadev.com. This solution is not a push-button integration, but it works. The link has detailed instructions, but generally you:
Copy the shell scripts into your project
Add build rules to your target to run the two shell scripts
When you build your project, the script runs MOGenerator on all .xcdatamodel files in your project directory. After the build, if the script generates new class files, you must manually add them to your project. Subsequent builds will remember existing MO-Generated files.
Caveats:
The example's build rule assumes you put the scripts into a /scripts/ file folder within your project directory. When I ignored this detail (creating a project folder but not a file folder) I got a build error. Make sure the build rule points to the script's file location.
The script uses the --base-class argument. Unless your model classes are subclasses of a custom class (not NSManagedObject), you must delete this argument from the script. E.g.,
mogenerator --model "${INPUT_FILE_PATH}/$curVer" --output-dir "${INPUT_FILE_DIR}/" --base-class $baseClass
Now that Xcode 4 is released Take a look at the Issues page for mogenerator
After I make changes to my model file, I just run mogenerator manually from the terminal. Using Xcode 4 and ARC, this does the trick:
cd <directory of model file>
mogenerator --model <your model>.xcdatamodeld/<current version>.xcdatamodel --template-var arc=YES
Maybe I'll use build scripts at some point, but the terminal approach is too simple to screw up.
I've found a Script in the "Build Phases" to be more reliable than the "Build Rules".
Under "Build Phases" for your Target, choose the button at the bottom to "Add Run Script". Drag the run script to the top so that it executes before compiling sources.
Remember that the actual data model files (.xcdatamodel) are contained within a package (.xcdatamodeld), and that you only need to compile the latest data model for your project.
Add the following to the script (replacing text in angle-brackets as appropriate)
MODELS_DIR="${PROJECT_DIR}/<path to your models without trailing slash>"
DATA_MODEL_PACKAGE="$MODELS_DIR/<your model name>.xcdatamodeld"
CURRENT_VERSION=`/usr/libexec/PlistBuddy "$DATA_MODEL_PACKAGE/.xccurrentversion" -c 'print _XCCurrentVersionName'`
# Mogenerator Location
if [ -x /usr/local/bin/mogenerator ]; then
echo "mogenerator exists in /usr/local/bin path";
MOGENERATOR_DIR="/usr/local/bin";
elif [ -x /usr/bin/mogenerator ]; then
echo "mogenerator exists in /usr/bin path";
MOGENERATOR_DIR="/usr/bin";
else
echo "mogenerator not found"; exit 1;
fi
$MOGENERATOR_DIR/mogenerator --model "$DATA_MODEL_PACKAGE/$CURRENT_VERSION" --output-dir "$MODELS_DIR/"
Add options to mogenerator as appropriate. --base-class <your base class> and --template-var arc=true are common.
Random tip. If you get Illegal Instruction: 4 when you run mogenerator. Install it from the command line:
$ brew update && brew upgrade mogenerator