Re: How I can help

[Ariya Hidayat]

To the question "What is most important", I don't think we have formalized any particular strategy for priorities. What I can come up with is the following strawman, to initiate the discussion so that we can iterate on it.

1) Infinite loop. The first priority is always to ensure that no input to the parser/tokenizer, no matter how crazy it is, can cause the parser/tokenizer to get trapped in an Infinite loop. It is hard to guarantee that of course, nevertheless when such a situation is discovered, it needs some attention right away.

2) Negative impacts to the JavaScript run-time, this can be in form of excessive memory consumption, exhausting the stack, or any other situation where the JavaScript engine running the parser/tokenizer can not operate well. A reasonable input to the parser/tokenizer must not trigger such a scenario.

3) Incorrect output. The parser/tokenizer must always produce the expected syntax tree/token list (following the ESTree specification). If the output deviates from the expectation, e.g. when the type of a node is wrong, this can indicate a serious flaw in the parsing/tokenizing process. When this problem is not fixed, it causes a compatibility problem between Esprima and other tools which expect ESTree conformance.

4) Valid program mistakenly flagged as invalid. Not fixing this can hamper the use of Esprima in a tool (e.g. code coverage, auto-complete, etc) since that tool may not be able function properly when encountering the corner cases.

5) Invalid program mistakenly treated as valid. This is less damaging that the above. However, it can cause a wrong expectation to an Esprima-based tool, especially when it focuses on correctness (e.g. static analysis, etc).

6) Speed, or rather, the lack thereof.

Of course, there is also the aspect of implementing new syntax features found in the latest specification. For instance, currently ES2017 is the upcoming standard and Esprima 4.0 is intended to tackle that (https://github.com/jquery/esprima/projects/1).

I hope that clarifies the situation!

Best regards,

--

Ariya Hidayat, https://ariya.io

[Mike Sherov]

Hi K.F.,

We've conditionally built up options in the past. If you've identified a situation where we're always checking module code even though we're in script mode, that should be a perf and correctness win. Please feel free to file an issue and open a PR addressing it so we can provide feedback! Thanks for coming back.

Mike Sherov

> On Apr 27, 2017, at 4:28 AM, KFRF <kfla...@gmail.com> wrote:
>
> Hi
>
> I will soon have time to look into esprima again. Or actually I did study the core because I'm developing my own open source parser.
>
> First thing I think would need an serious attention is the few places in the code where you have crossing code paths. I discovered that you in many of this places throws an error and blocking the other path. As an result of this you are also throwing an error and blocking the valid code.
>
> If I temporary comment out the blocker. The code passes just fine. This scenario are located in areas where you are checking for module code or future reserved words. And a few others.
>
> Another thing i discovered was your module code. Import and export should only run if module code. Not in sloppy mode.
>
> If you look at the specs it describes a "parseModuleItems. Same as found in V8.
>
> Probably a huge BC to correct this so maybe not worh it.
>
> Regards
>
> K.F
>
> --
> You received this message because you are subscribed to the Google Groups "esprima" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to esprima+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Mike Sherov]

You absolutely should publish it. Competition spawns innovation. And even after you publish it, you're help on Esprima would be greatly appreciated.

Mike Sherov

> On Apr 27, 2017, at 11:25 PM, KFRF <kfla...@gmail.com> wrote:
>
> Hi. I guess one week from now I can fix PR.
>
> BTW. I have already informed Acorn and now I'm informing the Esprima team. I made my own parser. It will blow the hat of your head due to it's performance and features. And if I publish it. We all know what will happen...
>
> I'm fragmented about a public release due to all great effort done in Esprima.
>
> Based on that I decided for now to help out on Esprima and will start to send PR soon.

[Mike Sherov]

There is a desire for help, which has been expressed many times, even in this thread. I can't be any clearer that the way to help is to file issues demonstrating a bug and then submit PRs that fix those issues. Your antics are getting really tiresome, so I won't be personally communicating on this topic further. Feel free to take that as a sign to help or not, it's your own time and you choose how to spend it.

On Tue, Sep 26, 2017 at 8:12 AM, KFRF <kfla...@gmail.com> wrote:

Understand from the lack of answer that there is no desire for help. So I withdraw the offer, and wish you all good luck with Esprima!

--
You received this message because you are subscribed to the Google Groups "esprima" group.

To unsubscribe from this group and stop receiving emails from it, send an email to esprima+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mike Sherov