Basically, I've been developing a bot for several weeks now using the discord.js library and recently encountered a small but crucial issue. Essentially when I declare my argument, I also made it so that the message content (message.content) would be capitalized using .toUpperCase(). Essentially in doing so regardless of the type of prefix you would enter (symbol wise) it would all be read by the program as valid.
For example only: !help - should work, however if I would enter .help, it would also be read as valid.
In any case, here's the code. I appreciate all the help!
bot.on('message', message =>{
let args = message.content.toUpperCase().substring(PREFIX.length).split(" ");
const sender = message.member;
switch(args[0])
{
case 'HELP':
message.reply("I've sent you some documentation on all the commands that you can use...").then(d_msg => {d_msg.delete(3000); });
message.delete(3000);
const attachment = new Attachment('./UtilityBot_Documentation.txt')
message.author.send('[Education] Bot - Documentation');
message.author.send(attachment);
break;
}
})
The discord.js tutorial covers an extremely similar problem to what you're trying to do. I recommend you check it out. The page I linked in specific is doing a very similar thing to you, but it's worth giving the whole thing a read through if you haven't done so already. In general, I would include the following line just above where you established args.
if (!message.content.startsWith(PREFIX)) return;
What I'm doing here is saying if the message does not start with the prefix, stop running until a new message is sent. I might be missing something, but certainly check out the tutorial. It's really well written.
https://discordjs.guide/creating-your-bot/commands-with-user-input.html#basic-arguments
Related
I'd like to take an action the first time a user loads a new version of my VS Code extension. This is different from merely detecting first run as described by the How to run vscode extension command just right after installation? because I don't want to detect "just right after installation" I want to detect first run of each new version which is a totally different problem.
Mike Lischke's answer to that question doesn't actually answer that question, it answers this question, but that doesn't mean this is a duplicate question, it means the response to the other question doesn't actually answer the asked question, and since unlike many people I actually read the question, I didn't bother to read the answers, because answers to that question are not what I seek. Frankly I'm tempted to delete the question myself just to spite Stack Overflow because I'm fed up with this crap. Do whatever you like.
Searching the net turned up sample code
export function activate(context: vscode.ExtensionContext) {
if (context.firstTimeUse) {
//do the one-time-per-version-update thing
}
}
but ExtensionContext doesn't seem to have this property, at least not any more.
So how do you do it now?
I could record the version in a file and compare to the file before updating it, but if there's baked in support I'd rather do it the supported way.
There is no supported mechanism.
Since each update gets a new folder, you don't need to log a timestamp, just probe for the file. If it exists, not first run. If it doesn't exist, first run so create the file and do other first run things.
This is so simple and straightforward there probably won't ever be a supported mechanism. Thanks to Lex Li in the comments for confirming that this is the standard solution.
If you need to differentiate major, minor and maintenance releases, the simplest solution is to store the version string in context.globalState. You begin by trying to fetch from context.globalState. Absence means first run ever. If it's present, an exact match for current version means no change. For a non-match you can parse out major and minor version numbers context.globalState.
const currentVersion = context.extension.packageJSON.version as string;
const lastVersion = context.globalState.get("version") as string ?? "0.0.0"
if (lastVersion !== currentVersion) {
logger.warn(`Updated to ${currentVersion}`);
const lastVersionPart = lastVersion.split(".");
const currVersionPart = currentVersion.split(".");
if (lastVersionPart[0] !== currVersionPart[0]) {
// major version change
advertiseWalkthrough();
if (lastVersionPart[1] !== currVersionPart[1]) {
// minor version change
launchWhatsNew();
} else {
// it's a maintenance version change so don't pester the user
}
}
context.globalState.update("version", currentVersion);
}
I am attempting to put together a Cro service that has a react/whenever block consuming data "in the background" So unlike many examples of websocket usage with Cro, this has nothing to do with routes that may be accessed via the browser.
My use case is to consume message received via an MQTT topic and do some processing with them. At a later stage in development I might create a supply out of this data, but for now, when data is received it will be stored in a variable and dependant on certain conditions, be sent to another service via a http post.
My thought was to include a provider() in the Cro::HTTP::Server setup like so:
use Cro::HTTP::Log::File;
use Cro::HTTP::Server;
use Routes;
use DataProvider; # Here
my Cro::Service $http = Cro::HTTP::Server.new(
http => <1.1>,
host => ...,
port => ...,
application => [routes(), provider()], # Made this into an array of subs?
after => [
Cro::HTTP::Log::File.new(logs => $*OUT, errors => $*ERR)
]
);
And in the DataProvider.pm6:
use MQTT::Client;
sub provider() is export {
my $mqtt = MQTT::Client.new: server => 'localhost';
react {
whenever $mqtt.subscribe('some/mqtt/topic') {
say "+ topic: { .<topic> } => { .<message>.decode("utf8-c8") }";
}
}
}
This throws a bunch of errors:
A react block:
in sub provider at DataProvider.pm6 (DataProvider) line 5
in block <unit> at service.p6 line 26
Died because of the exception:
Invocant of method 'write' must be an object instance of type
'IO::Socket::Async', not a type object of type 'IO::Socket::Async'. Did
you forget a '.new'?
in method subscribe at /home/cam/raku/share/perl6/site/sources/42C762836A951A1C11586214B78AD34262EC465F (MQTT::Client) line 133
in sub provider at DataProvider.pm6 (DataProvider) line 6
in block <unit> at service.p6 line 26
To be perfectly honest, I am totally guessing that this is how I would approach the need to subscribe to data in the background of a Cro service, but I was not able to find any information on what might be considered the recommended approach.
Initially I had my react/whenever block in the main service.pm6 file, but that did not seem right. And needed to be wrapped in a start{} block because as I have just learned, react is blocking :) and cro was not able to actually start.
But following the pattern of how Routes are implemented seemed logical, but I am missing something. The error speaks about setting up a new method, but I'm not convinced that is the root cause. Routes.pm6 does not have a constructor.
Can anyone point me in the right direction please?
Thanks to all who have provided information, this has been a very valuable learning exercise.
The approach of passing additional sub routines, along side router() in the application parameter to Cro::HTTP::Server.new gave further trouble. (an array is not allowed, and broke routing)
Instead, I have moved the background work into a class of it's own, and given it a start and stop method more akin to Cro::HTTP::Server.
My new approach:
service.pm6
use Cro::HTTP::Log::File;
use Cro::HTTP::Server;
use Routes;
use KlineDataSubscriber; # Moved mqtt functionality here
use Database;
my $dsn = "host=localhost port=5432 dbname=act user=.. password=..";
my $dbh = Database.new :$dsn;
my $mqtt-host = 'localhost';
my $subscriber = KlineDataSubscriber.new :$mqtt-host;
$subscriber.start; # Inspired by $http.start below
my Cro::Service $http = Cro::HTTP::Server.new(
http => <1.1>,
host => ...,
port => ...,
application => routes($dbh), # Basically back the way it was originally
after => [
Cro::HTTP::Log::File.new(logs => $*OUT, errors => $*ERR)
]
);
$http.start;
say "Listening at...";
react {
whenever signal(SIGINT) {
say "Shutting down...";
$subscriber.stop;
$http.stop;
done;
}
}
And in KlineDataSubscriber.pm6
use MQTT::Client;
class KlineDataSubscriber {
has Str $.mqtt-host is required;
has MQTT::Client $.mqtt = Nil;
submethod TWEAK() {
$!mqtt = MQTT::Client.new: server => $!mqtt-host;
await $!mqtt.connect;
}
method start(Str $topic = 'act/feed/exchange/binance/kline-closed/+/json') {
start {
react {
whenever $!mqtt.subscribe($topic) {
say "+ topic: { .<topic> } => { .<message>.decode("utf8-c8") }";
}
}
}
}
method stop() {
# TODO Figure how to unsubscribe and cleanup nicely
}
}
This feels much more "Cro idiomatic" to me, but I would be happy to be corrected.
More importantly, it works as expected and I feel is somewhat future proof. I should be able to create a supply to make real-time data available to the router, and push data to any connected web clients.
I also intend to have a http GET endpoint /status with various checks to ensure everything healthy
The root cause
The error speaks about setting up a new method, but I'm not convinced that is the root cause.
It's not about setting up a new method. It's about a value that should be defined instead being undefined. That typically means a failure to attempt to initialize it, which typically means a failure to call .new.
Can anyone point me in the right direction please?
Hopefully this question helps.
Finding information on a recommended approach
I am totally guessing that this is how I would approach the need to subscribe to data in the background of a Cro service, but I was not able to find any information on what might be considered the recommended approach.
It might be helpful for you to list which of the get-up-to-speed steps you've followed from Getting started with Cro, including the basics but also the "Learn about" steps at the end.
The error message
A react block:
in sub provider ...
Died because of the exception:
...
in method subscribe ...
The error message begins with the built in react construct reporting that it caught an exception (and handled it by throwing its own exception in response). A "backtrace" corresponding to where the react appeared in your code is provided indented from the initial "A react block:".
The error message continues with the react construct summarizing its own exception (Died because ...) and explains itself by reporting the original exception, further indented, in subsequent lines. This includes another backtrace, this time one corresponding to the original exception, which will likely have occurred on a different thread with a different callstack.
(All of Raku's structured multithreading constructs[1] use this two part error reporting approach for exceptions they catch and handle by throwing another exception.)
The first backtrace indicates the react line:
in sub provider at DataProvider.pm6 (DataProvider) line 5
use MQTT::Client;
sub provider() is export {
my $mqtt = MQTT::Client.new: server => 'localhost';
react {
The second backtrace is about the original exception:
Invocant of method 'write' must be an object instance of type
'IO::Socket::Async', not a type object of type 'IO::Socket::Async'. ...
in method subscribe at ... (MQTT::Client) line 133
This reports that the write method called on line 133 of MQTT::Client requires its invocant is an instance of type 'IO::Socket::Async'. The value it got was of that type but was not an instance, but instead a "type object". (All values of non-native types are either type objects or instances of their type.).
The error message concludes with:
Did you forget a '.new'?
This is a succinct hint based on the reality that 99 times out of a hundred the reason a type object is encountered when an instance is required is that code has failed to initialize a variable. (One of the things type objects are used for is to serve the role of "undefined" in languages like Perl.)
So, can you see why something that should have been an initialized instance of 'IO::Socket::Async' is instead an uninitialized one?
Footnotes
[1] Raku's constructs for parallelism, concurrency, and asynchrony follow the structured programming paradigm. See Parallelism, Concurrency, and Asynchrony in Raku for Jonathan Worthington's video presentation of this overall approach. Structured constructs like react can cleanly observe, contain, and manage events that occur anywhere within their execution scope, including errors such as error exceptions, even if they happen on other threads.
You seem to be fine now but when I first saw this I made this https://github.com/jonathanstowe/Cro-MQTT which turns the MQTT client into a first class Cro service.
I haven't released it yet but it may be instructive.
We have developed the tools to read the emails from the Domino mailboxes and write those into the separate file in local disk(Its look like a backup). Recently we have created a new domino 9 test environment with our lab. But, our tools not working properly with our new domino work environment. To identify the problem about this issue, I have added some debug logs and it seems to look like the control hanged with the function "NAMELookup2". Here, I have added the code snippet,
DHANDLE hLookup;
char *pLookup;
if (NAMELookup2("Local", 0, 1, "$users", 1, dominoUser, 2, "FullName", &hLookup) == NOERROR) // hunged with this line
{
pLookup = (char *) OSLockObject(hLookup);
}
The same tool working fine with our other test environment. So, I think there is no problem with the code. I suspect that maybe the problem with our new work environment setup creation, or maybe missed to provide some kind permission to the users, or maybe I missed to add the mailboxes somewhere, etc.
Note:
I have run the tool with admin privilege user.
It would be great if anyone gives some direction on this.
Thanks,
See this NAMELookup2 page for reference. The function is declared as:
STATUS LNPUBLIC NAMELookup2(const char far *ServerName, DWORD Flags,
WORD NumNameSpaces, const char far *NameSpaces,
WORD NumNames, const char far *Names,
WORD NumItems, const char far *Items,
DHANDLE far *rethBuffer);
where NumItems is the number of null-terminated item names starting at the Items address. The code snippet in your question is passing a single item name ("FullName"), but is setting NumItems to 2. That is clearly wrong and could explain the hang. NumItems should be 1.
I am also suspicious of the ServerName argument. The documentation recommends passing NULL when you want to do a local lookup. Passing "Local" may be another way to accomplish the same, but you need to change your code in any case. I recommend changing the first argument to NULL.
I am encountering this issue in CE1.9.1.
When a User registers (doesn't matter if its during checkout or from the Create an Account link) the user keeps getting the password mismatch error even though the password is re-entered correctly.
The form validation does not indicate a miss-match, but once a user clicks on Register it returns the mismatch error.
There is no errors in the chrome console...
I found this: https://magento.stackexchange.com/questions/37381/please-make-sure-your-passwords-match-password-error-in-checkout-with-new-re
But I don't believe it is the same error.
I need to fix it soon, any help is greatly appreciated!
We also had this issue with 1 of our webshops. However we used a checkout extension. So im not sure if this applies for the regular standard checkout. Anyway.
The question should be, are u using a checkout extension?
If so, the value inside the model's file of that extension is set at:
$customer->setConfirmation($password);
but should be:
$customer->setPasswordConfirmation($password);
For me this worked, without changing anything in the core. It's just that the extensions should get a small update, or you can do it manually like i did. Just find that line in the files of the model map of your extension.
as workaround you can use folloing code:
$confirmation = $this->getConfirmation();
$passwordconfirmation = $this->getPasswordConfirmation();
//if ($password != $confirmation) {
if (!(($password == $confirmation) ||
($password == $passwordconfirmation))) {
$errors[] = Mage::helper('customer')->__('Please make sure your passwords match.');
}
Changing app/code/core/Mage/Customer/Model/Customer.php as proposed by #Pedro breaks the functionality of "forgot password" and "edit customer account" pages. Instead, make the following changes to
app/code/core/Mage/Checkout/Model/Type/Onepage.php
by editing lines starting from 369
if ($quote->getCheckoutMethod() == self::METHOD_REGISTER) {
// set customer password
$customer->setPassword($customerRequest->getParam('customer_password'));
$customer->setConfirmation($customerRequest->getParam('confirm_password'));
} else {
// emulate customer password for quest
$password = $customer->generatePassword();
$customer->setPassword($password);
$customer->setConfirmation($password);
}
and set the PasswordConfirmation -Property and not the Confirmation-Property of the Customer-Object:
if ($quote->getCheckoutMethod() == self::METHOD_REGISTER) {
// set customer password
$customer->setPassword($customerRequest->getParam('customer_password'));
$customer->setPasswordConfirmation($customerRequest->getParam('confirm_password'));
} else {
// emulate customer password for quest
$password = $customer->generatePassword();
$customer->setPassword($password);
$customer->setPasswordConfirmation($password);
}
Encountered the same problem and fixed it. Snel's answer is closer to right answer. The problem could lay in the external/local modules, so you should check not the
app/code/core/Mage/Checkout/Model/Type/Onepage.php
And of course do NOT modify it in any case!
But you should find _validateCustomerData() method which is used in your case. Use Mage::log() or debug_backtrace() for it. It may look something like (but not exactly, because this part could be modified for some reason):
if ($quote->getCheckoutMethod() == self::METHOD_REGISTER) {
// set customer password
$customer->setPassword($customerRequest->getParam('customer_password'));
$customer->setConfirmation($customerRequest->getParam('confirm_password'));
} else {
// emulate customer password for quest
$password = $customer->generatePassword();
$customer->setPassword($password);
$customer->setConfirmation($password);
}
Those modules extend the old version of core file so if you module wasn't updated, you should change them yourself and change
setConfirmation()
to its current usable analog:
setPasswordConfirmation()
I also had this same problem. I'm not comfortable with code so I wanted to avoid all the above fiddling. To fix it all I did was update my extensions, and I also disable one page checkout, cleared cache, then re-enabled one-page checkout.
This has now fixed the problem without needing to modify code.
hope it helps for you.
If anybody still can't figure out, why this is happening:
The Conlabz Useroptin extension (http://www.magentocommerce.com/magento-connect/newsletter-double-opt-in-for-customers.html) can cause this behavior aswell.
Unless this truly is a core bug, I wouldn't recommend changing core files.But i sloved this way Open app\code\core\Mage\Customer\Model\Customer.php and edit your code like below
$confirmation = $this->getConfirmation();
$passwordconfirmation = $this->getPasswordConfirmation();
//if ($password != $confirmation) {
if (!(($password == $confirmation) ||
($password == $passwordconfirmation))) {
$errors[] = Mage::helper('customer')->__('Please make sure your passwords match.');
}
I had the same issue after updating to 1.9.2.1 and was unable to resolve using some of the suggested code changes here and elsewhere - also very reluctant to change core code for obvious reasons.
My solution - a configuration update. It was:
Enable OnePage Checkout = Yes
Allow Guest Checkout = Yes
Require Customer to be Logged in = No
I updated to Yes/No/Yes as per the above and cleared the cache. This resolved the issue by inserting the standard customer registration form (rather than appending the registration to end of the billing info) and passing that info to the billing form on successful registration.
It seems there is a code issue here along the lines of the other responses but this was an excellent workaround for me. Hope it helps.
Change this code
app\code\core\Mage\Customer\Model\Customer.php
$confirmation = $this->getPasswordConfirmation();
to this code
$confirmation = $this->getConfirmation();
The javascript console keeps showing "Not a custom field name: username" when its supposed to show an error for the username field. There clearly is a field named "username". I tried changing it to some other name everywhere, but it still didn't work.
Any idea what is going on?
<fb:registration redirect-uri="<?=$pageurl?>"
fields="[{'name':'name'},{'name':'email'},{'name':'location'},{'name':'username','description':'Username','type':'text'},{'name':'password','view':'not_prefilled'},{'name':'captcha','view':'not_prefilled'}]"
onvalidate="validate" width="400"></fb:registration>
and my validate function...
function validate(form,cb)
{
console.dir(form);
$.get('/api/?f=user_email_present&username='+form.username+"&email="+form.email,function(data){
console.log(data);
if(data.username==false)
{
cb();
}
else
{
if(data.username=='username')
cb({username: 'That username is already taken. Please try another username.'});
else if(data.username=='usernamelength')
cb({username: 'The username cannot exceed 20 characters in length.'});
}
});
}
I can't be too sure, but I think I remember all this working a while back. Took me by complete shock when we are 2 days from launch.
Update: I scrapped out asynchronous validation and used the other validation. It still throws the same error!
After spending the better part of two days, I managed to figure out what is going on. It is a silly but potent bug on facebook's end. If the width of the widget is too less, it gives this error. Increasing the width to 800px fixed it promptly. Probably they don't render the proper error fields when the width is too small.
I have filed a bug report: https://github.com/facebook/connect-js/issues/275
If you guys can give it a shot and comment on my bug report so that they can take action immediately, it would be awesome.