refactor: Cleanup git state - commit all staged changes
Major refactoring cleanup: - Add new controller architecture (class-controller-*.php) - Add new settings-v2 UI (views/settings-v2/) - Add new CSS architecture (agentic-sidebar.css, tokens) - Add esbuild build pipeline (scripts/build.js, package.json) - Add composer dependencies (vendor/) - Add frontend src directory (assets/js/src/index.jsx) - Add documentation files - Remove old/obsolete files (class-settings.php, old CSS) This commits all pending changes from previous refactoring efforts.
This commit is contained in:
43
vendor/parsica-php/parsica/docs/resources/01_development_status.md
vendored
Normal file
43
vendor/parsica-php/parsica/docs/resources/01_development_status.md
vendored
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: Development Status
|
||||
sidebar_label: Development Status
|
||||
---
|
||||
|
||||
|
||||
Parsica is early stage, so expect things to break all the time.
|
||||
|
||||
This is a rough wishlist of features to do before 1.0:
|
||||
|
||||
### Done
|
||||
|
||||
- [x] API Documentation
|
||||
- [x] All essential parsers
|
||||
- [x] Basic error messages
|
||||
- [x] PHPUnit tooling
|
||||
- [x] Recursive parsers
|
||||
- [x] Versioned documentation
|
||||
- [x] Essential combinators
|
||||
- [x] JSON parser
|
||||
- [x] Parser position in error messages
|
||||
- [x] Expression parser helpers
|
||||
- [x] Tutorial
|
||||
|
||||
### TODO
|
||||
|
||||
- [ ] Streaming input
|
||||
- [ ] Change the behaviour of or, add try and lookAhead
|
||||
- [ ] Better parser assertions
|
||||
- [ ] Better exceptions
|
||||
- [ ] Character categories
|
||||
- [ ] Comparison tests for canonical and performant implementations
|
||||
- [ ] Debug trees
|
||||
- [ ] Inliner
|
||||
- [ ] Lexer
|
||||
- [ ] Monoidal parser types
|
||||
- [ ] More [monad combinators](https://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Monad.html#v:-62--61--62-)
|
||||
- [ ] Other popular test frameworks
|
||||
- [ ] [Permutation phrases](https://www.cs.ox.ac.uk/jeremy.gibbons/wg21/meeting56/loeh-paper.pdf)
|
||||
- [ ] Parser state
|
||||
- [ ] Profiling & performance
|
||||
- [ ] Publish documentation in e-reader and pdf formats
|
||||
|
||||
83
vendor/parsica-php/parsica/docs/resources/02_performance.md
vendored
Normal file
83
vendor/parsica-php/parsica/docs/resources/02_performance.md
vendored
Normal file
@@ -0,0 +1,83 @@
|
||||
---
|
||||
title: Performance
|
||||
sidebar_label: Performance
|
||||
---
|
||||
|
||||
|
||||
At the time of writing, no effort has been made to measure the performance of Parsica. That doesn't mean it's slow; it means that we don't know yet. If you're going to use this on large amounts of data, do some profiling yourself first. Compute == carbon, and we'd like to keep this planet a little longer. You can help by contributing your profiling and optimisations.
|
||||
|
||||
We have some ideas that will allow us to make it very efficient, and we intend to do that before getting to a 1.0 release.
|
||||
|
||||
|
||||
## XDebug
|
||||
|
||||
Turn off XDebug, as it will make things much slower. If you do turn on XDebug, you may get `Maximum function nesting level of '256' reached, aborting!`. Increase the nesting level until the error goes away, either in code or in `php.ini`:
|
||||
|
||||
```php
|
||||
<?php
|
||||
ini_set('xdebug.max_nesting_level', '1024');
|
||||
```
|
||||
|
||||
```ini
|
||||
xdebug.max_nesting_level=1024
|
||||
```
|
||||
|
||||
## Recursion
|
||||
|
||||
If you encounter a "Maximum function nesting level" error, the more likely problem is that you're building a recursive parser incorrectly. Have a look at the documentation page about recursion to learn more.
|
||||
|
||||
|
||||
## Performance tips
|
||||
|
||||
Below we'll list some approaches to improve performance.
|
||||
|
||||
The actual difference in performance depends on many factors, so measure your parsers' performance to know if it is actually faster.
|
||||
|
||||
### Reusing parsers is faster than rebuilding them
|
||||
|
||||
Storing parsers in a variable or property is often faster than rebuilding them. Compare the these two equivalent parsers:
|
||||
|
||||
```php
|
||||
<?php
|
||||
$slow = between(
|
||||
choice(char('"'), char("'")),
|
||||
choice(char('"'), char("'")),
|
||||
atLeastOne(alphaNumChar())
|
||||
);
|
||||
|
||||
$quote = choice(char('"'), char("'"));
|
||||
$fast = between(
|
||||
$quote,
|
||||
$quote,
|
||||
atLeastOne(alphaNumChar())
|
||||
);
|
||||
```
|
||||
|
||||
### Use predicates over higher level combinators
|
||||
|
||||
Often, a combinator may be replaced with lower level combinators to get the same result faster. For example, the following parsers are equivalent, but the second one is a lot faster:
|
||||
|
||||
```php
|
||||
<?php
|
||||
$somePredicate = isDigit();
|
||||
$slow = zeroOrMore(satisfy($somePredicate));
|
||||
$fast = takeWhile($somePredicate);
|
||||
```
|
||||
|
||||
The reason is that `$slow` reads one token at a time, and then appends it to the previous tokens. `$fast` on the other hand, reads all the tokens until `$predicate` fails, and then returns them all at once.
|
||||
|
||||
## Backtracking is slower
|
||||
|
||||
If your parser parses a long input, only to need to backtrack the whole thing when it fails, it's going to be slow. A better alternative is to organise your usage of choice in a way that only small chunks of the input need to be backtracked.
|
||||
|
||||
```php
|
||||
<?php
|
||||
$parser = choice(
|
||||
atLeastOne(alphaChar())->thenEof(),
|
||||
atLeastOne(alphaNumChar())->thenEof()
|
||||
);
|
||||
$result = $parser->tryString("abc123");
|
||||
```
|
||||
|
||||
In this example, the choice parser parses "abc", fails on "1", backtracks, and then parses all of "abc123". If we switch the two parsers inside the choice parser, we are more likely to reach the end of the input without doing any backtracking.
|
||||
|
||||
38
vendor/parsica-php/parsica/docs/resources/03_naming_conventions.md
vendored
Normal file
38
vendor/parsica-php/parsica/docs/resources/03_naming_conventions.md
vendored
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: Naming Conventions
|
||||
sidebar_label: Naming Conventions
|
||||
---
|
||||
|
||||
|
||||
## String and Character
|
||||
|
||||
PHP doesn't have a separate type for strings and characters, as opposed to some languages where string is defined as a list of characters. Still, as a convention in Parsica and its documentation, we generally use `'a'`, `'1'` (single quoted) to indicate a single character, and `"a"`, `"abc123"` (double quoted) to indicate a string.
|
||||
|
||||
We also use single quotes to indicate constant strings or symbols, such as `'STATUS_SUCCESS'`;
|
||||
|
||||
|
||||
## Predicates
|
||||
|
||||
Predicates are either prefixed with `is` or suffixed with `pred`.
|
||||
|
||||
```php
|
||||
<?php
|
||||
$predicate = orPred(isEqual('5'), isEqual('6'));
|
||||
assertTrue($predicate('6'));
|
||||
```
|
||||
|
||||
## Character Parsers
|
||||
|
||||
A parser for a single character is always suffixed with `Char`, as in `digitChar()`. These always output a string.
|
||||
|
||||
## Case
|
||||
|
||||
Some parsers have case-insensitive versions. These are sufficed with 'I'.
|
||||
|
||||
```php
|
||||
<?php
|
||||
$parser = stringI('hello world');
|
||||
$result = $parser->tryString("hElLO WoRlD");
|
||||
assertEquals("hElLO WoRlD", $result->output());
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user