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

Add ISBL lexer #891

Merged
merged 28 commits into from Apr 3, 2020
Merged

Add ISBL lexer #891

merged 28 commits into from Apr 3, 2020

Conversation

MedvedTMN
Copy link
Contributor

Add new lexer:

  • ISBL built-in language DIRECTUM
    Add New theme:
  • ISBL editor light

Add new lexer:
  - ISBL built-in language DIRECTUM
Add New theme:
  - ISBL editor light
@MedvedTMN
Copy link
Contributor Author

I did not have errors for Ruby 2.5.1. What to do?

@dblessing
Copy link
Collaborator

It may have been a transient failure. I restarted the job to see what happens.

@MedvedTMN
Copy link
Contributor Author

Problem still exists

- add isbl_editor_dark theme
- fixed isbl_editor_light theme
@dblessing
Copy link
Collaborator

This may have been related to #892. Rebase against master and see if that fixes things.

@pyrmont pyrmont added the needs-review The PR needs to be reviewed label Jul 18, 2019
@pyrmont
Copy link
Contributor

pyrmont commented Aug 1, 2019

@MedvedTMN Thanks for submitting the PR and I'm sorry it's taken so long to get this addressed. I joined the maintainers group a couple of months ago and have been working backwards chronologically through the outstanding PRs which is why I hadn't got to yours yet :(

I realise that @vidarh in his review had identified this as having only minor issues but I'm afraid that's not my conclusion. There are a couple of problems:

  1. The architecture of this lexer results in a large number of String objects being added to Rouge. At this stage Rouge works by loading all lexers into memory. Running rake check:memory on master and on this branch shows that this lexer would lead to an increase in allocated memory of 1MB and to retained memory of 400KB. That's a significant amount compared to other lexers. Looking at the lexer, the vast majority of strings are constants. Does ISBL differentiate between constants and non-constants by capital letters? If it did, you could get rid of all these constants by merely highlighting any capitalised word as a constant.

  2. If including all of these strings is inescapable, we would be looking to do two things. First, the strings should be put behind memoised class methods. You currently store these all as local variables which require allocation at the time the class is read. Using class methods can delay that allocation. A memoised class method looks like the following:

    def self.some_identifier
      @some_identifier ||= %w(...)
    end

    Second, these strings can be stored in a separate file and then brought in by the memoised method when needed. You can see how this would work by looking at the Gherkin lexer:

    # self-modifying method that loads the keywords file
    def self.keywords
    load File.join(__dir__, 'gherkin/keywords.rb')
    keywords
    end

    The file that is loaded by the Gherkin lexer is generated by a Rake task. You would need to create a similar task as part of the PR submission for ISBL.

  3. The lexer is missing the frozen_string_literal pragma we use for all files in Rouge.

  4. The lexer is called ISBL but the description suggests that the name of the language is DIRECTUM. Which name is the name of the language? If it is ISBL, the name of the lexer should be ISBL rather than Isbl.

  5. The lexer contains inconsistent usage of whitespace for indenting. Rouge follows common Ruby practices and indents with two spaces. Please update the lexer accordingly.

  6. Since the lexer was originally submitted, we have made RuboCop checks part of the test suite (you can run this at the command line by typing rake). To avoid RuboCop's ambiguous regular expression warnings, the parameter passed to rule should be prefaced with %r and a delimiter. The simplest delimiter is / such that rule /.../ becomes rule %r/.../.

  7. We generally prefer using \b rather than lookaheads in patterns. I realise that ISBL, due to its provenance, may be used by users who will write identifiers with Cyrillic characters. Does this mean you can't use \b?

  8. The PR includes two themes. I would suggest these be removed. I apologise for sounding a bit harsh but these appear to be primarily (if not only) of interest to the small subset of users that would want to highlight ISBL. Rouge's suggested approach for those situations is for users to include their own theming files separately in their projects.

Sorry you've had to wait so long only to then be hit with such a long list of suggested changes. I'll try to be as responsive as I can be to any follow-up questions you have.

@pyrmont pyrmont added author-action The PR has been reviewed but action by the author is needed and removed needs-review The PR needs to be reviewed labels Aug 1, 2019
@pyrmont
Copy link
Contributor

pyrmont commented Aug 2, 2019

@MedvedTMN Do you want it close this PR? It looks like perhaps you're planning to create your own fork?

@MedvedTMN
Copy link
Contributor Author

No, I do not want to close this PR. I just wanted to update the local project files to correct your comments. Am I doing something wrong?

@ashmaroli
Copy link
Contributor

Looks like @MedvedTMN changed the line-endings on all files and committed them..

@pyrmont pyrmont self-assigned this Aug 26, 2019
@ashmaroli
Copy link
Contributor

@MedvedTMN May I know what OS you're working on..? It looks like you altered the line endings of numerous files.

@MedvedTMN
Copy link
Contributor Author

