I am using rasa core version 0.10.4
At the end of the flow I want to add action_restart(default action) so that it will start new conversation when the end reached.
The story is like:
## Story_help_gnh
* button_option{"option_type":"gifts and hospitality"}
- utter_help_gnh
> gifts_and_hospitality
## Story_gnh_ethics_counsellor
> gifts_and_hospitality
* ethics_counsellor
- utter_gnh_ethics_counsellor
- action_restart
For me action_restart is not working in 0.10.4 version. I tried using 0.11.12 version, it is working.
I can't migrate code from 0.10.4 version to 0.11.12 version.
Can anyone help me with:
Does 0.10.4 version provides action_restart default action?
If yes how to use it. If no is there any alternative way to use it?
I just tried with Rasa Core version 0.10.4 and action_restart worked for me.
My stories:
## Story1
* greet
- utter_hello
- action_restart
My domain file:
intents:
- greet
actions:
- utter_hello
templates:
utter_hello:
- text: "Hi"
utter_restart:
- text: "I just restarted"
If then talk to the bot:
So 0.10.4 has a action_restart and you can simple add it as action_restart to your domain file. You can also add some custom text to the restart if you define a template utter_restart.
In general I recommend switching to the latest versions of Rasa Core. The step from 0.10.x to 0.11 is bit cumbersome as there were some architectural changes, but brings a ton of new features. Also their were none or only little breaking changes after 0.11.
Related
Apparently there are two ways to configure scrutinizer-ci to use custom phpCodeSniffer standards. The documentation only mentions phpcs use in "build" node and it isn't clear if they do different things or if one is preferred over the other.
Docs reference: https://scrutinizer-ci.com/docs/tools/php/code-sniffer/
What's the difference between running the checks inside "build" or "checks"? Should I use both?
checks:
php:
custom_coding_standard:
ruleset_path: 'ruleset.xml'
build:
tests:
override:
- 'phpcs-run --standard=ruleset.xml'
The official answer was to use phpcs-run.
build:
tests:
override:
- 'phpcs-run --standard=ruleset.xml'
The phpcs-run wrapper retrieves the latest version of phpcs on every build. Otherwise a preinstalled version of it is used. So usually the best way of running phpcs is using the wrapper in the build section.
Using puphpet a typical config.yaml php section might look like this:
php:
install: '1'
settings:
version: '70'
modules:
php:
- ioncube-loader
I have lots of other PHP modules installed but its ioncube I'm having issues with.
Up until just earlier, this was provisioning with PHP 7.0.4, which seemed to have a yum package for Ioncube loader.
I just had to rerun vagrant provision and now all of a sudden I appear to be on PHP 7.0.5.
Not much of a bother normally, except now I get issues with dependencies for ioncube (ioncube loader is crucial to run some encrypted 3rd party code I need).
My question is: Is it possible to lock php down to 7.0.4?
version: '704' doesn't work.
Also just to check I've understood the error message correctly:
Error: Package: php-ioncube-loader-5.1.2-1.el6.remi.5.4.x86_64 (remi)
Requires: php(zend-abi) = 20100525-x86-64
Installed: php-common-7.0.5-1.el6.remi.x86_64 (#remi-php70)
php(api) = 20151012-64
Available: php-common-5.4.45-5.el6.remi.x86_64 (remi)
php(api) = 20100412-x86-64
Available: php-common-5.4.45-7.el6.remi.x86_64 (remi)
php(api) = 20100412-x86-64
Available: php-common-7.0.4-1.el6.remi.x86_64 (remi-php70)
php(api) = 20151012-64
Available: php55u-common-5.5.33-1.ius.centos6.x86_64 (ius)
php(api) = 20121113-64
Available: php56u-common-5.6.19-1.ius.centos6.x86_64 (ius)
php(api) = 20131106-64
Available: php70u-common-7.0.4-1.ius.centos6.x86_64 (ius)
php(zend-abi) = 20151012-64
Other suggestions welcome, I just need ioncube loader working on this 1 project, am I right here? It looks like its available for every version of php except the one that's magically appeared on mine since the last provision. It's totally possible I'm barking up the wrong tree....
Author of PuPHPet here.
Unfortunately subversions are not supported (7.0.x), only major versions (7.0).
This is due to the absolutely insane way each distro and even each PHP version is so different to the other in regards to INI locations and module directories. It's ridiculous.
What could easily be added is support for ensure field to the YAML file that you could pass your specific version to. Mind opening a ticket on my github tracker to enable this?
hum
version: '704' doesn't work
should be
settings:
version: '7.0.4'
ioncube loader is not yet compatible with PHP 7, whatever version you install (7.0.4 or 7.0.5).
See the Compatibility list
Also see: upstream forum thread
I don't understand why the deployment is not working. I'm getting the following error in the build console:
Preparing deploy
Found gem
/usr/lib/git-core/git-stash: 186: /usr/lib/git-core/git-stash: cannot create /home/travis/build/prismicio/ruby-kit/.git/logs/refs/stash: Directory nonexistent
Build: https://travis-ci.org/prismicio/ruby-kit/jobs/40767391
My .travis.yml:
language: ruby
rvm:
- 2.1.1
- 2.1.0
- 2.0.0
- 1.9.3
- 1.9.2
- jruby-19mode
script: bundle exec rspec spec
notifications:
email:
- example#example.com
addons:
code_climate:
repo_token: X
deploy:
provider: rubygems
api_key:
secure: XXX
gemspec: prismic.gemspec
on:
tags: true
all_branches: true
What's wrong with the build?
The error:
/usr/lib/git-core/git-stash: 186: /usr/lib/git-core/git-stash: cannot create /home/travis/build/prismicio/ruby-kit/.git/logs/refs/stash: Directory nonexistent
may be related to how you're deploying your files to your provider and it's triggered by git stash and its DPL::Provider#cleanup process (see: releases.rb). By default Deployment Provider will deploy the files from the latest commit. This is not supported for all providers, therefore this just means that the "releases" provider needs to skip the cleanup, so it should deploy from the current file state instead (see #BanzaiMan comment) by adding this line:
skip_cleanup: true
This is because every provider has slightly different flags and these are documented in the Deployment section (or for the latest documentation check on GitHub for supported providers).
Further more, the above error is basically related to Travis CI bug (GH #1648) where basically File#basename is stripping the directory part (as per #BanzaiMan comment) and it's not clear why this cannot manifest in the CLI case. So this is something to fix in the near future.
I cannot see the apps running using 'Preview'.
The Ruby environment with the Rails framework is installed (able to see folders and files generated), and see application being built in Nitrous.IO IDE.
My installation shows I have the following installed:
- ruby 2.1.1p76
- Rails 4.1.0
- git version 2.0.0
- SQLite3
Building a simple blog app, I use the scaffold generator to create the MVC components needed for posts and comments:
1. $ rails generate scaffold post title:string body:text
2. $ rails generate scaffold comment post_id:integer body:text
I create the post and comment database tables using:
1. $ rake db:migrate
2. $ rake routes
3. $ rails server
Using 'Preview' to see app running on WEBrick, only get default webpage which says:
- "Routes are set up in the config/routes.rb"
- "running in development mode and haven't set a root route yet."
config/routes.rb file has the following:
Rails.application.routes.draw.do
resources :comments
resources :posts
# lines 6 -> 59 are comments giving coding examples of routes
end
==>> What do I need to do to 'Preview' Ruby apps??
Based on your comment above, I believe what you need to do is remove the public/index.html file and/or go to the route(s) you have created and specify one of them as root.
Also see this SO question and it's answer(s): deploying to heroku -- can't get rid of the "welcome to rails" default page
After you run rake routes command, it creates all the REST calls for you i.e. GET/POST/PUT/DELETE and as you have already created the scaffold you just need to invoke URL with the paths as /comment or /post and you will be able to access your blog application.
Ex: http://yourhost.com:3000/comment or http://yourhost.com:3000/post.
I'm trying to create a Vagrant setup using CentOS 6.4 and Apache 1.3 (this is for a legacy application). I am using Puppet (though if an answer in Chef is easier, I'd be happy to use it) and the Puppetlabs Apache class. The issue I'm having is that it installs Apache 2.2, but I don't see how to make it install Apache 1.3 instead.
What am I doing wrong and how can I do it right? (Answers of "Upgrade your app" will be downvoted - I don't have the authority to make that decision.)
The module you're using doesn't explicitly expose a parameter to specify which version of the httpd package you want to install.
Instead of using Puppetlabs module, you could use the Apache module from Alessandro Franceschi (source here - also on the forge)). If the package you need to install has a different name than httpd, the module exposes a package parameter which you can override like this:
class { 'apache':
package => 'apache13',
}
If, instead, Apache 1.3 is provided by the same httpd package by declaring the specific version you want, you can rely on the version parameter:
class { 'apache':
version => '1.3.39',
}
Clearly, you can also combine the two parameters together.
using those modules return the following error on Redhat:
Error 400 on SERVER: Illegal expression.
A Type-Name is unacceptable as function name in a Function Call at /etc/puppet/modules/apache/man.