-
Notifications
You must be signed in to change notification settings - Fork 15
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
Ruby wrapper for parser #60
base: master
Are you sure you want to change the base?
Conversation
Can you add some tests? |
subject { SymEngine::parse('123 + 321') } | ||
|
||
it { is_expected.to be_a SymEngine::Integer } | ||
it { is_expected.to eq 444 } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will be if there's erroneous/unparseable input? (And, BTW, what input, if any is considered erroneous or unparseable by symengine?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zverok I did think about that. In C++ code it will throw errors for unparseable code. Checking that may almost be equivalent to doing the parsing. There are 4 errors,
- Expected token!
- Invalid symbol or number!
- Mismatching parantheses!
- Operator inconsistency!
Catching the exceptions from the C++ code and throwing ruby exceptions will be covered in the weeks 9 and 10. So this issue will be solved then.
As of now, I wanted the tests to merely confirm that the Ruby wrapper is communicating successfully with the cwrapper. Actually the same idea was behind the matrix wrapper tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. I just always became suspicious when I see tests for success and not tests for fail :)
In fact, I always prefer to add empty contexts for such a deferred tests pathes, like this:
context "When there is parsing error" do
# TODO: will be covered on weeks 9-10
end
Though, I'm not insisting, currently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a quite nice way to make it clear!
I'll keep this as it is, because week 9 is just one week away from now, probably I will start working on it even earlier.
@isuruf can we merge this now, that the symengine/symengine#1044 has |
Can you resolve conflicts and add tests for parser errors? |
@@ -18,5 +18,16 @@ | |||
it { is_expected.to be_a SymEngine::Rational } | |||
its(:to_s) { is_expected.to eq '1/3' } | |||
end | |||
|
|||
describe 'parse' do | |||
subject { SymEngine::parse('123 + 321') } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since these specs act as documentation, can you add more strings for parsing?
eg.
x + (y * 3 - 5)
x ** y + f(x)
sin(x) + cos(y) / 2
1 / 2 + 3 / 2
1 + 2 * 2
tan(0) - sqrt(2)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to add a few more to this list
5+-3
5--3
All Without spaces
And
5++3
or something like this to raise an error.
@isuruf @abinashmeher999 please review. |
end | ||
|
||
it 'gives parse errors' do | ||
expect { SymEngine::parse('12a + n34a9') }.to raise_error(RuntimeError) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO the error message should be checked too since we don't have specific exception for ParseError
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not to add ParseError as a specific exception? That seems worthwhile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found just the thing that explains creating custom exceptions from Ruby C API: http://clalance.blogspot.in/2011/01/writing-ruby-extensions-in-c-part-5.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't have to create new exceptions.
SYMENGINE_RUNTIME_ERROR
-rb_eRuntimeError
SYMENGINE_DIV_BY_ZERO
-rb_eZeroDivError
SYMENGINE_NOT_IMPLEMENTED
-rb_eNotImpError
SYMENGINE_PARSE_ERROR
-rb_eSyntaxError
SYMENGINE_UNDEFINED
-rb_eFloatDomainError
?? (I'm not sure whatSYMENGINE_UNDEFINED
is. Is this supposed to be a Domain error?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I partially agree to the above. While RuntimeError
and ZeroDivisionError
should be used, our code atleast shouldn't raise NotImplementedError
and SyntaxError
. The latter ones are ScriptError
s and not StandardError
s.
This post explains why it would be abuse of NotImplementedError
. SyntaxError
is not a right fit since it is raised while encountering invalid Ruby code. If the user wants to handle a parse error, (s)he will have to handle SyntaxError
and that would also lead to unwanted silencing of the actual syntax error in the source code.
Also there is the technical problem that a rescue
clause by default only catches the StandardError
s. It is highly advised that custom application level exceptions be derived from StandardError
.
For SYMENGINE_UNDEFINED
it can be just StandardError
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just checked SciRuby/nmatrix repo and they use NotImplementedError
and IOError
(instead of SyntaxError
)
@certik @abinashmeher999 @isuruf should I make another PR to continue this work after the GSoC period? Because the submission guidelines asked not to change the submitted material after submission. Pls advice on this. |
I assume the submission guidelines mention about putting in the exact amount of work that was achieved during the GSoC period. That you have mentioned in the blog post already. As long as you are not changing the contents and the amount of work achieved, you won't be violating any rules. Correct me If I am wrong. You can keep the new exception making part for another PR. I think we can go ahead with merging this. Just a few more changes that have been suggested and we will be good to go. |
@rajithv, do you have time to finish this PR? If not, can you enable edits from maintainers? |
@rajithv ping. |
No description provided.