@MedvedTMN May I know what OS you're working on..? It looks like you altered the line endings of numerous files.

Windows 10

@MedvedTMN
Copy link
Contributor Author

How can I fix it?

@ashmaroli
Copy link
Contributor

@MedvedTMN Fixing this is perhaps too much for you (I'm assuming that you're not an advanced Git user). But you may want to read through the following documentation for future contributions:
https://help.github.com/en/articles/configuring-git-to-handle-line-endings

I'll try to fix this for you via a PR to your branch some time later..

@MedvedTMN
Copy link
Contributor Author

I'll try to fix this for you via a PR to your branch some time later..

Thank you very much for your help

@pyrmont pyrmont added needs-review The PR needs to be reviewed and removed author-action The PR has been reviewed but action by the author is needed labels Mar 24, 2020
Copy link
Contributor

@pyrmont pyrmont left a comment

Choose a reason for hiding this comment

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

Thanks for the work on getting this ready to merge. It's looking good!

Could I ask you to have a look at reducing the visual sample so that it's not as duplicative? The visual sample doesn't need to be the absolute minimum required to test lexer's rules but for maintainability reasons, it's helpful to have it be more on the minimal side.

If that can be cut down a little, we'll be ready to merge.

@pyrmont pyrmont added author-action The PR has been reviewed but action by the author is needed and removed needs-review The PR needs to be reviewed labels Mar 31, 2020
@ashmaroli
Copy link
Contributor

@MedvedTMN Why have trailing whitespace been added to the sample file in the latest commit..?

@pyrmont
Copy link
Contributor

pyrmont commented Apr 2, 2020

@MedvedTMN Thanks for fixing the trailing whitespace issue; however, you've added back in all the extraneous stuff in the visual sample you removed earlier. Can you delete that stuff again?

@MedvedTMN
Copy link
Contributor Author

The current example most fully demonstrates the capabilities of the language. If the example is too large, I can shorten it. Or do you need to remove any specific extraneous stuff?

@pyrmont
Copy link
Contributor

pyrmont commented Apr 2, 2020

@MedvedTMN The code added back by this commit is the extraneous stuff I'm referring to.

@MedvedTMN
Copy link
Contributor Author

What is wrong with this code?

@pyrmont
Copy link
Contributor

pyrmont commented Apr 2, 2020

@MedvedTMN Did you look at the link? All the code you added back in isn't necessary, is it? The point of the visual sample is to test the rules in the lexer. I don't see why a lexer that's 97 lines of code total needs a visual sample that's almost 300 lines.

@pyrmont
Copy link
Contributor

pyrmont commented Apr 2, 2020

@MedvedTMN To pick one thing as illustrative, you have multiple instances of multiline comments. One or two would suffice. I'm not familiar with this language so it's hard for me to identify definitively what's duplicative but it looks to me like there are many instances like this. The visual sample appears to be a copy and paste from existing code. A more minimal sample that better targeted the rules of the lexer would make this easier to maintain.

@MedvedTMN
Copy link
Contributor Author

it's all right?

Comment on lines 1 to 14
// Types
type : IApplication
type : .custom_type

// Operators
result = 1 + 1 / 2

// Numbers
integer = 5
float = 5.5

// Strings
double_quotes = "An example"
single_quotes = 'An example'
Copy link
Contributor

@pyrmont pyrmont Apr 2, 2020

Choose a reason for hiding this comment

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

@MedvedTMN Is this correct syntax for ISBL? Looking quickly at the rules, it looked to me like .custom_type should be lexed as a type but that wasn't what happened. Could you have a look?

Copy link
Contributor Author

@MedvedTMN MedvedTMN Apr 2, 2020

Choose a reason for hiding this comment

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

No, this is the wrong type definition for the ISBL variable. The following definition will be considered correct:
VariableName: ObjectType|IReference[.ReferenceType]|IEDocument[.CardType][ = Expression]
This is how this code looks in the built-in code editor:
image

Copy link
Contributor

Choose a reason for hiding this comment

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

Cool. Can you update the visual sample so that it's correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

edit this part:
// Types
type : IApplication
type : .custom_type

or this:
Employees : IReference.РАБ = CreateReference(EMPLOYEES_REFERENCE; ArrayOf("Пользователь"; SYSREQ_STATE); FALSE)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks!

@pyrmont pyrmont merged commit f3fb856 into rouge-ruby:master Apr 3, 2020
@pyrmont
Copy link
Contributor

pyrmont commented Apr 3, 2020

@MedvedTMN I realise this took a long time but we finally got there in the end :) This will be part of the next release of Rouge. The gem is scheduled to be pushed on Tuesday 14 April 🎉

@pyrmont pyrmont removed the author-action The PR has been reviewed but action by the author is needed label Apr 3, 2020
mattt pushed a commit to NSHipster/rouge that referenced this pull request May 21, 2020
This commit adds a lexer for ISBL.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants