mori0091 / cparsec2 Goto Github PK
View Code? Open in Web Editor NEWCPARSEC2 - a parser combinator library for C language
License: MIT License
CPARSEC2 - a parser combinator library for C language
License: MIT License
What's happen? Please describe the problem you met.
For skip1st(p1, p2)
, at the present, both p1
and p2
must be a CharParser
.
I hope it will be more generic function.
Describe the solution you'd like
For skip1st(p1, p2)
, each p1
and p2
may be a one of the following type of:
CharParser
StringParser
IntParser
For example:
parseTest(skip1st(char1('a'), string1("bc")), "abc"); // -> results (const char*)"bc"
parseTest(skip1st(string1("ab"), char1('c')), "abc"); // -> results (char)'c'
Describe alternatives you've considered
Additional context
Describe the bug
Cannot compile test/src/test_list.cpp
To Reproduce
# on Mingw64 w/ gcc 8.3.0
./build -s
Expected behavior
Build and test should be completed successfully.
Development environment (please complete the following information):
Additional context
nullptr
is recommended instead of NULL
in modern C++.
What's happen?
We found that code coverage of some files are not reported, such as 'example/calc/src/main.c'.
What's expected?
Coverage of the projects' whole source code should be reported.
How to reproduce
See also CodeCov coverage report, and CircleCI report of 'coverage' task.
Further info (if available)
Maybe gcov
is confused, since :
make
is executed at for each (sub-)project directory.Proposal (if available)
Shall we fix the GNUmakefile rules like as follows ?
For example in case of line 58 of GNUmakefile:
@$(CC) $(CFLAGS) -c -o $@ $<
@$(CC) $(CFLAGS) -c -o $@ $(realpath $<)
Describe the bug
Should update API Reference relative to #46
To Reproduce
Specification of macros for "Building block of Parser-combinators" are changed.
But docs is not updated.
Expected behavior
New spec. of macros should be described in docs/API.org
Development environment (please complete the following information):
Additional context
Describe the bug
runParser(p, input)
API returns broken result or causes crash, on MINGW environment.
To Reproduce
The following sample code fails on MINGW, though it passes on Ubuntu or MSYS.
Checkout the following branch, and do make test
in bug/bug_20190925 sub-folder:
https://github.com/mori0091/cparsec2/tree/bug/runParser_returns_broken_result
/* -*- coding: utf-8-unix -*- */
#include <assert.h>
#include <cparsec2.h>
int main(void) {
cparsec2_init();
{
/* the below should pass but fails */
ParseResult(Char) r = runParser(anyChar, "abc");
assert(r.consumed == 1);
assert(r.succeeded);
assert(r.ok == 'a');
}
cparsec2_end();
return 0;
}
Expected behavior
runParser(p, input)
should return correct result.
Development environment (please complete the following information):
Additional context
(1) CPARSEC2's self-test (src/main.c) was passed.
(2) But the sub-project (bug/bug_20190925/src/main.c) failed.
Note that (2) is same code as one of the test defined in (1).
Describe the bug
The following APIs were changed at #38 , but not reflected to docs.
To Reproduce
See Building block of Parser-class section of docs/API.org
Expected behavior
At least the following contents should be described and/or updated:
Development environment (please complete the following information):
Additional context
Maybe some macros (such as TYPEDEF_xx, DECLARE_xx, DEFINE_xx, GENERIC_xx, and other relative macros) should be described in another document.
Because these APIs are for developer of CPARSEC2 library, not for users of CPARSEC2 library at the present.
Describe the bug
./build.sh clean
fails on WSL due to obj/*.d
, which have been generated on Mingw64
(see also #9)
To Reproduce
NOTE: Supposing that the git
's working-copy is shared by Mingw64 and WSL.
./build.sh
on Mingw64./build.sh clean
on Ubuntu18.04 (WSL)make
command causes an error like as follows:obj/seq.d:1: *** target pattern contains no '%'. Stop.
obj/seq.d
generated on Mingw64:
obj/seq.o: C:/msys64/home/mori0091/cparsec2/src/seq.c \
include/cparsec2.h
Expected behavior
./build.sh clean
(i.e. make clean
) should clean up all artifacts successfully, even if it was a artifact generated on different environment.
Development environment (please complete the following information):
I'm using the following environments on Windows10:
Additional context
All the above environments shares git
's working-copy.
But its file-path is different each other. For example:
/home/mori0091/cparsec2
on Msys / Mingw64/mnt/c/msys64/home/mori0091/cparsec2
on Ubuntu on WSLAnd $(realpath ...)
function of GNU make
produces such as
/home/mori0091/cparsec2
on MsysC:/msys64/home/mori0091/cparsec2
on Mingw64 ๐/mnt/c/msys64/home/mori0091/cparsec2
on Ubuntu on WSLTherefore make
on WSL is confused due to *.d
which is generated on Mingw64.
Describe the bug
Relative to #28
Description of some parser-combinators should be updated.
many(p)
(refactored at #31)many1(p)
(refactored at #31)seq(p, ...)
(refactored at #32)cons(p, ps)
(refactored at #34)To Reproduce
See API docs.
Expected behavior
The above four parser-combinators are now a generic parser-combinator.
Supporting type of its arguments and return value (parser) should be described.
Development environment (please complete the following information):
Additional context
Describe the bug
Some file's coverage seems wrong.
To Reproduce
Steps and/or code snippet to reproduce the behavior:
For example, 'src/oneOf.c'.
It is tested by 'test/src/test_oneOf.cpp', but CodeCov says its coverage is 0%.
Expected behavior
All test result must be reflected to the coverage report.
Development environment (please complete the following information):
Additional context
Maybe this is a usage issue of gcov
.
When and where the gcov
should be executed?
What's happen? Please describe the problem you met.
README seems too larger.
Shall you divide it into some sub-documents in docs folder?
Describe the solution you'd like
Here is my suggestion, for example:
Describe alternatives you've considered
Additional context
What's happen? Please describe the problem you met.
The spec of number
built-in parser is unclear.
Describe the solution you'd like
Please add description of number
built-in parser to docs/API.org
Describe alternatives you've considered
Additional context
Proposal:
Token
typeToken token(int type, PARSER(T) p
with R token(PARSER(T) p)
R
is the result type of parse(p, src, ex)
token(p)
return a parser, which skip any leading white-spaces and return the result of p.Reason why:
After We wrote the sample app example/calc, we noticed that:
parse(spaces, src, ex)
Token
and token(type, p)
is useless.token(p)
is simpler, easy to use, and enough, we think.What's happen? Please describe the problem you met.
A generic parser-combinator (such as either(p1, p2)
) is not tested for PARSER(Int).
To test it, we need to implement a parser of PARSER(Int) type everytime...
Describe the solution you'd like
Supports a built-in parser of PARSER(Int) type.
For example, PARSER(Int) number
which parses one or more digits and returns an integer.
If such one was available, we can use it to write testcase for a generic parser-combinator.
(and also to keep coverage higher)
Describe alternatives you've considered
Additional context
It is appreciate if there is more variation of examples. (in example
folder)
For example :
+
and -
binary operator*
and /
binary operator(
expr
)
expression grouped by parensDescribe the bug
Some test-case's name are misleading or confusing. (Perhaps garbage of copy & paste is left)
This is not a bug, but should be corrected.
To Reproduce
See 'test/src/test_oneOf.cpp' and 'test/src/test_noneOf.cpp'.
There is some misleading GIVEN("...")
clause, for example:
GIVEN("an input: \"a\" (i.e. SPC)") {
... snip ...
}
What means "(i.e. SPC)" ? Isn't it garbage of copy & paste ?
Expected behavior
All such GIVEN(...)
clause should be fixed as follows:
GIVEN("an input: \"a\"") {
... snip ...
}
Development environment (please complete the following information):
Additional context
test/src/test_oneOf.cpp
has 4 such same issue.test/src/test_noneOf.cpp
has 4 such same issue.We would like to add explanation and sort out about concept.
What's happen? Please describe the problem you met.
There is non-generic parser-combinators, though it should be generic, such as for example many(p)
.
To make it more generic, we need List(T)
, a generic list container, and PARSER(List(T))
.
For example:
PARSER(List(Int)) p = many(number); // NOTE: `number` is a PARSER(Int)
List(Int) xs = parse(p, src, ex); // xs is a list of int
Describe the solution you'd like
We need a generic container List(T)
, and parser-class PARSER(List(T))
.
And List(Char)
should be same as const char*
if possible.
Describe alternatives you've considered
There is two major design of List container:
I think "C++ STL like List" is better for C, because iterating a container by loop is better than recursive function call, in case of C/C++.
Additional context
To keep simple API, maybe it's better to define two set of APIs:
Codacy is working fine for static code analysis, but its result is not shown on GitHub.
Because Codacy badge written in README.org
do not work.
We need following two parser combinators :
or(p1, p2)
:
p1
's result if p1
success, orp1
consumed one or more chars and failed, throw p1
's errorp1
consumed no chars and failed, return p2
's result or throw p2
's error tryp(p)
:
p
if p
success,p
's error.Describe the bug
Some parser-combinators should support PARSER(List(String)) and PARSER(List(Int))
To Reproduce
For example:
PARSER(List(Int)) p1 = tryp(many(number)); // compile error
PARSER(String) digits = token(many1(digit));
PARSER(List(String)) p2 = token(many(digits)); // compile error
PARSER(List(Int)) p3 = skip1st("++", many(number)); // compile error
PARSER(List(Int)) p4 = either(many(number), skip1st("++", many(number))); // compile error
Expected behavior
The above four parser-combinators should support List(String) and List(Int).
And should be tested for List(String) and List(Int). (including above example code and more)
Development environment (please complete the following information):
Additional context
Describe the bug
Description of cons(p,ps)
seems wrong.
To Reproduce
See the description of cons(p, ps)
:
Create a parser of PARSER(List(T)) type, which
- apply
p
and parsers in the listps
to a text.- return a list consists of the result of
p
and results of each parsers inps
.- if any parser failed, throws an error of it.
The 2nd argument ps
is not a list but a parser which returns a list.
Expected behavior
The description should be corrected as follows for example:
cons(p, ps)
creates a parser
p
andps
.Development environment (please complete the following information):
Additional context
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.