Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: multiple lg #1861

Merged
merged 49 commits into from
Feb 14, 2020
Merged

feat: multiple lg #1861

merged 49 commits into from
Feb 14, 2020

Conversation

zhixzhan
Copy link
Contributor

@zhixzhan zhixzhan commented Jan 15, 2020

Description

Add support for multiple lg file.

changes:

1. Bot file structure:

Each when create a dialog, lg/lu will also be created. same as deleting.

+ ToDoSample
    + common
       - common.lg
    + Main
       - Main.dialog
       - Main.lg
       - Main.lu
2. support lg import
[import](../common/common.lg) 
 
# bfdactivity-696707
- @{help()}

# bfdactivity-157674()
- Hi! I'm a ToDo bot. Say "add a todo named first" to get started.

lgIndexer/parse,check now support call with an importResolverDelegate.
and default importResolverDelegate implemented in server and client/store

3. visual editor

new created lg, will save to dialog's lg file, not common.lg anymore.

4. auto migration from single-lg bot

auto move generated lg template (like bfdactivity-123456) from common.lg into dialog.lg

Task Item

close #796
close #1871

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Code refactor (non-breaking change which improve code quality, clean up, add tests, etc)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Doc update (document update)

Checklist

  • I have added tests that prove my fix is effective or that my feature works
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have functionally tested my change

Screenshots

preview

@zhixzhan zhixzhan requested a review from yeze322 as a code owner January 20, 2020 09:36
@boydc2014 boydc2014 added Approved to merge approved, waiting to be merged and removed Needs review labels Feb 10, 2020
boydc2014
boydc2014 previously approved these changes Feb 12, 2020
@boydc2014
Copy link
Contributor

One last thing, after some digging into, i finally can repro the warning message in console. Create a bot with the master branch, and use this branch to open it. You will see some errors in console complaining about '\r'.

I believe there is some thing happening in your conversion phrase (by the way, this conversion logic is great), i think perhaps there are some issue in this version of lg parser when doing CRUD, not sure. Please take a look.

@zhixzhan
Copy link
Contributor Author

zhixzhan commented Feb 13, 2020

One last thing, after some digging into, i finally can repro the warning message in console. Create a bot with the master branch, and use this branch to open it. You will see some errors in console complaining about '\r'.

I believe there is some thing happening in your conversion phrase (by the way, this conversion logic is great), i think perhaps there are some issue in this version of lg parser when doing CRUD, not sure. Please take a look.

Hi @boydc2014 @cwhitten After some investments, I found two reason cause this error lg.

  1. lg Parser do not support file end with '\r', that's why we could only re-pro it in windows, not *nix.
  2. When splitting common.lg, by mistake I use '\n' as NEWLINE splitter, but windows NEWLINE is '\r\n'.

To fix 2, I convert all '\r' to '\r\n' ( like lg parser doing ).

By doing this, we can ensure Composer would not produce lg file end with \r. But for other text editor, it may still be an issue for lg parser.

@zhixzhan zhixzhan force-pushed the managed-lg branch 2 times, most recently from fa285a8 to 6fdba8d Compare February 13, 2020 09:44
boydc2014
boydc2014 previously approved these changes Feb 13, 2020
Copy link
Contributor

@boydc2014 boydc2014 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last thing, after some digging into, i finally can repro the warning message in console. Create a bot with the master branch, and use this branch to open it. You will see some errors in console complaining about '\r'.
I believe there is some thing happening in your conversion phrase (by the way, this conversion logic is great), i think perhaps there are some issue in this version of lg parser when doing CRUD, not sure. Please take a look.

Hi @boydc2014 @cwhitten After some investments, I found two reason cause this error lg.

  1. lg Parser do not support file end with '\r', that's why we could only re-pro it in windows, not *nix.
  2. When splitting common.lg, by mistake I use '\n' as NEWLINE splitter, but windows NEWLINE is '\r\n'.

To fix 2, I convert all '\r' to '\r\n' ( like lg parser doing ).

By doing this, we can ensure Composer would not produce lg file end with \r. But for other text editor, it may still be an issue for lg parser.

LG parser support both \n or \r\n as line break, just not '\r', because it's not a line break.

It's OK in composer to choose one flavor, like you said "\r\n", when saving files, just make sure not '\r' arrears alone somewhere at the end. Maybe choosing line break based on platform is better, but since all our sample bots is also kind of have some flavor, so it's OK for now.

@cwhitten if you are seeing warning messages in console, you should remove the last line-break(\r) in your LG file, because you've checked out this branch, so your opening bot has been converted once which introduce this '\r' at end. Since it's fixed, it won't affect existing user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Approved to merge approved, waiting to be merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants