I am here because I am trying to use Couchbeam form my page on a YAWS.
I have tested CB and it worked correctly from Terminal, using:
erl -pa ebin -pa deps/ibrowse/ebin -s couchbeam
Now I am trying to replicate what I did locally on my webpage.
I believe the issue is that I don't know how to tell erl to do 'erl -pa ebin -pa deps/ibrowse/ebin -s couchbeam' from a yaws page.
I have tried to simply running all the needed apps, but I am getting this:
Stack: [{ibrowse_lib,url_encode,["test"],[]},
{couchbeam,save_doc,3,[{file,"src/couchbeam.erl"},{line,383}]},
{m50,out,1,
[{file,"/Users/Nesh/.yaws/yaws/default/m50.erl"},{line,35}]},
{yaws_server,deliver_dyn_part,8,
[{file,"yaws_server.erl"},{line,2647}]},
{yaws_server,aloop,4,[{file,"yaws_server.erl"},{line,1152}]},
{yaws_server,acceptor0,2,[{file,"yaws_server.erl"},{line,1013}]},
{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]
This is my erl code:
<erl>
startApp() ->
application:start(crypto),
application:start(private_key),
application:start(ssl),
application:start(sasl),
application:start(ibrowse),
application:start(couchbeam).
out(Arg) ->
startApp(),
Host = "localhost",
Port = 5984,
Prefix = "",
Options = [],
S = couchbeam:server_connection(Host, Port, Prefix, Options),
Options = [],{ok, Db} = couchbeam:open_db(S, "erlang", Options),
Doc = {[{<<"_id">>, <<"test">>},{<<"content">>, <<"web text">>}]},
{ok, Doc1} = couchbeam:save_doc(Db, Doc).
</erl>
I wouldn't recommend running Couchbeam from within a .yaws page like this. You should instead either create an Erlang release such that Couchbeam and Yaws are both executed within the same Erlang VM and then use a Yaws appmod to call into Couchbeam, or maybe you should consider making Couchbeam a bootstrap yapp for Yaws.
If you really think you're having load path problems, you can specify load paths in the yaws.conf file via the ebin_dir directive. For example:
ebin_dir = deps/ibrowse/bin
ebin_dir = couchbeam/ebin
But the stack trace you show seems like it's missing something, so it's hard to tell you exactly what's wrong.
I managed to fix it doing this:
I've added these lines in yaws.conf:
ebin_dir = /usr/local/var/yaws/couchbeam/deps/ibrowse/ebin
ebin_dir = /usr/local/var/yaws/couchbeam/deps/jiffy/ebin
ebin_dir = /usr/local/var/yaws/couchbeam/deps/mochiweb/ebin
ebin_dir = /usr/local/var/yaws/couchbeam/ebin
Note: I put the folder 'couchbeam' in /usr/local/var/yaws/
then I modified the code in this way:
load_deps() ->
application:start(sasl),
application:start(ibrowse),
application:start(jiffy),
application:start(inets),
application:start(xmerl),
application:start(compiler),
application:start(syntax_tools),
application:start(mochiweb),
application:start(couchbeam).
out(Arg) ->
load_deps(),
Host = "localhost",
Port = 5984,
Prefix = "",
Options = [],
S = couchbeam:server_connection(Host, Port, Prefix, Options),
Options = [],{ok, Db} = couchbeam:open_db(S, "erlang", Options),
Doc = {[{<<"content">>, <<"Checking webpage">>}]},
{ok, Doc1} = couchbeam:save_doc(Db, Doc),
{html, "Document has been added"}.
</erl>
Related
I ran into a problem while writing an extension for Visual Studio Code!
I keep getting messages like this "Cannot read properties of undefined (reading 'uri')", etc.
const defaultCompiler = 'g++';
// define the command for compiling C++ code with each compiler
const compilerCommands = {
'g++': 'g++ -S -o "{oFile}" "{cFile}"',
'clang++': 'clang++ -S -o "{oFile}" "{cFile}"'
};
let currentlyOpenFilePath = vscode.window.activeTextEditor;
// let curDir = vscode.workspace.workspaceFolders[0].uri.path
let cFile = currentlyOpenFilePath.document.uri.path;
let dirPath = path.dirname(cFile);
let oFile = path.join(dirPath, 'output.s');
let command = compilerCommands[this.currentCompiler].replace('{cFile}', currentlyOpenFilePath).replace('{oFile}', oFile);
I surfed all over Google in search of a solution to the problem, but everything I found did not help me. I tried various combinations in variables currentlyOpenFilePath, curDir, cFile (currently open file), dirPath, oFile.
My system is MacOS and also needs to work on Windows.
And also the extension is local (the previous version of the code took the path not of the current open file, but the path to the extension)
I need this plugin, when called, to successfully process the command "g++ -S -o {oFile} {cFile}" or "clang++ -S -o {oFile} {cFile}" by changing {cFile} to the current path to the open .cpp file in editor a in {oFile}, same path as {cFile} but saved as output.s
let workspacePath = '';
if (vscode.workspace.workspaceFolders?.length) {
workspacePath = workspace.workspaceFolders[0].uri.fsPath;
workspacePath = path.normalize(workspacePath);
}
Try to see if it's what you want
I'm a bit stuck with my server deployment recipes...
So far, I can create and provision my servers via commandline:
First I run salt-cloud and afterwards I provision it via salt-ssh...
But since I'm using some special ports (https,...) I also have to set/open input/endpoints (=ports) on Microsoft Azure.
This is where I stuck: is there any way of telling salt-cloud, to automatically execute a script, which opens the endpoints automatically?
My preferred result would be:
run salt-cloud => sets up new machine and opens all necessary ports
run salt-ssh to provision them
I have already looked at salt orchestration, but it looks like it's more for server fleets, instead of single (external) server configuration.
Any hints?
You could write a custom bootstrap script that would open the ports that you want.
As Utah_Dave said, I wrote a ruby script to add the ports...
# ruby
# execute with ruby startscript.rb
require 'json'
PROVIDER = "yourprovider"
SERVER = "yourserver"
ENDPOINTS = {
"SSH2" => 17532,
"HTTPS" => 443,
"HTTP" => 80,
"SlangerHTTP" => 8080,
"Slanger" => 4567,
"CouchDB" => 5984
}
def get_missing
service_existing = false
while !service_existing
begin
res = `salt-cloud --out=json -f list_input_endpoints #{PROVIDER} deployment=#{SERVER} service=#{SERVER}`
result = JSON.parse(res)
service_existing = true
rescue => e
puts e
end
end
existing_services = result[PROVIDER]["azure"].keys
missung_services = ENDPOINTS.keys - existing_services
end
missung_services = get_missing
while missung_services.any?
print "#{Time.now} [#{SERVER}] Services missing: #{missung_services.join(", ")}"
missung_services.each do |m|
print "."
`salt-cloud --out=json -f add_input_endpoint #{PROVIDER} name=#{m} port=#{ENDPOINTS[m]} protocol=tcp deployment=#{SERVER} service=#{SERVER} role=#{SERVER}`
end
print "\n"
missung_services = get_missing
end
I want to use an yeoman generator inside a NodeJS project
I installed yeoman-generatorand generator-git (the generator that I want use) as locally dependency, and, at this moment my code is like this:
var env = require('yeoman-generator')();
var path = require('path');
var gitGenerator = require('generator-git');
var workingDirectory = path.join(process.cwd(), 'install_here/');
generator = env.create(gitGenerator);
obviously the last line doesn't work and doesn't generate the scaffold.
The question: How to?
Importantly, I want to stay in local dependency level!
#simon-boudrias's solution does work, but after I changed the process.chdir(), this.templatePath() and this.destinationPath() returns same path.
I could have use this.sourcePath() to tweak the template path, but having to change this to each yeoman generator is not so useful. After digging to yo-cli, I found the following works without affecting the path.
var env = require('yeoman-environment').createEnv();
env.lookup(function() {
env.run('generator-name');
});
env.create() only instantiate a generator - it doesn't run it.
To run it, you could call generator.run(). But that's not ideal.
The best way IMO would be this way:
var path = require('path');
var env = require('yeoman-generator')();
var gitGenerator = require('generator-git');
// Optionnal: look every generator in your system. That'll allow composition if needed:
// env.lookup();
env.registerStub(gitGenerator, 'git:app');
env.run('git:app');
If necessary, make sure to process.chdir() in the right directory before launching your generator.
Relevant documentation on the Yeoman Environment class can be found here: http://yeoman.io/environment/Environment.html
Also see: http://yeoman.io/authoring/integrating-yeoman.html
The yeoman-test module is also very useful if you want to pass predefined answers to your prompts. This worked for me.
var yeomanTest = require('yeoman-test');
var answers = require('from/some/file.json');
var context = yeomanTest.run(path.resolve('path/to/generator'));
context.settings.tmpdir = false; // don't run in tempdir
context.withGenerators([
'paths/to/subgenerators',
'more/of/them'
])
.withOptions({ // execute with options
'skip-install': true,
'skip-sdk': true
})
.withPrompts(answers) // answer prompts
.on('end', function () {
// do some stuff here
});
I've just started writing my first app with NodeJS and I must say it's a pleasure learning how to work with :)
I've reached the point where I'm making some configuration before starting the server, and I would like to load the config from a config.json file.
I have found a few ways so far, either request that json file and leaver node require parse it, use a config.js file and export my config, use nconf, which seems pretty easy to use, or the last option I've seen is using optimist which I thought it would be better than ncond. Though I'm starting to think that the latter, optimist, can only be used for parsing arguments from the node cli.
So I'm asking here, can I use node optimist to get my config from a file, or, if not, should I use nconf ? Or maybe, there's something even better and lightweight out there that I don't know of ? (my options at this point are pretty vague, since I'm not sure if at some point I would like to parse any config from the cli).
I use a config.js file like this:
var config = {}
config.web = {};
config.debug = {};
config.server_name = 'MyServerName';
config.web.port = process.env.WEB_PORT || 32768;
config.debug.verbositylevel = 3;
module.exports = config;
then i can just call config variables like this:
var port = config.web.port;
I find it much easier to maintain like this. Hope that helps you.
I use dotenv. It's as easy as:
var dotenv = require('dotenv');
dotenv.load();
Then you just create a .env file with your configuration settings.
S3_BUCKET=YOURS3BUCKET
SECRET_KEY=YOURSECRETKEYGOESHERE
Disclaimer: I'm the creator, and didn't find the config.json file approach useful in production environments. I prefer getting configuration from my environment variables.
6 years later and the answer should have been: Use Nconf. it's awesome.
//
// yourrepo/src/options.js
//
const nconf = require('nconf');
// the order is important
// from top to bottom, a value is
// only stored if it isn't found
// in the preceding store.
// env values win all the time
// but only if the are prefixed with our appname ;)
nconf.env({
separator: '__',
match: /^YOURAPPNAME__/,
lowerCase: true,
parseValues: true,
transform(obj) {
obj.key.replace(/^YOURAPPNAME__/, '');
return obj;
},
});
// if it's not in env but it's here in argv, then it wins
// note this is just passed through to [yargs](https://github.com/yargs/yargs)
nconf.argv({
port: {
type: 'number'
},
})
// if you have a file somewhere up the tree called .yourappnamerc
// and it has the json key of port... then it wins over the default below.
nconf.file({
file: '.yourappnamerc'
search: true
})
// still not found, then we use the default.
nconf.defaults({
port: 3000
})
module.exports = nconf.get();
then in any other file
const options = require('./options');
console.log(`PORT: ${options.port}`);
now you can run your project like :
$ yarn start
# prints PORT: 3000
$ YOURAPPNAME__PORT=1337 yarn start
# prints PORT: 1337
$ yarn start --port=8000
# prints PORT: 8000
$ echo '{ "port": 10000 }' > .yourappnamerc
$ yarn start
# prints PORT: 10000
and if you forget what options you have
$ yarn start --help
# prints out all the options
Currently, I have several "environments" which are loaded using NODE_ENV
(I'm using RailwayJS / express)
development.js
app.set('mongodb_connection_string', 'mongodb://localhost/') // example
production.js:
app.set('mongodb_connection_string', process.env.MONGOLAB_URI)
So, in production, we're using the MONGOLAB_URI variable set within heroku.
Just wondering if there's a better way of managing these, without having to double up, and set app.set('mongodb_connection_string') ??
I use this really tiny module for that. It's written in coffee-script if you can't read it let me know and I'll translate it:
extend = (source, replacement)->
for k, v of replacement
source[k] = v
source
module.exports =
create: ->
env_settings = this[process.env.NODE_ENV]
extend this.general, env_settings
This allows me to write the following settings:
settings = require 'square-settings'
settings.general =
domain: '0.0.0.0:3000'
settings.production =
domain: 'www.somewhere.com'
module.exports = settings.create()
Everything in settings.general are the default settings. I can overwrite it for each environment by adding settings.environment.