Is there a way to make RichEmbed methods work in Heroku? - heroku

When attempting to use this code I got the error below:
const embed = new RichEmbed();
var num = Math.floor(Math.random() * 10);
let name = part + num + ".gif";
embed.attachFiles([name]);
embed.setImage('attachment://' + name);
mess.channel.send(embed);
TypeError: embed.attachFiles is not a function
I if I delete away embed.attachFiles([name]) I get an error saying that embed.setImage isn't a function either.
Is there anything I can do to make Heroku register these as functions? It is worth noting that this worked outside of Heroku, when I ran it using the command line on my own computer.

Heroku by itself does not modify the behavior of discord.js. Here's a list of things you can try:
Verify that your package.json file is updated with the version of discord.js you want and run npm i to make sure the version on your pc is the same*.
Make sure that RichEmbed is Discord.RichEmbed: try to write it explicitly to see if that helps.
Try to console.log(embed) and see what gets logged in the console: that might give you a clue of what the problem is...
* The RichEmbed.attachFile() method was added in the 11.0.0 version: any previous version of discord.js won't allow you to use it.

Related

TypeError while instantiating Auth0Lock on yarn app

I have downloaded the official lock repo: https://github.com/auth0/lock
I run the examples and they all work fine.
When I try and run the same code inside my Yarn project like so:
const cid = 'redacted';
const domain = 'redacted.auth0.com';
const lock = new Auth0Lock(cid, domain);
lock.show();
I get the following error:
TypeError: l.setup is not a function
at setupLock (app-root.entry.js:38263:13)
at Auth0Lock.Base (app-root.entry.js:47258:37)
at new Auth0Lock (app-root.entry.js:47517:56)
at AppRoot.auth0Login (app-root.entry.js:49538:20)
at AppRoot.handleLoginEvent (app-root.entry.js:49531:10)
at HTMLDocument.<anonymous> (index-64bf1dc2.js:94:51)
There are no references to this error on the internet except this post from 2017:
https://github.com/rollup/rollup-plugin-node-resolve/issues/87
The reporter kylecombes made a fork with substantial changes to fix the issue, but that fork is now quite out-of-date.
Because the example code is so terse, I'm not sure what else to try. I am concerned that its a compatibility issue between Yarn and Auth0/lock. Their only examples are in webpack and browserfy.
Any help would be greatly appreciated.

go-swagger restapi/configure_todo_list.go - api.TodoGetHandler undefined error

I am a newbie in go and go-swagger. I am following steps in Simple Server tutorial in goswagger.io.
I am using Ubuntu 18.04, swagger v0.25.0 and go 1.15.6.
Following the same steps, there are a few differences of the files generated. For instance, goswagger.io's has find_todos_okbody.go and get_okbody.go in models but mine does not. Why is that so?
Link to screenshot of my generated files vs
Link to screenshot of generated files by swagger.io
Starting the server as written in the tutorial go install ./cmd/todo-list-server/ gives me the following error. Can anyone please help with this?
# my_folder/swagger-todo-list/restapi
restapi/configure_todo_list.go:41:8: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
restapi/configure_todo_list.go:42:6: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
The first step in goswagger.io todo-list is swagger init spec .... Which directory should I run this command in? I ran it in a newly created folder in my home directory. However, from the page, it shows the path to be ~/go/src/github.com/go-swagger/go-swagger/examples/tutorials/todo-list. I am not sure whether I should use go get ..., git clone ... or create those folders. Can someone advise me?
Thanks.
This is likely the documentation lagging behind the version of the code that you are running. As long as it compiles, the specific files the tool generates isn't so crucial.
This is a compilation error. When you do go install foo it will try to build the foo package as an executable and then move that to your GOPATH/bin directory. It seems that the generated code in restapi/configure_todo_list.go isn't correct for the operations code generated.
All you need to run this tutorial yourself is an empty directory and the swagger tool (not its source code). You run the commands from the root of this empty project. In order not to run into GOPATH problems I would initialise a module with go mod init todo-list-example before doing anything else.
Note that while the todo-list example code exists inside the go-swagger source, it's there just for documenting example usage and output.
What I would advice for #2 is to make sure you're using a properly released version of go-swagger, rather than installing from the latest commit (which happens when you just do a go get), as I have found that to be occasionally unstable.
Next, re-generate the entire server, but make sure you also regenerate restapi/configure_todo_list.go by passing --regenerate-configureapi to your swagger generate call. This file isn't always refreshed because you're meant to modify it to configure your app, and if you changed versions of the tool it may be different and incompatible.
If after that you still get the compilation error, it may be worth submitting a bug report at https://github.com/go-swagger/go-swagger/issues.
Thanks #EzequielMuns. The errors in #2 went away after I ran go get - u -f ./... as stated in
...
For this generation to compile you need to have some packages in your GOPATH:
* github.com/go-openapi/runtime
* github.com/jessevdk/go-flags
You can get these now with: go get -u -f ./...
I think it's an error of swagger code generation. You can do as folloing to fix this:
delete file configure_todo_list.go;
regenerate code.
# swagger generate server -A todo-list -f ./swagger.yml
Then, you can run command go install ./cmd/todo-list-server/, it will succeed.

