I'm trying to manage the context of my Google Assistant agent (in DialogFlow), using the ApiAi class in the npm package actions-on-google.
The problem is this:
How can I reset the lifespan / delete a context using the npm package?
I can easily set the lifespan of a new context, and it works.
However:
How do I delete a context?
Setting the context to a different number does not seem to work. That is, if I set app.setContext('myContext',10) and then, 2 intents later, when the lifespan in 8, I call app.setContext('myContext',10) again, in the next intent, the lifespan is still 7. If I could answer (1) and delete a context, I'd just delete it and set it again.
I don't think there is a way to delete or overwrite the duration of a context. Instead, if you know that a certain context must not be active at a certain point, set a context that lasts for 1 or 2 turns and do this after each turn. This will also give you more control over the conversation, so you won't have contexts that last for 10 turns that you suddenly don't need anymore.
To delete a lifespan of context you just set it to ZERO or 0 like app.setContext('your_context',0)
Make sure you do this before calling the app.ask or app.tell
or
if not using client you could write a function that simply sets
this.contexts_[your_context] = {}
The first option is definitely working for me. I have not tried the second option. Try and see if you are not setting it in the Dialogflow. Also, you can remove context setting in webhook and put lifespan as 0 in Dialogflow. That will put a line (like deprecated method) over your context.
I know this question is old, at least old enough so that we now have a v2 API and library overhaul, so I'll answer anyway with today's solution :) .
1 - To delete a context, you can use conv.contexts.delete('context1'); as specified on the Node.js library reference docs.
2- If conv.contexts.set('context1', 1); doesn't change the context's lifespan then you can easily delete it and recreate it with these two calls.
My experience is that you cannot overwrite context data.
You can create a new context though:
agent.setContext({
name: contextName,
lifespan: newLifeSpan,
// Note: Parameters are not visible until the context is passed
// console.log() won't show them now.
parameters: {
// Previously saved using getContext()
param_name : paramValue,
}
});
Related
I am using NestJS (version 6.5, with Express platform) and I need to handle a request with a property that can either be a File or a String.
Here is the code I currently have, but I don't find a clean way to implement this.
MyAwesomeController
#Post()
#UseInterceptors(FileInterceptor('source'))
async handle(#UploadedFile() source, #Body() myDto: MyDto): Promise<any> {
//do things...
}
Am I missing something obvious or am I supposed to write my own interceptor to handle this case?
Design-wise, is this bad?
Based on the fact you're designing a REST API:
It depends what use case(s) you want to achieve: is your - client-side - flow designed to be performed in 2 steps o not ?
Can string and file params be both passed at the same time or is there only one of the two on each call ? (like if you want to update a file and its name, or some other non Multer related attributes).
When you pass a string as parameter to your endpoint call, is a file resource created / updated / deleted ? Or maybe not at all ?
Depending on the answer and the flow that you thought of, you should split both cases handling within two independent endpoints, or maybe it makes sense to handle both parameters at the same time.
If only one of the params can be passed at a time, I'd say go for two independent endpoints; you'll benefit from both maintenance and code readability.
If both params can be passed at the same time and they're related to the same resource, then it could make sense to handle both of them at once.
Hope this helps, don't hesitate to comment ;)
I set up the command handler for my bot using the Discord.js guide (I am relatively new to Discord.js, as well as JavaScript itself, I'd say). However, as all my commands are in different files, is there a way that I can share variables between the files? I've tried experimenting with exporting modules, but sadly could not get it to work.
For example (I think it's somewhat understandable, but still), to skip a song you must first check if there is actually any audio streaming (which is all done in the play file), then end the current stream and move on to the next one in the queue (the variable for which is also in the play file).
I have gotten a separate music bot up and running, but all the code is in one file, linked together by if/else if/else chains. Perhaps I could just copy this code into the main file for my other bot instead of using the command handler for those specific commands?
I assume that there is a way to do this that is quite obvious, and I apologize if I am wasting peoples' time.
Also, I don't believe code is required for this question but if I'm wrong, please let me know.
Thank you in advance.
EDIT:
I have also read this question multiple times beforehand and have tried the solution, although I haven't gotten it to work.
A simple way to "carry over" variables without exporting anything is to assign them to a property of your client. That way, wherever you have your client (or bot) variable, you also have access to the needed information without requiring a file.
For example...
ready.js (assuming you have an event handler; otherwise your ready event)
client.queue = {};
for (guild of client.guilds) client.queue[guild.id] = [];
play.js
const queue = client.queue[message.guild.id];
queue.push({ song: 'Old Town Road', requester: message.author.id });
queue.js
const queue = client.queue[message.guild.id];
message.channel.send(`**${queue.length}** song${queue.length !== 1 ? 's' : ''} queued.`)
.catch(console.error);
I'm using node-wit to develop a chatbot application.
This is working fine mostly, but I've run into a problem with the use of the context.
I'm using the runActions api :
this.witClient.runActions(customer._key, messageText, witContext).then((newContext => {}
)).catch(reject);
I have defined a number of actions, which set the context.
This is working fine, as long the context is taking place over one message.
For example, if I were to call an action called addProduct :
addProduct({sessionId, context, text, entities}) {
return new Promise((resolve, reject) => {
context.product = `myNewProduct';
resolve(context);
});
},
It will then show a message using the 'product' context key.
However, when I try to use it over 2 messages, it seems to have lost the context ( for example, when asking a multiple choice question, and then handling that response ).
If I understand how it's working correctly, then node-wit doesn't keep the context beyond messages ( I assumed this at first because I'm passing a session key ).
A solution I see is to store the resulting context ( newContext in this case) in a session/user specific way, and then restore it and pass it again when the user is sending his new message.
Meaning, something like this :
witContext = getContextFromSession();
this.witClient.runActions(customer._key, messageText, witContext).then((newContext => { setContextInSession(newContext) }
)).catch(reject);
Would this be the correct way of handling it ?
Off course you have to store your context state, you decide how to store it. But, take into account what is the most efficient way if you're gonna have a lot of users, and your reasources available.
As you can see in the official example for nodeJs, there's a method named findOrCreateSession on https://github.com/wit-ai/node-wit/blob/master/examples/messenger.js they get the session before the wit actions are called.
In my particular case, I am storing it in the database, so I get the session before the action is called, so I can send the context, then in the actions I query the session again to modify the resulting context and store it again, try the best implementation for your needs.
G'day all,
I've been having trouble upgrading to a more recent version of the ember-simple-auth module.
In particular I seem to have two challenges:
1) the application no longer transitions to the desired route after authenticating. the configuration looks like this:
ENV['ember-simple-auth'] = {
crossOriginWhiteList: ['http://10.10.1.7:3000'],
routeAfterAuthentication: 'profile',
//store: 'simple-auth-session-store:local-storage',
//authorizer: 'simple-auth-authorizer:token',
};
but it never gets to "profile".
2) I can't get the authenticated session to stick after a reload. I had been trying to use the local-store which I believed would do the trick, but it's not. Has something changed in the implementation?
The documentation seems to indicate that the configuration strings are right, but the transition and session store don't seem to be working.
Has anyone had a similar problem?
Thanks,
Andrew
you could try adding "routeIfAlreadyAuthenticated" to ENV['ember-simple-auth'] - or you could transition manually in index route "afterModel" hook, if session is already authenticated
have you configured a session store? https://github.com/simplabs/ember-simple-auth#session-stores - the way it's configured changed in 1.0, now you can add the desired session store to app/session-stores/application.js - maybe this solves #1 too.
OK. As the comments call out, there were two problems here:
1) I had written a customer authorizer for the old version of simple-auth which didn't work with the new version, and
2) I had a typo in the adapter code, where DataAdapterMixin was DAtaAdapterMixin.
Removing (1) and fixing (2) fixed the problem.
Is there a way to remove a scope from the digest cycles? In other words, to suspend/resume a scope digest cycle?
In my case, I have all pages already loaded, but not all of them visible. So I'd like to suspend the ones that aren't visible to avoid useless processing. I don't want to use ng-view + $route, I don't want/need deep-linking.
I saw this thread and arrived to this fiddle. It probably does the work, but it's pretty invasive and not very framework-update-friendly.
Is there any other solution like a $scope.suspend() and scope.resume()? Or a less invasive one (from framework perspective)? I'm currently thinking about $destroy and $compile cycles.
I've ran into the same problem and I found an interesting solution that doesn't interfere (too much) with AngularJS. Add this to the scopes you want to disable:
var watchers;
scope.$on('suspend', function () {
watchers = scope.$$watchers;
scope.$$watchers = [];
});
scope.$on('resume', function () {
scope.$$watchers = watchers;
watchers = null;
});
Then, you can disable a scope and its children with: scope.$broadcast('suspend') and bring it back with scope.$broadcast('resume').
As the framework stands today there are no methods to suspend / resume digest on a scope. Having said this there are several techniques that one can use to limit number of watches that are executed as part of a digest cycle.
First of all, if parts of a screen are hidden anyway you could use the ng-switch family of directives thus removing invisible parts completely from the DOM.
Secondly, if a digest cycle is triggered from your directive via $apply and you want to limit watches re-evaluation to child scopes you could call $digest instead of $apply.
Then, yes, one could destroy and re-create scopes as described in the discussion you've linked to. But, if you are already hiding parts of the DOM it sounds like ng-switch might be a better option.