After I upgrade sbt to 1.3.8, I see a lot of unuseful messages in the sbt console, which is very annoying. I searched online but didn't find a good key word. Does anyone know how to disable the messages showing like below?
| => Zero / checkBuildSources / dynamicInputs 0s
| => Zero / checkBuildSources / dynamicInputs 0s
| => Global / previousCache 0s
| => Zero / checkBuildSources / dynamicInputs 0s
| => Global / previousCache 0s
These messages are progress logging from the sbt "super-shell". You can disable it using the sbt.supershell option, e.g.
sbt -Dsbt.supershell=false
Or by adding it to your .sbtopts file or SBT_OPTS env var (check sbt -help for details on how to use them). See also Command Line Options for the reference.
Related
I'm not sure if there is already a command like this existing, but what about a command like that in a code language:
do this
do that
<point2>
if (something){
GOTO ('point1')
}
do this
do that
<point1>
do this
do that
if (something){
go to ('point2')
}
a command which just leads the program to a point forward or backward in the code
i know you can do this with if clauses and functions and have the same effect
otherwise with this command you can portray code in blocks:
_____________ <-----
| start motor | | Go to command
| if failure -------
|_____________|
|
|
\/
Drive
My questions:
do we need this command? , is it useful in languages like java or php or else? and why is it unset in java? Could it be upgraded or made better and how? is it enough for not using loops anymore? Or has a goto command a major downside? Maybe in compiling or so its performance is bad... ----why dont i use it or find it in any tutorial when it could be a standard command like loops... why????
I'm thankful for a nice discussion about this command and for not writing how many grammar mistakes I made ...
"a command which just leads the program to a point forward or backward in the code" <-- it is called GOTO command. Different programming language may implement it differently.
"nice discussion about this command" <--- After your research, mind sharing which part of the reading materials/reference/code that you don't understand or can't be execute? A sample code and screenshot may help too.. (:
I have a semi-complicated SBT process because I need to conditionally include a different config file based on what kind of build is needed. I solved this problem through sub-projects:
lazy val app = project
.in(file("."))
.enablePlugins(JavaAppPackaging)
.settings(
commonSettings // Seq() of settings to be shared between projects
,sourceGenerators in Compile += (avroScalaGenerateSpecific in Compile).taskValue
,(avroSpecificSourceDirectory in Compile) := new java.io.File("src/main/resources/com/coolCompany/folderName/avro")
)
lazy val localPackage = project
.in(file("build/local"))
.enablePlugins(JavaAppPackaging)
.settings(
organization := "com.coolCompany",
version := "0.1.0-SNAPSHOT",
scalaVersion := "2.11.8",
name := "my-neat-project",
scalacOptions := compilerOptions, //Seq() of compiler flags
sourceDirectory in Compile := (sourceDirectory in (app, Compile)).value,
mappings in Universal += {
((sourceDirectory in Compile).value / "../../conf/local/config.properties") -> "lib/config.properties"
}
)
.dependsOn(app)
val buildNumber = inputKey[String]("The version number of the artifact.")
lazy val deployedPackage = project
.in(file("build/deployed"))
.enablePlugins(JavaAppPackaging)
.settings(
organization := "com.coolCompany",
buildNumber := {
val args : Seq[String] = spaceDelimited("<arg>").parsed
println(s"Input version number is ${args.head}")
args.head
},
version := buildNumber.inputTaskValue + "-SNAPSHOT", //"0.1.0-SNAPSHOT",
scalaVersion := "2.11.8",
name := "my-cool-project",
scalacOptions := compilerOptions,
sourceDirectory in Compile := (sourceDirectory in (app, Compile)).value,
mappings in Universal += {
((sourceDirectory in Compile).value / "../../conf/deployed/config.properties") -> "lib/config.properties"
}
)
.dependsOn(app)
Now I need to allow the version number to be passed in by a build tool when building. You can see what I've attempted to do already: I created an inputKey task called buildNumber, then tried to access that in the version := definition. I can run the buildNumber task itself just fine:
$ sbt 'deployedPackage/buildNumber 0.1.2'
Input version number is 0.1.2
So I can at least verify that my input task works as expected. The issue is that I can't figure out how I actually get to that input value when running the actual packageBin step that I want.
I've tried the following:
$ sbt 'deployedPackage/universal:packageBin 0.1.2'
[error] Expected key
[error] Expected '::'
[error] Expected end of input.
[error] deployedPackage/universal:packageBin 0.1.2
So it clearly doesn't understand what to do with the version number. I've tried a bunch of different input variations, such as [...]packageBin buildNumber::0.1.2, [...]packageBin -- buildNumber 0.1.2, or [...]packageBin -- 0.1.2, and all of them give that error or something similar indicating it doesn't understand what I'm trying to pass in.
Now, ultimately, these errors make sense. buildNumber, the task, is what knows what to do with the command line values, but packageBin does not. How do I set up this task or these set of tasks to allow the version number to be passed in?
I have seen this question but the answers link to an sbt plugin that seems to do about 100 more things than I want it to do, including quite a few that I would need to find a way to explicitly disable. I only want the version number to be able to be passed in & used in the artifact.
Edit/Update: I resolved this issue by switching back to Maven.
I think you're a bit confused about the way sbt settings work. Settings are set when sbt loads and then cannot be changed until you reload the session. So whatever you set version to, it will be fixed, it cannot be dynamic and depend on user input or a task (which on the contrast is dynamic and is evaluated every time you call it).
This is true. However you can still compute a SettingKey value in the first place. We use environment variables to set our build version.
version := "1." + sys.env.getOrElse("BUILD_NUMBER", "0-SNAPSHOT")
Explanation
1. is the major version. Increment this manually as you like
BUILD_NUMBER is an environment variable that is typically set by a CI, e.g. Jenkins. If not set, use 0-SNAPSHOT as a version suffix.
We use this in our company for our continuous deployment pipeline.
Hope that helps,
Muki
I think you're a bit confused about the way sbt settings work. Settings are set when sbt loads and then cannot be changed until you reload the session. So whatever you set version to, it will be fixed, it cannot be dynamic and depend on user input or a task (which on the contrast is dynamic and is evaluated every time you call it).
You have an input task buildNumber which depends on user input and is evaluated every time you call it:
> show buildNumber 123
Input version number is 123
[info] 123
[success] Total time: 0 s, completed Dec 24, 2017 3:41:43 PM
> show buildNumber 456
Input version number is 456
[info] 456
[success] Total time: 0 s, completed Dec 24, 2017 3:41:45 PM
It returns whatever you give it and doesn't do anything (besides println). More importantly, it doesn't affect version setting anyhow (and couldn't even in theory).
When you use buildNumber.inputTaskValue, you refer to the input task itself, not its value (which is unknown because it depends on the user input). You can see it by checking the version setting value:
> show version
[info] sbt.InputTask#6c996907-SNAPSHOT
So it's definitely not what you want.
I suggest you to review your approach in general and read a bit more sbt docs, for example about Task graph (and the whole Getting started chapter).
If you still really need to set version on sbt load according to your input, you can do it with a command. It would look like this:
commands += Command.single("pkg") { (state0, buildNumber) =>
val state1 = Project.extract(state0).append(Seq(version := buildNumber + "-SNAPSHOT"), state0)
val (state2, result) = Project.extract(state1).runTask(packageBin in (deployedPackage, universal), state1)
state2
}
But you should be really careful dealing with the state manually. Again, I recommend you to review your approach and change it to a more sbt-idiomatic one.
I suggest you just set the version setting only for the project deployedPackage just before you call the task needing the version. This is the simplest way of setting the version, and as settings keys have scopes, this should work as intended.
I used something like this for a big multi module project, where one of the projects had a separate versioning history than the other projects.
I'm quite new with Robot Framework, and I cannot find a way to run a process with arguments on windows. I am quite sure I did not understand the documentation and there is a simple way of doing that though...
Ok, let's say I can start my program using this command:
c:\myappdir>MyApp.exe /I ..\params\myAppParams.bin
How to do that in RF?
Any kind of help would be appreciated.
Thank you very much :)
Edit 1:
Here is a piece of my code:
| *Setting* | *Value*
| Resource | compilationResource.robot
#(Process lib is included in compilationResource)
#I removed the "|" for readability
...
TEST1
...
${REPLAYEXEDIR}= get_replay_exe_dir #from a custom lib included in compilationResource
${EXEFULLPATH}= Join Path ${WORKSPACEDIR} ${REPLAYEXEDIR} SDataProc.exe
Should Exist ${EXEFULLPATH}
${REPLAYLOGPATH}= Join Path ${WORKSPACEDIR} ReplayLog.log
${REPLAYFILEPATH}= Join Path ${WORKSPACEDIR} params params.bin
Should Exist ${REPLAYFILEPATH}
Start Process ${EXEFULLPATH} stderr=${REPLAYLOGPATH} stdout=${REPLAYLOGPATH} alias=replayjob
Process Should Be Running replayjob
Terminate Process replayjob
Process Should Be Stopped replayjob
This works. As soon as I try to include the arguments like this:
Start Process ${EXEFULLPATH} ${/}I ${REPLAYFILEPATH} stderr=${REPLAYLOGPATH} stdout=${REPLAYLOGPATH} alias=replayjob
I get this error:
WindowsError: [Error 2] The system cannot find the file specified
and this error comes from the start process line.
Let me know if I was unclear or if nmore info is needed.
Thank you all for your help on this.
Edit 2: SOLUTION
Each argument must be separated form the other (when not running in shell) with a double space. I was not using double spaces, hence the error.
| | Start Process | ${EXEFULLPATH} | /I | ${REPLAYFILEPATH} | stderr=${REPLAYLOGPATH} | stdout=${REPLAYLOGPATH} | alias=replayjob
To launch your program from a Robot Framework Test, use the Process library like:
*** Settings ***
Library Process
*** Test Cases ***
First test
Run Process c:${/}myappdir${/}prog.py /I ..\params\myAppParams.bin
# and then do some tests....
We're using Boost-Build to build our software. To help facilitate this, we've written a library of rules and actions. Boost-Build allows passing in command line arguments and will pass along any argument prefixed with --. Currently, to get a hold of the arguments and check for flags we're doing something like:
import modules ;
local args = [ modules.peek : ARGV ] ;
# or like this
if "--my-flag" in [ modules.peek : ARGV ]
Which works to get and check values. However, developers that use Boost-Build and our jam libraries have no idea that these flags are available and would like to see some help on these flags whenever they run either bjam -h or bjam --help. I see that BB has a help module, but I don't see any way to register arguments with the help system.
Is there a way to register command line flags, complete with short documentation, that the help system will pick up?
In response to my own question, I have added the very feature that I was asking about: https://github.com/boostorg/build/pull/23
It uses the existing options plugin system. Whenever you want to create a new command-line option create a new module within the options directory. Within that new module, create a variable that holds a value or is empty. Above the variable create a comment. The comment is used as the command-line documentation and the value (if given) is used to describe the default value of that variable.
Create a process rule within the new module and register your option with the system. This allows importing the option module and getting the value from a single source. This requires that each variable name is prefixed with the name of the module.
Create a variable named .option-description. Its value is the section separator and its comment is the description of the section.
For example:
# within options/cool.jam
# These are the options for the Cool option plugin
.option-description = Cool Options
# This enables option1
.option.--cool-option1 ?= ;
# This enables something cool
.option.--cool-default-option ?= "my default value" ;
rule process (
command # The option.
: values * # The values, starting after the "=".
)
{
option.set $(command) : $(values) ;
}
When running bjam with the --help-options flag, it will output all modules that follow the above patterns within the options directory. It will have an output similar to the following:
Boost.Build Usage:
b2 [ options... ] targets...
* -a; Build all targets, even if they are current.
* -fx; Read 'x' as the Jamfile for building instead of searching for the
Boost.Build system.
* -jx; Run up to 'x' commands concurrently.
* -n; Do not execute build commands. Instead print out the commands as they
would be executed if building.
* -ox; Output the used build commands to file 'x'.
* -q; Quit as soon as a build failure is encountered. Without this option
Boost.Jam will continue building as many targets as it can.
* -sx=y; Sets a Jam variable 'x' to the value 'y', overriding any value that
variable would have from the environment.
* -tx; Rebuild the target 'x', even if it is up-to-date.
* -v; Display the version of b2.
* --x; Any option not explicitly handled by Boost.Build remains available to
build scripts using the 'ARGV' variable.
* --abbreviate-paths; Use abbreviated paths for targets.
* --hash; Shorten target paths by using an MD5 hash.
* -dn; Enables output of diagnostic messages. The debug level 'n' and all
below it are enabled by this option.
* -d+n; Enables output of diagnostic messages. Only the output for debug
level 'n' is enabled.
Debug Levels:
Each debug level shows a different set of information. Usually with higher
levels producing more verbose information. The following levels are supported:
* 0; Turn off all diagnostic output. Only errors are reported.
* 1; Show the actions taken for building targets, as they are executed.
* 2; Show quiet actions and display all action text, as they are executed.
* 3; Show dependency analysis, and target/source timestamps/paths.
* 4; Show arguments of shell invocations.
* 5; Show rule invocations and variable expansions.
* 6; Show directory/header file/archive scans, and attempts at binding to
targets.
* 7; Show variable settings.
* 8; Show variable fetches, variable expansions, and evaluation of 'if'
expressions.
* 9; Show variable manipulation, scanner tokens, and memory usage.
* 10; Show execution times for rules.
* 11; Show parsing progress of Jamfiles.
* 12; Show graph for target dependencies.
* 13; Show changes in target status (fate).
Cool Options:
These are the options for the Cool option plugin
* --cool-option1: This enables option1. Default is disabled.
* --cool-default-option: This enables something cool. "my default value".
Later on in your own Jam code, you can then get a hold of values from the registered options by doing:
import option ;
option1 = option.get '--cool-option1' ;
if $(option1) {
# do_something ;
}
There is no way to "register" individual options with the B2 help system. As generally that's just not how the help system works. The help system documents B2 modules (i.e. classes) and projects (i.e. jamfiles) only. What you see when you do "b2 --help" is a collection of the project help information and module information. All the data is extracted from the parse jamfiles.
For modules you add comments to classes and arguments and they get formatted for output. For example take a look at the "container.jam" source. In that the second comment on the file is a module help doc, the comment before "class node" is a class help doc, the comment before "rule set" is a method help doc, and the comment after the "value ?" argument is a help doc.
For projects the second comment in the project's jamfile is taken as the help doc. For example the Boost Jamroot has a large help doc comment for the usage information. This is printed out if you:
cd <boost-root>
b2 --help
If you such a comment to one of your project jamfiles (note: it assumes the first comment is a copyright notice and hence skips it and uses the second comment block for the help doc), and cd to that project directory and do b2 --help you should see it printed.
Which type of help doc you want is of course dependent on your project and your intentions.
I have an RSS feed that should include any posts that do not have any of these attributes:
A tag "conferencebox"
A category "Appearances"
A category "Appearances_Archive"
That is... any one of those qualities means it shouldn't be in the RSS feed.
I tried this:
<MTEntries category="NOT Appearances AND NOT Appearances_Archive" tag="NOT #conferencebox" lastn="15">
but I get this error:
Publish error in template 'RSS': Error in <mtEntries> tag: You have an error in your 'category' attribute: NOT Appearances AND NOT Appearances_Archive
When I reduce it to:
<MTEntries category="NOT Appearances" tag="NOT #conferencebox" lastn="15">
it works as expected (I get the Appearances_Archive posts) but the others are excluded.
I've tried renaming the category so that it doesn't have a "_" in it, but that doesn't fix the problem.
If I change it to:
<MTEntries category="NOT Appearances AND NOT appearancesarchive" tag="NOT #conferencebox" lastn="15">
I don't get an error, but the RSS feed still includes the "appearancesarchive" posts.
This also doesn't get an error, but doesn't not produce an RSS feed as I want:
<MTEntries category="NOT (Appearances OR appearancesarchive)" tag="NOT #conferencebox" lastn="15">
I've tried various combinations of CamelCase, lowercase, with and without "_". No luck.
Versions: Movable Type Pro version 5.2.3 with: Community Pack 1.92, Professional Pack 1.72
Yes, this is possible, and I believe your first attempt should have worked.
One install I tested using 4.37. This works fine:
<mt:Entries lastn="10" categories="NOT Personal AND NOT Conversations">
Then I used a 5.2.6 Pro install to rename two categories and a tag to match yours. I changed the labels to match yours but made the basenames random characters to make sure it didn’t have to do with basenames. I was able to publish your exact snippet, and the returned entries seem as expected:
<MTEntries category="NOT Appearances AND NOT Appearances_Archive" tags="NOT #conferencebox" lastn="15">
<mt:EntryIfCategory><mt:EntryIfTagged><mt:EntryID> CATS: <mt:EntryCategories glue=","><mt:CategoryLabel></mt:EntryCategories> TAGS: <mt:EntryTags glue=","><mt:TagName></mt:EntryTags></mt:EntryIfTagged></mt:EntryIfCategory></mt:Entries>
I checked if 5.2.3 might be the problem, but I don’t think so. A diff of lib/MT/Template/Tags/Entry.pm between 5.2.3 and 5.2.6 shows no substantial changes:
➜ Projects git clone https://github.com/movabletype/movabletype.git
Cloning into 'movabletype'...
remote: Counting objects: 91433, done.
remote: Compressing objects: 100% (27561/27561), done.
remote: Total 91433 (delta 63969), reused 89691 (delta 62257)
Receiving objects: 100% (91433/91433), 41.49 MiB | 811 KiB/s, done.
Resolving deltas: 100% (63969/63969), done.
➜ Projects cd movabletype
➜ movabletype git:(master) git diff 122a610d87e8fcc95b3534970d3d2346b88f8256 master -- lib/MT/Template/Tags/Entry.pm > diff.txt
➜ movabletype git:(master) ✗ cat diff.txt
diff --git a/lib/MT/Template/Tags/Entry.pm b/lib/MT/Template/Tags/Entry.pm
index c431b1a..89d5caf 100644
--- a/lib/MT/Template/Tags/Entry.pm
+++ b/lib/MT/Template/Tags/Entry.pm
## -1,4 +1,4 ##
-# Movable Type (r) Open Source (C) 2001-2012 Six Apart, Ltd.
+# Movable Type (r) Open Source (C) 2001-2013 Six Apart, Ltd.
# This program is distributed under the terms of the
# GNU General Public License, version 2.
#
So I’m currently at a loss as to why you got the error, but I’m posting this as an answer because it answers the question in your title!
Could you provide a link to the text of the full template? Perhaps a list of any nonstandard plugins you might have installed?