I have the following story:
story: survey continue
steps:
- intent: greet
- action: utter_greet
- intent: affirm
- action: health_form
- active_loop: health_form
- intent: out_of_scope
- action: utter_ask_continue
- intent: affirm
- action: health_form
- active_loop: null
- action: utter_slots_values
And let's assume the following conversation:
1 Me: hello
2 Bot: Hi! It's time for your daily wellness check. Tracking healthy habits is a great way to measure your progress over time. Would you like to answer a few questions about your health?
3 Me: yes please
4 Bot: Did you exercise yesterday? Don't sweat it if you didn't run a marathon - walks count!
5 Me: wait stop
6 Bot: Sorry, I don't quite understand. Do you want to continue?
7 Me: actually yes
8 Bot: What kind of exercise did you do?
As you can see, in the 7th message if the user makes an affirmation intent it answers the question proposed in the 6th message as well as the one proposed in the 4th message.
I would expect a conversation flow like this:
[...]
6 Bot: Sorry, I don't quite understand. Do you want to continue?
7 Me: actually yes
8 Bot: Did you exercise yesterday? Don't sweat it if you didn't run a marathon - walks count!
Is this expected behavior? How can I achieve the expected flow that I have in mind?
Try to set your form to run again under active_loop, instead of null. A sample story from the Rasa official website on how to "return" to the form after another intent here
rules:
- rule: Example of an unhappy path
condition:
# Condition that form is active.
- active_loop: restaurant_form
steps:
# This unhappy path handles the case of an intent `chitchat`.
- intent: chitchat
- action: utter_chitchat
# Return to form after handling the `chitchat` intent
- action: restaurant_form
- active_loop: restaurant_form
Related
so we use yaml for translations at the moment.
So imagine the following list as an idea (not the real one)
# Employee records
- martin:
name: Martin D'vloper
job: Developer
skills: "Preferred skills"
mostPreferred: python
leastPreferred: perl
notImportant: pascal
- tabitha:
name: Tabitha Bitumen
job: Developer
skills:
- lisp
- fortran
- erlang
So what I want to know is, in the case of skills for Martin, I want to define skills, and then it needs to have a subgroup of itself for the other keys.
explaining how it works, site checks for the keys on the translation file, and there is a key that would be employee.martin.skills.mostPreferred for which it retrieves the variable, but for the label of that section it also wants to get the variable saved for the workd employee.martin.skills.
how would this be achieved on yaml?
at the moment I see the code doing this
- martin:
name: Martin D'vloper
job: Developer
skills: "Preferred skills"
"skills":
mostPreferred: python
leastPreferred: perl
notImportant: pascal
is this correct and necessary?
I'm trying to create a role with argument validation via the meta/arguments_spec.yml file, and I'd like a user to be able to pass in a tree of arbitrary depth as one of the arguments. In other words, a valid family_tree argument might look like:
family_tree:
name: Sarah
children:
- name: John
- name: Jimmy
- name: Billy
But it may also look like:
family_tree:
name: Bob
children:
- name: Bob, Jr.
children:
- name: Bob, III
children:
- name: Bob, IV
children:
# and so on...
This would require a recursive reference of some kind, however, I can't seem to find anything that supports this in the native argument_spec options. I know how to create recursive references via JSON Schema, and I'm aware the ansible.utils.validate supports JSON Schema as well, but as far as I can tell, this would mean manually adding a task to the beginning of my role's tasks list, which defeats the purpose of a dedicated argument_spec file and makes things harder to reason about, so not my preferred option.
for this website, it takes information from a authors.Yaml file.
this file holds the detail for the demo author.
authors:
- slug: wutali
name: Takahiro Fujiwara
introduction:
Co-founder and CTO at Fuller, Inc. / Software & Data Engineer /
Python / Golang / React
however, I wish to put in my information.
- slug: Hemming
name: Alexander Hemming
introduction:
Developer, React, Node, Sveltekit, Goland.
- slug: Owner
name: John Doe
introduction:
Founder and CEO at a company.
adding this to the end doesn't seem to work. How would I make it some that this information is accessible for additional potential authors?
You have two indentation errors:
- slug: Hemming
name: Alexander Hemming
introduction:
Developer, React, Node, Sveltekit, Goland.
- slug: Owner # fixed indentation to be on par with previous item
name: John Doe
introduction: # next line must be more indented to be the value
# of this key.
Founder and CEO at a company.
Considering writing/reading files in YAML format (http://yaml.org/)
I'm just surprised by apparent lack of output formatting options in default YAML.dump (Ruby 2.2.3). Without any pretty printing option, the YAML.dump appears really ugly. I explain:
Consider this hand-written YAML configuration file 'config/bots.yml' where I have a list of items (hashes, each one with keys 'token' and 'comment':
input file:
- token: 070743004:yuSJJdB5L354Zq41iGIggSdYGJ1IhVh8XSrA
comment: ROSPOshop.com
- token: 998001334:zAFo4dBdd3ZZtqKiGdPqkkYGJ1ppVW8pUZ
comment: pagoSALDO.com bot
- token: 184679990:BBBBBBBBBCCCCCCCGIDDDDDDDHHHHHHHHHH
comment: SOLYARISoftware demo bot
- token: 184679990:BBBBBBBBBCCCCCCUUUUUUUUUUHHHHHHHHHH
comment: Another demo bot
- token: 184679990:BBBBBBBBBCCCCCCCGHGGHHGHGHHHHHHHHHH
comment: Yet Another demo bot
No elaboration: just a load and a successive dump script as:
config = YAML.load(File.open('config/bots.yml'))
File.open('config/bots.yml', "w") { |f| f.write(YAML.dump(config)) }
output file:
---
- token: 070743004:yuSJJdB5L354Zq41iGIggSdYGJ1IhVh8XSrA
comment: ROSPOshop.com
- token: 998001334:zAFo4dBdd3ZZtqgKiGdPqkkYGJ1ppVW8pUZ
comment: pagoSALDO.com bot
- token: 184679990:BBBBBBBBBCCCCCCCGIDDDDDDDHHHHHHHHHH
comment: SOLYARISoftware demo bot
- token: 184679990:BBBBBBBBBCCCCCCUUUUUUUUUUHHHHHHHHHH
comment: Another demo bot
- token: 184679990:BBBBBBBBBCCCCCCCGHGGHHGHGHHHHHHHHHH
comment: Yet Another demo bot
I'm unhappy because all array items are now collapsed (the line break is removed). That's very sad if the numbers of items is long and/or data structures for each item isa variable: a messy reading!
Question (1)
There is any YAML option do do some more pretty printing for YAML.dump ?
By example to separate with a blank line each item in an Array ?
Question (2)
I found this very helpfull tutorial ("YAML Cookbook"):
http://www.yaml.org/YAML_for_ruby.html#yaml_for_ruby
There is any more recent update / official Ruby doc about explaining YAML tips&tricks (data conversions, etc.) ?
Question (3)
Any possible YAML alternative ? I mean maybe an alternative gem to read/write YAML ? BTW, of course I considered JSON, but I prefer the more clear YAML format when reading texts data!
UPDATED
BTW, A lot of info/useful YAML format tips here:
https://en.wikipedia.org/wiki/YAML
You can write your own pretty-print solution, if that's all you're looking for. For example:
config = YAML.load(File.open('bots.yml'))
puts config.to_yaml.gsub("\n-", "\n\n-")
Output:
---
- token: 070743004:yuSJJdB5L354Zq41iGIggSdYGJ1IhVh8XSrA
comment: ROSPOshop.com
- token: 998001334:zAFo4dBdd3ZZtqKiGdPqkkYGJ1ppVW8pUZ
comment: pagoSALDO.com bot
- token: 184679990:BBBBBBBBBCCCCCCCGIDDDDDDDHHHHHHHHHH
comment: SOLYARISoftware demo bot
- token: 184679990:BBBBBBBBBCCCCCCUUUUUUUUUUHHHHHHHHHH
comment: Another demo bot
- token: 184679990:BBBBBBBBBCCCCCCCGHGGHHGHGHHHHHHHHHH
comment: Yet Another demo bot
Is there a way to make the following YAML shorter so that the same resources aren't repeated?
---
classes:
- roles::storage::nfs
samba::config::includeconf:
- alpha
- beta
- charlie
- delta
- echo
- foxtrot
smb_shares:
alpha:
name: alpha
beta:
name: beta
charlie:
name: charlie
delta:
name: delta
echo:
name: echo
path: /path/to/file
foxtrot:
name: foxtrot
If there's a way to reduce any of the repetition, that would be great. Ideally, each resource name would only appear once.
Yes you can vastly reduce this with two optimisations, one of which nullifies most of the effect of the other. You will however have to change your program from reading in simple sequences and mappings to create smarter objects ( which I called ShareInclude, Shares and Share):
---
classes:
- roles::storage::nfs
samba::config::includeconf: !ShareInclude
- alpha
- beta
- charlie
- delta
- echo
- foxtrot
smb_shares: !Shares
echo: !Share
path: /path/to/file
When creating ShareInclude, you should create a Share for each sequence element with an initial name being the same as the scalar value and insert this in some global list.
The above takes care of most of the Share object, execept info. When
echo: !Share
path: /path/to/file
is processed a temporary anonymous Share should be created with path set as an attribute or other retrievable value (if the name would be different that could be stored as well). Then once Shares is created it will know the name of the share to look up (echo from the key of the mapping) and take one of two actions:
If the name can be looked up, update the Share object with the information from the anonymous Share
If the name cannot be found, promote the anonymous share by providing the key value as its name, and store it.
This way you have to specify echo twice, otherwise there is no way to associate the explicit path with the specific Share object created when processing ShareInclude. If that is still too much you can approach it from the other way and leave ShareInclude empty and implicitly make those entries when dealing with Shares:
---
classes:
- roles::storage::nfs
samba::config::includeconf: !ShareInclude
smb_shares: !Shares
alpha:
beta:
charlie:
delta:
echo:
path: /path/to/file
foxtrot:
Although this is somewhat shorter, depending on your YAML parser, you might no longer have a guaranteed ordering in the creation of the Share object. And if you have to make Shares into a sequence of key-value pairs the shortening advantage is gone.