There are lots of parameters for JVM. Some start with -, such as -server, -client. Some start with -X, such as -Xms, -Xmx. Some start with -XX, such as -XX:PermSize, -XX:UseParallelGC.
Since these parameters are not duplicated, why start with so many different prefix? Why not just use -. My guess is there are some kind of standards for this. The -XX parameters are extension settings and not supported by all JVM impls. Is that so?
These are three main categories of Command-Line Argument options:
Standard options :Options that begin with - are Standard options are expected to be accepted by all JVM implementations and are stable between releases (though they can be deprecated).
Non-standard options :Options that begin with -X are non-standard (not guaranteed to be supported on all JVM implementations), and are subject to change without notice in subsequent releases of the Java SDK.
Developer options :Options that begin with -XX are developer options and often have specific system requirements for correct operation and may require privileged access to system configuration parameters; they are not recommended for casual use. These options are also subject to change without notice.
src
Yeah, its the level of support. The vanilla ("-") options are supported in future versions, and the X are not supported. Further, the XX options are "not recommended for casual use".
For an example, see IBM's JVM documentation: http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom.ibm.java.doc.user.aix64.60%2Fdiag%2Fappendixes%2Fcmdline%2Fcommands_jvm.html
Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the JDK.
Options that are specified with -XX are not stable and are subject to change without notice.
Java Reference
java -help:
-X Displays information about non-standard options and exit
Related
The CMake documentation on generator expressions is fairly clear that "A common mistake is to try to split a generator expression across multiple lines with indenting". Here is the example they give:
# WRONG: New lines and spaces all treated as argument separators, so the
# generator expression is split and not recognized correctly.
target_compile_definitions(tgt PRIVATE
$<$<AND:
$<CXX_COMPILER_ID:GNU>,
$<VERSION_GREATER_EQUAL:$<CXX_COMPILER_VERSION>,5>
>:HAVE_5_OR_LATER>
)
My experience is that using multiple lines with indenting works exactly as I'd hope. For example, the following code produces the exact results I would naively expect with the use of whitespace and indentation:
target_compile_options(common_interface INTERFACE
$<$<CXX_COMPILER_ID:MSVC>:
/W4 # Turn on warnings
/WX # Turn warnings into errors
>
$<$<CXX_COMPILER_ID:GNU,Clang,AppleClang>:
-Wall # Turn on warnings
-Wextra # Turn on warnings
-Werror # Turn warnings into errors
>
)
As I understand the CMake documentation, each line here would be added as a separate compile option (e.g., $<$<CXX_COMPILER_ID:MSVC>:), but that is clearly not the case since the generated build files show the flags come through correctly.
My questions are:
What am I missing? Is the issue only with certain types of expressions (e.g., logical operators)? Has the behavior changed and the documentation is out of date? or maybe the documentation needs to be enhanced to clarify the restrictions and expected behavior?
Is it safe to continue using whitespace and indentation in some circumstances?
My suspicion is that the resulting true_string (or false_string in $<IF:condition,true_string,false_string>) of a conditional expression may contain whitespace, but the other arguments of an expression cannot be broken.
Tsyvarev's comments to the question are on the money, but I'll give a more formal answer as both one of the CMake maintainers and the author of the generator expression documentation you linked to. The TLDR version is "The docs describe what you can rely on. Don't rely on implementation details that are outside that and which may change.".
The documentation makes clear where you are required to use quoting to ensure robust behavior. Splitting a genex across multiple lines or whitespace has never been officially supported. Sometimes it might appear to work, but that is by coincidence, not by design. Just because you found a case that happens to work in some range of CMake versions, you shouldn't assume that is supported behavior, especially when the documentation now explicitly calls that out as unsupported. There is no promise that such unsupported behavior will continue to work in future releases.
To be absolutely clear, the direct answers to your questions are:
What am I missing? Is the issue only with certain types of expressions (e.g., logical operators)? Has the behavior changed and the documentation is out of date? or maybe the documentation needs to be enhanced to clarify the restrictions and expected behavior?
The documentation is up to date, and I don't know how to make things clearer than what the existing documentation already says. You're asking about things that go directly against that documentation. The aspects you're asking about are not things we intend to document because they are specifically not intended to be supported behavior! Furthermore, CMake's behavior in this area may well have changed over different versions, but it has never been promised to be stable, since it has never been part of CMake's documented API.
Is it safe to continue using whitespace and indentation in some circumstances?
No. The current documentation should make it very clear what's safe and what isn't. If you're asking if something that contradicts that documentation is safe, well, it should hopefully be clear that my answer is still "No". ;)
Footnote
People failing to quote their generator expressions has been one of the most frequently reported problems (or more accurately, the cause of reported problems) in the CMake forums and issue tracker. It kept biting people over and over, to the point where I wrote a Quoting In CMake blog article about quoting in general and I also added the Whitespace And Quoting section to the generator expressions manual in the official CMake docs (that update appeared with CMake 3.24).
While using async-profiler I run the profiles for cpu and alloc separately but was hoping it would be possible to use them as part of the same duration? Given the output format types supported, this only seems to make sense if JFR is used.
Yes, this feature is implemented in v2.0 branch of async-profiler. The branch is currently under development, use with care. Planned for the next major release.
To specify multiple events in the command line, use
profiler.sh -e cpu,alloc -f out.jfr ...
The same as an agent option:
-agentpath:/path/to/libasyncProfiler.sh=start,event=cpu,event=alloc,file=out.jfr,...
As you've correctly guessed, this works only with JFR output.
For the feedback, comment the corresponding GitHub issue.
Since MariaDB 10.2.4 defaults is:
sql_mode = STRICT_TRANS_TABLES
and
innodb_strict_mode = ON
System requirements on https://get.typo3.org and in Installation guide do not explicitly mention it, but I know the restriction about not supporting strict mode got removed from the readme quite some time ago. I am not sure about innodb_strict_mode though.
Is there anything else to consider? What about third party extensions?
Resources:
Since MariaDB 10.2.4 defaults is:
sql_mode = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
https://mariadb.com/kb/en/sql-mode/
When this manual refers to “strict mode,” it means a mode with either or both STRICT_TRANS_TABLES or STRICT_ALL_TABLES enabled.
https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html
Since MariaDB 10.2.2
innodb_strict_mode = ON
InnoDB strict mode is similar to SQL strict mode. When it is enabled, certain InnoDB warnings become errors instead.
https://mariadb.com/kb/en/innodb-strict-mode/
This isn't intended as a full answer, but too long for a comment.
Had a lot of 3rd party EXT going haywire. It is often manageable if you install the extension anew, but upgrading an old install into an STRICT db resulted e.g. in just some views/subpages throwing exceptions while the rest of the system seemed to work.
You might spot a problematic extension due to the SQL definition making problems already (e.g. wrong default values), but that isn't a guarantee.
However sometimes specific queries cause problems as mentioned above. Most of the times however it is hacky SQL or using implicit type casts (especially date fields).
Checking an extension if its sql file would work and if it is using Doctrine throughout is a good indicator IMHO. But even for the rest nothing an acceptance regression test suite can't find, but some of the errors were such a PITA we disabled STRICT mode again.
Nevertheless: there is no reason not all extensions should allow strict mode.
According to the open docs, there are adverbs for reading, writing, and appending. That's fine and what I would expect. I have a particular application that uses sysopen for better control and I was trying to rewrite it in Perl 6. I know about NativeCall (as mentioned in my question about kill), but is there something builtin that I'm missing?
This is a case of incomplete documentation:
On MoarVM, open has supported the more common ones of the POSIX flags since 2015, including O_EXCL via the named parameter :exclusive.
The flag combination you're looking for is
my $fh = open "file", :mode<wo>, :create, :exclusive;
which can be written more compactly as
my $fh = open "file", :x;
This will hopefully be documented as part of the ongoing grant Standardization, Test Coverage, and Documentation of Perl 6 I/O Routines. For now, details can be found in the commit log. There have been some minor changes since then; in particular, :mode<pipe> has been removed and a JVM implemetation added (which however does not allow you to combine flags as freely as MoarVM does).
There are a lot of useful parameters (for example, changelogCatalogName) for Maven update task: http://www.liquibase.org/documentation/maven/maven_update.html
But they are not mentioned in CLI page for liquibase update: http://www.liquibase.org/documentation/command_line.html
Is it possible to pass these parameters?
Thanks!
You can also use liquibase --help to return command line options as well, there may be some on there that were missed in the docs.
I am working on improving consistency and feature parity between different ways to run Liquibase but there can still be some features that have not made it into all modes yet. ChangelogCatalogName and ChangelogSchemaName look like two fields that have not made it into CLI parameters yet, but you are able to specify them by system properties as -Dliquibase.catalogName=ABC and -Dliquibase.schemaName=XYZ