I'm developing an extension to Frama-C, and I intend to create a configuration interface on it.
Is it possible to save states in Frama-C independently of Project or Session, i. e., save a configuration that will be loaded with every instance of it?
I tried with State_builder, but it seems the data is attached to a corresponding project.
If I understand correctly, you need the following three things:
the name of the configuration file, e.g. let config_file () = MyPlugin.Config.file ~error:false "my_plugin.conf". See documentation of module Config in plugin.mli and of module type Specific_dir in parameter_sig.mli.
A hook for loading the configuration after the plugin has been loaded: let () = Cmdline.run_after_extended (fun () -> load_config (config_file())). You might want to load the configuration at another stage of Frama-C boot process, as documented in cmdline.mli
A hook for saving the configuration when Frama-C exits: let () = Cmdline.at_normal_exit (fun () -> save_config (config_file())
There is an old mechanism, inherited from Cil and used by the GUI to read and write formatted configuration files, found in cilconfig.mli, but basically your plugin can choose any format for its own configuration.
Related
How do I register a custom protocol with Windows so that when clicking a link in an email or on a web page my application is opened and the parameters from the URL are passed to it?
Go to Start then in Find type regedit -> it should open Registry editor
Click Right Mouse on HKEY_CLASSES_ROOT then New -> Key
In the Key give the lowercase name by which you want urls to be called (in my case it will be testus://sdfsdfsdf) then Click Right Mouse on testus -> then New -> String Value and add URL Protocol without value.
Then add more entries like you did with protocol ( Right Mouse New -> Key ) and create hierarchy like testus -> shell -> open -> command and inside command change (Default) to the path where .exe you want to launch is, if you want to pass parameters to your exe then wrap path to exe in "" and add "%1" to look like: "c:\testing\test.exe" "%1"
To test if it works go to Internet Explorer (not Chrome or Firefox) and enter testus:have_you_seen_this_man this should fire your .exe (give you some prompts that you want to do this - say Yes) and pass into args testus://have_you_seen_this_man.
Here's sample console app to test:
using System;
namespace Testing
{
class Program
{
static void Main(string[] args)
{
if (args!= null && args.Length > 0)
Console.WriteLine(args[0]);
Console.ReadKey();
}
}
}
Hope this saves you some time.
The MSDN link is nice, but the security information there isn't complete. The handler registration should contain "%1", not %1. This is a security measure, because some URL sources incorrectly decode %20 before invoking your custom protocol handler.
PS. You'll get the entire URL, not just the URL parameters. But the URL might be subject to some mistreatment, besides the already mentioned %20->space conversion. It helps to be conservative in your URL syntax design. Don't throw in random // or you'll get into the mess that file:// is.
If anyone wants a .reg file for creating the association, see below:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\duck]
"URL Protocol"=""
[HKEY_CLASSES_ROOT\duck\shell]
[HKEY_CLASSES_ROOT\duck\shell\open]
[HKEY_CLASSES_ROOT\duck\shell\open\command]
#="\"C:\\Users\\duck\\source\\repos\\ConsoleApp1\\ConsoleApp1\\bin\\Debug\\net6.0\\ConsoleApp1.exe\" \"%1\""
Pasted that into notepad, the file -> save as -> duck.reg, and then run it. After running it, when you type duck://arg-here into chrome, ConsoleApp1.exe will run with "arg-here" as an argument. Double slashes are required for the path to the exe and double quotes must be escaped.
Tested and working on Windows 11 with Edge (the chrome version) and Chrome
There is an npm module for this purpose.
link :https://www.npmjs.com/package/protocol-registry
So to do this in nodejs you just need to run the code below:
First Install it
npm i protocol-registry
Then use the code below to register you entry file.
const path = require('path');
const ProtocolRegistry = require('protocol-registry');
console.log('Registering...');
// Registers the Protocol
ProtocolRegistry.register({
protocol: 'testproto', // sets protocol for your command , testproto://**
command: `node ${path.join(__dirname, './index.js')} $_URL_`, // $_URL_ will the replaces by the url used to initiate it
override: true, // Use this with caution as it will destroy all previous Registrations on this protocol
terminal: true, // Use this to run your command inside a terminal
script: false
}).then(async () => {
console.log('Successfully registered');
});
Then suppose someone opens testproto://test
then a new terminal will be launched executing :
node yourapp/index.js testproto://test
It also supports all other operating system.
I'm using hydra to log hyperparameters of experiments.
#hydra.main(config_name="config", config_path="../conf")
def evaluate_experiment(cfg: DictConfig) -> None:
print(OmegaConf.to_yaml(cfg))
...
Sometimes I want to do a dry run to check something. For this I don't need any saved parameters, so I'm wondering how I can disable the savings to the filesystem completely in this case?
The answer from Omry Yadan works well if you want to solve this using the CLI. However, you can also add these flags to your config file such that you don't have to type them every time you run your script. If you want to go this route, make sure you add the following items in your root config file:
defaults:
- _self_
- override hydra/hydra_logging: disabled
- override hydra/job_logging: disabled
hydra:
output_subdir: null
run:
dir: .
There is an enhancement request aimed at Hydra 1.1 to support disabling working directory management.
Working directory management is doing many things:
Creating a working directory for the run
Changing the working directory to the created dir.
There are other related features:
Saving log files
Saving files like config.yaml and hydra.yaml into .hydra in the working directory.
Different features has different ways to disable them:
To prevent the creation of a working directory, you can override hydra.run.dir to ..
To prevent saving the files into .hydra, override hydra.output_subdir to null.
To prevent the creation of logging files, you can disable logging output of hydra/hydra_logging and hydra/job_logging, see this.
A complete example might look like:
$ python foo.py hydra.run.dir=. hydra.output_subdir=null hydra/job_logging=disabled hydra/hydra_logging=disabled
Note that as always you can also override those config values through your config file.
I'm trying to set an environment variable for an API key that I don't want in my code. My source javascript looks something like this :
.get(`http://api-url-and-parameters&api-key=${process.env.API_KEY}`)
I'm using webpack and the package dotenv-webpack https://www.npmjs.com/package/dotenv-webpack to set API_KEY in a gitignored .env file and it's all running fine on my local. I'd like to also be able to set that variable when deploying through Netlify, I've tried adding it through to GUI to the 'build environment variables', and also to set it directly in the build command, but without success.
Any idea what might be the issue ?
WARNING: If this is a secret key, you will not want to expose this environment variable value in any bundle that gets returned to the client. It should only be used by your build scripts to be used to create your content during build.
Issue
dotenv-webpack expects there to be a .env file to load in your variables during the webpack build of your bundle. When the repository is checked out by Netlify, the .env does not exist because for good reason it is in .gitignore.
Solution
Store your API_KEY in the Netlify build environment variables and build the .env using a script prior to running the build command.
scripts/create-env.js
const fs = require('fs')
fs.writeFileSync('./.env', `API_KEY=${process.env.API_KEY}\n`)
Run the script as part of your build
node ./scripts/create-env.js && <your_existing_webpack_build_command>
Caveats & Recommendations
Do not use this method with a public facing repository [open] because any PR or branch deploy could create a simple script into your code to expose the API_KEY
The example script above is for simplicity so, make any script you use be able to error out with a code other than 0 so if the script fails the deploy will fail.
You can set Dotenv-webpack to load system environment variables as well as those you have declared in your .env file by doing the following:
plugins: [
new Dotenv({
systemvars: true
})
]
I.e Setting the systemvars attribute of your webpack dotenv plugin to true.
Note that system environment variables with the same name will overwrite those defined in your .env file.
Source: https://www.npmjs.com/package/dotenv-webpack#properties
if you go to corresponding site's settings in Netlify, under build&deploy you can find a section called environment variables you can easily add your environment variables from there. if you add MY_API_KEY variable to environment variables you will be able to access it inside your project via process.env.MY_API_KEY.
If you're using Nuxt JS there is a more "straight forward" approach.
Just edit the nuxt.config.js like so:
module.exports = {
env: {
GOOGLE_API_KEY: process.env.GOOGLE_API_KEY
},
// ...
Then add the GOOGLE_API_KEY to Netlify through the build environment variables as usual.
Credit goes to yann-linn and his answer on github.
What you can also do is also to define a global constant in Webpack. Netlify environment variables defined in UI will work with it. You don't need dotenv or dotenv-webpack.
webpack.config.js
const webpack = require("webpack");
module.exports = {
plugins: [
new webpack.DefinePlugin({
"process.env.API_KEY": JSON.stringify(process.env.API_KEY)
}),
]
}
However again, of course you shouldn't do it just inputting enviornmental variables in the frontend if your API key is confidential and project public. The API key will appear in the source code of the website and will be easily accessible for everyone visiting it. Lambda function would be a better option.
You can use the Netlify's config file also ...
You can find documentation here.
Also i wanted to have the same ENV variables with with different values per branch/environment.
This workaround worked for me:
Create a netlify.toml file like:
[build]
NUXT_ENV_BASE_API = "/api"
NUXT_ENV_HOST_DOMAIN = "https://your-domain.gr"
[context.branch-deploy]
environment = { NUXT_ENV_BASE_API = "/dev-api", NUXT_ENV_HOST_DOMAIN = "https://dev.your-domain.gr" }
[context.production]
environment = { NUXT_ENV_BASE_API = "/api", NUXT_ENV_HOST_DOMAIN = "https://your-domain.gr" }
And deploy in Netlify ...
I want to produce different log configuration for my stage app and on the tarball that I'd use to distribute my application
I have a task to generate the configuration and want it to be called with different parameters on doing stage and packageZipTar. This is my config
mappings in Universal in stage += {
val f = generateLoggingConfigTask(LogType.ConsoleAndFiles).value
f -> ("conf/" + f.getName)
},
mappings in Universal in packageZipTarball += {
val f = generateLoggingConfigTask(LogType.Files).value
f -> ("conf/" + f.getName)
},
The first task fires only when doing stage but on packageZipTarball I get both tasks running, furthermore they run in an unpredictable order so sometimes I have one config sometimes another
Any hints on how to proceed?
The issue is that packageZipTarball depends on stage, which is how native-packager works. stage always creates a "ready to build" directory, which the packaging format uses to create the package. Diverging these two, would be confusing and inconsistent with native-packagers behavior.
I would recommend one of the following options
1. Create your app with stage and pass the configuration explicitly with a cli parameter
2. Create a bash script that adds the logging configuration parameter explicitly and you call this to start your app
Can anyone tell me why the code below throws the following error? :
Error: A method named '/players/insert' is already defined
I'm new to Meteor and coffeescript so I may be overlooking something simple.
Here's my port of the leaderboard example to coffeescript:
###
Set up a collection to contain player information. On the server,
it is backed by a MongoDB collection named "players."
###
Players = new Meteor.Collection("players")
if Meteor.is_client
Template.leaderboard.players = ->
Players.find({}, {sort: {score: -1, name: 1}})
Template.leaderboard.selected_name = ->
player = Players.findOne(Session.get "selected_player")
player and player.name
Template.player.selected = -> if Session.equals("selected_player", this._id) then "selected" else ''
Template.leaderboard.events = {
'click input.inc': ->
Players.update(Session.get("selected_player"), {$inc: {score: 5}})
}
Template.player.events = {
'click': ->
Session.set("selected_player", this._id)
}
# On server startup, create some players if the database is empty.
if Meteor.is_server
Meteor.startup ->
if Players.find().count() is 0
names = [
"Ada Lovelace"
"Grace Hopper"
"Marie Curie"
"Carl Friedrich Gauss"
"Nikola Tesla"
"Claude Shannon"
]
Players.insert({name: name, score: Math.floor(Math.random()*10)*5}) for name in names
The full stack trace is as follows:
[[[[[ ~/dev/meteor/leaderboard ]]]]]
Running on: http://localhost:3000/
node.js:201
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: A method named '/players/insert' is already defined
at app/packages/livedata/livedata_server.js:744:15
at Function.<anonymous> (app/packages/underscore/underscore.js:84:24)
at [object Object].methods (app/packages/livedata/livedata_server.js:742:7)
at new <anonymous> (app/packages/mongo-livedata/collection.js:111:13)
at app/leaderboard.js:4:11
at /Users/alex/dev/meteor/leaderboard/.meteor/local/build/server/server.js:109:21
at Array.forEach (native)
at Function.<anonymous> (/Users/alex/dev/meteor/leaderboard/.meteor/local/build/server/underscore.js:76:11)
at /Users/alex/dev/meteor/leaderboard/.meteor/local/build/server/server.js:95:7
Exited with code: 1
I'm running Meteor version 0.4.0 (8f4045c1b9)
Thanks in advance for assistance!
You would also get this error, regardless of using coffeescript or plain javascript, if you duplicated your files. For example, copying your sources files to a subdirectory named Backup would produce this error, because Meteor merges files from subdirectories.
This appears to be a configuration issue with coffeelint (installed globally with npm).
I originally installed coffeelint to check that my coffeescript code was correct and had no errors.
I installed coffeelint as per the instructions with:
sudo npm install -g coffeelint
coffeelint worked fine when run stand-alone against .coffee files.
However, when running any Meteor project with coffeescript package added I got the above error.
On a whim, I thought the error might be due to conflict with my exisiting node install.
I decided to uninstall coffeelint first with:
sudo npm uninstall -g coffeelint
and then deleted the previously meteor-generated leaderboard.js file.
After re-starting meteor the coffeescript example above worked as expected without errors.
try moving (ie copying and deleting the original )
Players = new Meteor.Collection("players")
one time below if Meteor.is_client
and another time below if Meteor.is_server
I don't know exactly why, as I'm new to Meteor too, but that worked for me, I assume that the server side needs it's own reference,as well as the client,
although declaring outside the scope should do the same (maybe a bug, remember they're still at 0.5.0 preview , which makes me think you might wanna upgrade and try some new smart packages that are with the new version, it looks like you're using 0.4), but when the files in my server wouldn't recognize anything I defined the root directory of meteor (which pushes these files to both client and server), I defined the server's own reference, and I got the same error, and until I moved the 'public' declaration of the reference to give the server and the client each their own copy, nothing worked.
Hopefully that helps...