In the last blog post I reported that lambdify function was fully wrapped. Yes, that’s what I thought at the time! But it did indeed dragged on quite a bit, requiring many changes, which were very educative for me in terms of how Ruby looks at user experience. Several changes were done, including structural changes on calling lambdify, and for supporting older Ruby versions. The really interesting and long discussions on this can be viewed in the PR 61.
Apart from that, simultaneously I started reading and exchanging ideas on exception handling. It was agreed that in the C wrappers, an error code to be returned, which can be accessed from the Ruby wrapper, which in turn can raise a Ruby exception. The preliminary model can be seen in PR 1044 in SymEngine and PR 64 in SymEngine Ruby wrapper.
Right now any exception is caught and sent to the Ruby Wrapper with an error code of -1, which raises a generic Runtime Error in Ruby. Although not very informative, this is helpful in prevention of crashing the Ruby runtime.
To illustrate, when the following code (a division by zero) is run before and after is shown.
irb(main):001:0> require 'symengine' => true irb(main):002:0> x = SymEngine(1) => #<SymEngine::Integer(1)> irb(main):003:0> y = SymEngine(0) => #<SymEngine::Integer(0)> irb(main):004:0> x/y terminate called after throwing an instance of 'Teuchos::NullReferenceError' what(): /home/rajith/Development/symengine/symengine/utilities/teuchos/Teuchos_RCPNode.cpp:720: Throw number = 1 Throw test that evaluated to true: true Teuchos::RCP<SymEngine::Basic const> : You can not call operator->() or operator*() if getRawPtr()==0! Abort caught. Printing stacktrace: Traceback (most recent call last): Done.  590 abort (core dumped) irb
irb(main):001:0> require 'symengine' => true irb(main):002:0> x = SymEngine(1) => #<SymEngine::Integer(1)> irb(main):003:0> y = SymEngine(0) => #<SymEngine::Integer(0)> irb(main):004:0> x/y RuntimeError: Runtime Error from (irb):4:in `/' from (irb):4 from /usr/bin/irb:11:in `<main>' irb(main):005:0>
This is a good improvement overall, but as it’s nicer to have a more descriptive error shown to the user, that part will be the continuation of exception handling during the 10th week.
See you next week!