I have a question about Scalar DL.
How can I make sure that a scalardl environment works properly after setting up or modifying the environment?
You can use a read-only contract if you have one in your applications or you can use Scalar DL Explorer otherwise.
https://github.com/scalar-labs/scalardl-tools/tree/master/explorer
Related
I do not know where to even start, apologies for the noob question but seems there's nothing on this specific case in SO unless there's more generic terms I do not know.
Recent (like 5+ years or so), gperftools support environment variable that dumps used backtracing method. Set TCMALLOC_STACKTRACE_METHOD_VERBOSE to 1 and it'll show what it uses by default. You can also override used method via TCMALLOC_STACKTRACE_METHOD environment variable.
Another option is via package manager. On my debian system I see that libtcmalloc-minimal4 is linked without libunwind (as expected since it doesn't capture any backtraces), and libgoogle-perftool4 does depend in libunwind8. On debian and ubuntu you can see that by running apt-cache show .
As far as I know module attributes evaluated during compilation time. I was trying to follow this post about mocking API in Elixir:
defmodule Example.User do
#github_api Application.get_env(:example, :github_api)
def get(username) when is_binary(username) do
#github_api.make_request(:get, "/users/#{username}")
end
end
And I'm wondering if that's gonna work in production at all. As far as I understand when this module is compiled there's no access to the Application. So my question is: can I use module attributes to store some config values that come from Application.get_env?
You absolutely can. As long as the application was compiled using MIX_ENV specified to environment you want the application running under, and as long as that call evaluates to what you expect for that environment, it'll all work fine.
For a deeper look at how module attributes are affected by compilation for an almost identical case as what you've described, take a look at this blog post here.
In Bamboo, I want so take a build-release and deploy it on a target host. The target host should be variable.
As far as I know, it is not possible to run deployment-projects with customized deployment-variables (as it is possible to override plan-variables on custom-builds). My question is: is that true and if yes, what is the best way to achieve what I want?
Here are some thoughts I had during research regarding this issue:
I could use a plan-variable "host" in my build job and always customize it as needed. Then I write this variable into a file that will be declared as a build-artifact. In my deployment-tasks I use the "Inject Bamboo variables configuration" task to get the variable. This solution has the disadvantage, that I always have to run a build, even if the artifacts do not change.
Global variables are not feasible because they are not build-dependent. Therefore I can not use them for my task. The reason is that it could happen that they get overwritten by another build.
Are there any better solutions/thoughts on this task?
target host should be variable
No, each host is a separate environment. Otherwise the notion of "promoting an environment" breaks apart. This may be a lot of work to implement and therefore I strongly advise using bamboo specs (in Java).
it is not possible to run deployment-projects with customized deployment-variables
I confirm: it's not possible. And again, it would break the notion of environment promotion. Rule of thumb: your environment setup should be immutable: no variable variance. The only difference b/n runs is the artifacts that are to be deployed.
You can set variables in 'Other environment settings' in deployment project while configuring Environment. This way you will not have to run build when artifacts don't change. Just change variable value before deploying the artifact.
Say I have a variable named repo_path and I want to set some environmental variables or VM options based on this variable, such as SOME_VAR={$repo_path}/some_sub_path or -DsomeProperty={$repo_path} so that I don't have to type repo_path every time I use it. What is the correct way to achieve this other than typing the full address everywhere?
Why don't you define a regular system variable 'REPO_PATH' and use it in IntelliJ Run Configuration as a regular system variable :)
-DsomeProperty=$REPO_PATH
It works well under Mac OS, so I assume it will work under Ubuntu as well.
I'm getting confused of how to place an environmental variable in my head. So it's like a global variable for the operating system? So a global for an IDE is just a reference for something the IDE needs to be able to allocate. Is this the correct idea to have?
At execution each process has an image. It consists of a set of variables in memory that can be accessed, read and modified at all time. It defines the state of a process at a certain point in time.
Some of these variables are created by the process itself for its internal logic, and others will be inherited from its parent process (usually the shell that's used to launch it). They usually describe a certain state of the system. They are called the environment variables. You can use them to define stuff like:
- location of certain executables on your computers (like java or python).
- location of some shared libraries (or DLL if you're on Windows).
- location of the database you're querying
- permission and user access (although that's not the safest place to define it).
The point is, you can define anything in your environment, and every process launched with this environment will inherit from these variables.
I don't know what you mean with the IDE, and quite frankly am not sure I completely understood your question. But since it's been a while and no one answered, I'm hoping it could help you get a beginning of an answer.