Given a changeBlock that introduce a change to the Pharo Environment (such as loading a configuration, slice or changeset).
Example code:
oldEnvironment := Environment current serialize.
changeBlock value.
diff := oldEnvironment difference: Environment current
How can I record reliably the added/removed of all packages, classes and methods?
How can I properly serialize the packages/classes/methods?
Having the names of each unit is enough.
Related
We are using the roles pattern in puppet with hiera, meaning we have these lines in hiera.yaml:
- name: "Roles data"
path: "roles/%{::server_role}.yaml"
We have a custom fact that produces the role name when facter runs, but we would like to move this into hiera. Instead of the server_role variable being produced by facter, we want to specify the server_role inside of hiera, and let that variable be referenced elsewhere in hiera. Something like this:
hiera.yaml:
- name: "Per-node data"
path: "nodes/%{trusted.certname}.yaml"
- name: "Roles data"
path: "roles/%{lookup(server_role)}.yaml"
nodes/hostname.yaml:
server_role: foo_bar
I have seen this question, which says to use hiera() or lookup() but when I try to use those, I get this error message:
Interpolation using method syntax is not allowed in this context
So how can I use a hiera variable that's defined elsewhere in hiera?
Edit:
The prototypical code examples for defining roles could use any fact that's known to facter, often giving examples that are based on hostname. When you can't embed server config into hostname, a common(ish) workaround is to write a file such as /etc/server_role, but it seems to defeat the purpose of config management, when you need to ssh into a machine and edit a file. As the other comments & answer here so far mentioned, you could use an ENC, but again, the goal here is not to have config stored outside of version control. In fact, we have foreman as an ENC and we make a practice to never use it that way because then upgrades and other maintenance become unsustainable.
We could write a class which will pick up data from hiera, write it to /etc/server_role, and on the next puppet run, facter will pick that up and send it back to hiera, so then we'll have the server_role fact available to use in hiera.yaml. As gross as this sounds, so far, it's the best known solution. Still looking for better answers to this question.
Thanks.
As #MattSchuchard explained in comments, you cannot interpolate Hiera data into your Hiera config, because the config has to be known before the data can be looked up.
If you need a per-role level in your data hierarchy then an alternative would be to assign roles to machines via an external node classifier. You don't need it to assign any classes, just the server_role top-scope variable and probably also environment.
On the other hand, maybe you don't need a per-role level of your general hierarchy in the first place. Lots of people do roles & profiles without per-role data, but even if you don't want to do altogether without then it may be that module-specific data inside the module providing your role classes could be made to suffice.
The default cache directory is lack of disk capacity, I need change the configure of the default cache directory.
You can specify the cache directory everytime you load a model with .from_pretrained by the setting the parameter cache_dir. You can define a default location by exporting an environment variable TRANSFORMERS_CACHE everytime before you use (i.e. before importing it!) the library).
Example for python:
import os
os.environ['TRANSFORMERS_CACHE'] = '/blabla/cache/'
Example for bash:
export TRANSFORMERS_CACHE=/blabla/cache/
As #cronoik mentioned, alternative to modify the cache path in the terminal, you can modify the cache directory directly in your code. I will just provide you with the actual code if you are having any difficulty looking it up on HuggingFace:
tokenizer = AutoTokenizer.from_pretrained("roberta-base", cache_dir="new_cache_dir/")
model = AutoModelForMaskedLM.from_pretrained("roberta-base", cache_dir="new_cache_dir/")
I'm writing this answer because there are other Hugging Face cache directories that also eat space in the home directory besides the model cache and the previous answers and comments did not make this clear.
The Transformers documentation describes how the default cache directory is determined:
Cache setup
Pretrained models are downloaded and locally cached at: ~/.cache/huggingface/transformers/. This is the default directory given by the shell environment variable TRANSFORMERS_CACHE. On Windows, the default directory is given by C:\Users\username.cache\huggingface\transformers. You can change the shell environment variables shown below - in order of priority - to specify a different cache directory:
Shell environment variable (default): TRANSFORMERS_CACHE.
Shell environment variable: HF_HOME + transformers/.
Shell environment variable: XDG_CACHE_HOME + /huggingface/transformers.
What this piece of documentation doesn't explicitly mention is that HF_HOME defaults to $XDG_CACHE_HOME/huggingface and is used for other huggingface caches, e.g. the datasets cache, which is separate from the transformers cache. The value of XDG_CACHE_HOME is machine dependent, but usually it is $HOME/.cache (and HF defaults to this value if XDG_CACHE_HOME is not set) - thus the usual default $HOME/.cache/huggingface
So you probably will want to set the HF_HOME environment variable (and possibly set a symlink to catch cases where the environment variable is not set).
export HF_HOME=/path/to/cache/directory
This environment variable is also respected by Hugging Face datasets library, although the documentation does not explicitly state this.
part question. First, how do I configure the size of a branch predictor?
I can see that I can set the type using the se.py config script and the --bp-type argument. (In my case I'm setting it to LTAGE), but how do I change the size of the tables? And is there an easy way to see the total size of all tables?
My second part, is looking at the code, I don't understand the LTAGE constructor:
LTAGE::LTAGE(const LTAGEParams *params)
: TAGE(params), loopPredictor(params->loop_predictor)
{
}
The LTAGEParams doesn't appear to be defined anywhere except here:
LTAGE*
LTAGEParams::create()
{
return new LTAGE(this);
}
How can I see what all the members of LTAGEParams are?
About the size, have a look at m5out/config.ini after running a simulation, it contains all SimObject parameters.
In the case of branch predictors, all Python-visible parameters of each implemented predictor will be defined in its respective class declaration at src/cpu/pred/BranchPredictor.py. They also inherit the parameters of their base class. For example, LTAGE has all the parameters of the TAGE class - out of which the tage object is re-assigned to be an instance of LTAGE_TAGE - and a new parameter, loop_predictor, which is a LoopPredictor instance.
You can then just set any of the values in that file from your Python config and they will be used (double check in config.ini after re-running).
The C++ constructor of SimObjects takes a param object like LTAGEParams and that object is autogenerated from the corresponding Python SimObject file, and passes values from Python configs to C++ using pybind11.
gem5 has a lot of code generation, so whenever you can't find a definition, grep inside the build directory. This is also why I recommend setting up Eclipse inside the build directory: How to setup Eclipse IDE for gem5 development?
SimObject autogeneration is described further at: https://cirosantilli.com/linux-kernel-module-cheat/#gem5-python-c-interaction
I have installed Java through some cookbook and have set some default variables, now I want to add some more variables (Application specific) through my cookbook. How can I do that through Recipes in Chef. I tried to pass some variables in setenv.sh but it is overriding the default values instead I want to merge the variables and override existing variable values.
My code in setenv.sh:
export JAVA_OPTS="$JAVA_OPTS -Xmx2048m"
where $JAVA_OPTS - default variables
First way to do it would be to update the attribute defining the bases values in your application cookbook, as the attributes are read before the recipes are evaluated your file would end up with the correct values.
You're not saying with which cookbook you're using so I'll base the example on the tomcat cookbook
This cookbook define an attribute default['tomcat']['java_options'] = '-Xmx128M -Djava.awt.headless=true'
The easiest way it to complement this by using something like
default['tomcat']['java_options'] = "#{default['tomcat']['java_options']} -Xmx2048m"
The obvious problem is that you end up with 2 -Xmx values, usually the JVM will take the latest but it become hard to find what options is at which value when there's a lot of overwriting.
Second option is to take advantage of jvmargs cookbook wich gives helpers functions to deine the java options and use in your setenv.sh template at end.
Context
I'm building my complete debian system configuration,
so I'm modifying the keyboard and console setups.
I prefer not to modify the base files to keep a maximum
commpatibility and modularity. So I want to use VARIANT
(see setupcon (5)) and load them at init.
But not sure I'm doing it right.
Desired Architecture
I will only use keyboard file for the following example.
There is the base file /etc/default/keyboard
And two possible custom files (according to setupcon (5))
~/.keyboard
/etc/default/keyboard.variant
~/.keyboard
It provides a custom behaviour per $HOME (user)
/etc/default/keyboard.variant
A global and default keyboard setup
I would like to use the three at a time.
Problem
The daemon calling setupcon are console-setup and console-setup-mini
(according to the coments in their initd scripts). They are started
before login shell, so won't know ~/.keyboard.
setupcon needs to be called
setupcon variant
or, looking at the sources, with a variable $VARIANT
VARIANT=variant
What is the best solution to adopt, saving a maximum modularity.
Thank you,