How to reference script files in webpack deploy?

I am using webpack and electron and while I can reference my script files fine locally (app/scripts/scriptname.sh), when it comes to the production deploy, I get an error: Can't open app/components/scripts/scriptname.sh.
It's unclear to me if this is an electron-dependent issue or a webpack-issue.
I am running these using node child_process as:
var ls = spawn('sh', ['app/components/scripts/scriptname.sh']);
I don't necessarily need the scripts to be in their own folder it would just be helpful.
You need to provide the complete absolute path to the script. To do that you can use the app.getAppPath() API of electron
app.getAppPath()
Returns String - The current application directory.
So your code would be something like:
var scriptAbsolutePath = app.getAppPath() + '/app/components/scripts/scriptname.sh';
var ls = spawn('sh', [scriptAbsolutePath]);
You can also have a look at app.getPath(name) API if it satisfies your particular requirement.

Running gulp using Symfony Process results in command not found

I am trying to run gulp using envoy from a controller on a Laravel installation using Symfony Process to no luck. I keep getting an error back reading "The command "envoy" failed. Exit Code: 127(Command not found)". I have attached the code I am using below:
$process = new Process('envoy', base_path() . '/vendor/laravel/envoy');
$process->setTimeout(60);
$process->setIdleTimeout(60);
$process->setWorkingDirectory(base_path());
$process->run();
$process->start();
$process->wait();
if (!$process->isSuccessful()) {
throw new ProcessFailedException($process);
}
My question is, how come the command is being read as not found even though I am targeting it directly?
Thanks in advance for the help!
I believe you need to change this line like so:
$process = new Process('envoy vendor/laravel/envoy');
can you try it? Not certain it work, but I think it's something like that. Since you are using base_path(), I think it's pointing to a different directory than you expect.

what is the difference between stensi & WanWizard datamaper versions?

I've tried stensi but I see it has some mistakes and unexpected output as mentioned in the user guide.
For example, when trying to delete a record it gives this error:
$p=new Per();
$p->where('id',1)->get();
$p->delete();
with an error message of:
undefined index id
when
echo $p->UserName;
outputs:
mhmd
and WanWizard has also this error:
<h4>A PHP Error was encountered</h4>
<p>Severity: Warning</p>
<p>Message: array_key_exists() expects parameter 2 to be array, boolean given</p>
<p>Filename: libraries/datamapper.php</p>
<p>Line Number: 399</p>
How can I overcome these errors or what can I do to make it work properly?
I've changed the two lines of code at ../libraries/datamapper.php line 399 (WanWizard version):
$d = array($this->config->item('datamapper'));
DataMapper::$config = $d;
and the error message disappeared.
If anyone has tried DataMapper and has a better suggestion, please let us know.
just found out this error can occur if you autoload the datamapper config file
Stensi's original version hasn't been maintained since 2007, and only supports CI 1.4. Not really an option anymore these days. It was forked by Overzealous in 2008, and I took over maintenance of that fork in 2010.
I fixed this (in the CI spark version) by moving the config file from the sparks directory to the /application/config directory.
There's something strange happening in CI v2.1.4 where
$this->config->load('datamapper', TRUE, TRUE);
on line 391 of application/libraries/datamapper.php in Datamapper-ORM v1.8.2.1 isn't "namespacing" the config correctly. If you do
print_r ($this->config); die;
just after line 391, you'll see all of the config values are in the general CodeIgniter "namespace" inside the loaded config array. The least intrusive way to get around this is to manually namespace your application/config/datamapper.php file yourself, by changing all the references from
$config['prefix'] = '';
$config['join_prefix'] = '';
...
to
$config['datamapper']['prefix'] = '';
$config['datamapper']['join_prefix'] = '';
...
That's how I got around it. Though #Mhmdgomma's fix does work, I prefer not to hack the core of the system when there is a simpler solution available. Someone should probably get the maintainers to fix this, but I'm not sure where the issue lies. It looks more like it's a CI issue, rather than DM.

Resources