[SpiceRub] Day 1

[Gaurav Tamba]

Dear Mentors,

The repository is up at https://github.com/gau27/spicerub ! Looks a little bare right now but this week itself should see it filling up a lot.

First, a general question for everybody : What do you guys think of the name? I had considered RSpice but I like the sound of SpiceRub (does this make you smile positively or in a *shake your head* sort of way? :) ) In the immediate next few days it'd be easy to change the gem name so I'd love any better suggestions albeit soon.

I feel that it may be a bit unusual to have meaningful specs for Kernel loading functions right now, so I'll start with getting the extension glue working.

Is the current gem directory structure all right? Here's what I'm going for :-

/bin/cspice.a     [Main CSPICE binary linkable, distribution will be a problem for a later week]

Optionally, the above binary could be in /ext/include as some header files may be required during compile + link phases so placing them all in there would make sense instead of specifying different library paths.

/lib/spicerub      [Will contain the KernelHandler class and other Ruby classes]..

/lib/spicerub.rb  [Autoload all required files]

/ext/spicerub/extconf.rb [Generates the right makefile for compilation, playing with the best way to link this right now]

I'm thinking that the Ruby interface should be the only way to load Kernels since Kernels are tracked by global variables in CSPICE and there may be some complications if we enable more than one way of loading them due to thread safety, etc.

Regards,

Gaurav

[Victor Shepelev]

Hi Gaurav

Congratulations about the start of the work!

Gem name looks ok to me.

Directory structure is not quite.

bin/ folder in gems, despite the name, is for executable files, not any binary libraries: those should strictly go to ext/.

And there is one more question about naming: "Kernel" from SPICE terminology have a collision with Ruby's core module, what are you planning to do about it?..

V.

--
You received this message because you are subscribed to the Google Groups "SciRuby Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sciruby-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gaurav Tamba]

Dear Victor,

Thank you for pointing that out, I will rectify my design accordingly.

As for the Kernel name clashes, I was hoping that making the class names something like "KernelLoader" would be appropriate and avoid clashes with any core modules while not obscuring important SPICE terminology.

Regards,
Gaurav

[Shaun Stewart]

Is he concerned that KernalHandler may already be used by Ruby's core module?

Sent from my iPhone

On May 23, 2016, at 5:57 AM, Gaurav Tamba <gaurav...@gmail.com> wrote:

[John Woods]

I think the name is excellent. Most clever.

I agree with Victor. There are a couple of different ways to generate your binaries and shared objects, but most of them involve Rake::ExtensionTask, and that means using the rake-preferred ext/ directory structure. It may be that things will be put in bin/, but don't spend too much time trying to fool rake into doing something non-standard. It'll just be confusing for people if you succeed.

John

[John Woods]

I think KernelHandler is okay. It's also probably allowable to do SpiceRub::Kernel, but I think the collision with ::Kernel could be confusing.

Shaun: http://ruby-doc.org/core-2.2.3/Kernel.html

John

[Rajith Vidanaarachchi]

Hi Abinash,

I wanted to update you and the community on the work on Day1. I'm yet to finish work for Day 1, but thought better to send the update before the end of the calendar day!

According to my proposal, this week and the next the task would be to wrap Complex and Floating point numbers.

I started on adopting the Complex numbers first. Initially, with a very simple test,

[Abinash Meher]

Hi Rajith,

That's great! I appreciate you taking time to update us about the progress.

Also since this is a public channel, I guess most of the subscribers would prefer the updates to be on a single thread.

About debugging, yes that's true. Finding the C code segment where it went wrong is tough. I had followed the usual way of commenting and uncommenting the code. I am sure there are better ways. I had opened up an issue to discuss how to detect memory leaks. There are some links there where you might find some tips. I will see if I can find something.

[Rajith Vidanaarachchi]

Hi Abinash,

Update for Day 2. (I'm sending in the same thread, so as not spam the whole community)

I solved the problems from yesterday. I used rb_p statements to print while debugging, and it was okay. And the work is in the PR 39.

I had some memory issues, but it was solved. This lead to fixing issues 19 and 21 as well. Most of the things needed for the complex numbers are still there.

Lastly, I realized the constant "i" hasn't been wrapped, so quickly wrote that as well.

Now, something like this would work:

2.1.8 :001 > x = Rational('2/5')
 => (2/5) 
2.1.8 :002 > y = Rational('3/7')
 => (3/7) 
2.1.8 :005 > X = SymEngine::sympify(x)
 => #<SymEngine::Rational:0x8e71f8c> 
2.1.8 :006 > Y = SymEngine::sympify(y)
 => #<SymEngine::Rational:0x8deb8ec> 
2.1.8 :007 > i = SymEngine::I
 => #<SymEngine::Constant:0x8ec7ec8> 
2.1.8 :008 > Z = X + i*Y
 => #<SymEngine::Complex:0x8de25a8> 
2.1.8 :011 > Z = Z - i*Y
 => #<SymEngine::Rational:0x8dd7f18> 

Also this is working:

2.1.8 :006 > a = 2 + 0i
 => (2+0i) 
2.1.8 :008 > A = SymEngine::sympify(a)
 => #<SymEngine::Integer:0x84f38fc> 
2.1.8 :009 > a.class
 => Complex 
2.1.8 :010 > A.class
 => SymEngine::Integer 

Btw, are there other functions to be wrapped in Rational / Complex classes? And please let me know your ideas as well.

Cheers,
Rajith

[Rajith Vidanaarachchi]

Sorry, I pressed send by mistake.

a = Complex(2, 3)
a = SymEngine::Complex.new(a)
expect(a).to be_a SymEngine::Complex
expect(a.to_s).to eq('2+3i')

I got into an error which I'm still trying to solve, as discussed in the conversation here.

This brought up a question on what's the best way to debug the Ruby Wrappers? The errors would only give the ruby function which throws the error, but finding the code segment which makes the error in the C code is quite difficult. Do you have any tips on that?

Also, Isuru mentioned (in the above conversation) about this issue in the Rational class. Solving that issue would overcome the error I encountered, and help both Rational and Complex classes. I'm now working on that. 

Regards,
Rajith

[Rajith Vidanaarachchi]

Hi Abinash,

Day 3
--------

Today also I worked on the complex number wrapping.

First, I made the complex numbers which are not using rational real and imaginary parts to be supported by sympify.
Then, some minor edits were done in order to facilitate the tests on Ruby versions <= 2.0 .
to_c method was also implemented to convert SymEngine::Complex to Ruby Complex.

Also, on SymEngine, I wrote the wrappers for the Real Doubles. I will soon send a PR for this.

After the tests are done, and the real_part and imaginary_part are wrapped. we can move on to the floating points and come back for the Complex Doubles. I have written / figured out some parts already.

Regards,
Rajith

[Abinash Meher]

Great, thanks for the update.

[Rajith Vidanaarachchi]

Day 4
---------

Sorry for the late update. I'm sending this from mobile, and will be short.

Basically yesterday I worked on both the cwrappers and ruby wrappers. I believe you saw the changes in the respective PRs.

The appveyor fails in .rb because of a version issue with the main repo. I tried by having the hash of the latest commit but it didn't work. I will have to figure it out today. Also will be looking at the new spec formats to familiarize my self and to rewrite the complex spec.

Regards,
Rajith

[Sameer Deshmukh]

Rajith can you move your updates out of the spicerub thread? Also link to your repos/PRs whenever you mention them here.

[Rajith Vidanaarachchi]

um... I haven't sent any mails to the spicerub thread. :/ I'm confused.

[Sameer Deshmukh]

This is weird it's showing up here.

[Rajith Vidanaarachchi]

Hi Abinash,

Today's update:

I have recovered my system successfully and we are back on track according to the schedule, and mpfr, mpc and functionsymbol classes are almost finished. I think it can be merged tomorrow, after reviews and tests.

Apart from that I will get eval functions wrapped tomorrow as well. This was not on schedule but, I think it's quite useful to have it. Also as we are postponing polynomials and series, it is only fair that I work on something else.

Starting next week it's possible to move on to the matrices.

Regards,

Rajith 

--

Rajith Vidanaarachchi | රජිත් විදානආරච්චි

[Rajith Vidanaarachchi]

Hi Abinash,

The new blog post was written (most of the updates are there), and as for development, most of the hanging work is tied up, the only thing left is having a format for SymEngine::FunctionSymbol.new(), which is similar to the Python version. I was reading on how to wrap the eval functions, and it seems to be more complicated than I first thought. I wrote more about this in the blog post too. Will start coding on that one tomorrow, while starting to read on matrices implementations.

Regards,

Rajith

[Victor Shepelev]

Rajith, can you please provide a link to your blog post?

Or isn't it published yet?

V.

[Rajith Vidanaarachchi]

Hi Victor,

Wek 3 blog post : https://rajithsays.wordpress.com/2016/06/12/gsoc-wek-3-progress/

My GSoC related posts are at : https://rajithsays.wordpress.com/category/symengine/

Rajith

[Rajith Vidanaarachchi]

Hi Abinash,

Today I was working on eval function, the tests and the Ruby wrapper remains to be coded. I started the PR #987 for this.

Also, I was thinking about the NMatrix implementation. Maybe SciRuby guys can help me with figuring out some stuff for this.

Is the stype for Sparse matrices, "yale"? Dense matrices are clear to be "dense". I am not sure about "list" etc. Basically in SymEngine, there are two types. SparseMatrix and Dense matrix. How should the mappings be done?

Also, I was thinking of the Ruby code behaving as following:

m = N[ [2, 3, 4], [7, 8, 9] ]

mat = SymEngine::DenseMatrix.new(m)

mat.class # gives "SymEngine::DenseMatrix"

Would love to know comments before I actually start wrapping them.

Regards,

Rajith

[Sameer Deshmukh]

Dear Rajith,

So nmatrix has two kinds of sparse matrix types - list and yale. The list type stores data in the form a C linked list and yale is a bit different storing indexes and elements as arrays (see this resource).

How do you plan to interface with nmatrix? If it will happen directly via ruby then it's not issue since the Ruby API is very capable of handling all sorts of matrix types (read up the wiki pages). However, if you plan to interface symengine via the C API, the sparse matrix types might be a bit of a problem since there's no standard way of creating a sparse matrix through the C API yet. To get a full glimpse of the nmatrix C API go through the nmatrix.h file.

[Rajith Vidanaarachchi]

Hi Abinash,

Quick Update for today:

The Ruby Wrappers for evalf is now complete with the specs. (I just sent a PR)
The CWrapper is also complete with the tests.
The C++ tests are giving some trouble still, but the I am sure the code is working, because the wrappers work under various input. Also, three test cases are failing on Travis, so I will have to look into it.

In the meanwhile, I have thought on going ahead with the interface for the NMatrix through Ruby. Will update you on how it's going tomorrow.

Regards,

Rajith

[Rajith Vidanaarachchi]

Hi ,

The week #4 progress blogpost is here; https://rajithsays.wordpress.com/2016/06/19/gsoc-week-4-progress/

Regards,

Rajith

[Rajith Vidanaarachchi]

Hi,

I got some progress with the Matrices today. After trying a couple of approaches, the allocations seem to be going good now. The only problem I had was that, since MatrixBase is an abstract class, I had to use a separate wrapping Data Structure for DenseMatrix. (I didn't do SparseMatrix yet, but I will have to write another for that.)

I plan to get the constructors to work by tomorrow (at least excluding NMatrix one). As I wrote in the blogpost, the planned out constructors are as follows:

mat = SymEngine::DenseMatrix.new()
mat = SymEngine::DenseMatrix.new(SymEngine::DenseMatrix)
mat = SymEngine::DenseMatrix.new(NMatrix)
mat = SymEngine::DenseMatrix.new(Array)
mat = SymEngine::DenseMatrix.new(no_rows, no_columns)

Please let me know if this is okay to go ahead with.

Regards,

Rajith

[Rajith Vidanaarachchi]

Hi,

Today's progress was good. I wrapped 4/5 constructors from what I've planned. The NMatrix one is remaining.

Tomorrow I plan to wrap the __str__ for the MatrixBase, so that debugging will be easier after that. While keeping NMatrix aside for a while, I thought of wrapping the SparseMatrix as well, and move on to some of the Matrix operations.

Now that the foundation for Matrices is there a considerable part of the matrices would be ready by this weekend.

Regards,

Rajith

[Rajith Vidanaarachchi]

Hi,

Today I wrapped SparseMatrix, __str__, getters and setters and several other methods for Dense Matrices.Will continue wrapping other matrix functions tomorrow.

Regards,

Rajith

[Rajith Vidanaarachchi]

Hi Abinash,

The blog post for week #5 is available at : https://rajithsays.wordpress.com/2016/06/26/gsoc-wek-5-progress/

In summary, yesterday and today I wrapped several functions:

DenseMatrix.get(row, col)
DenseMatrix.set(row, col, SymEngine::Basic)
DenseMatrix.inv
DenseMatrix.det
DenseMatrix.transpose
DenseMatrix.submatrix(row_start, col_start, row_end, col_end, row_step, col_step)
DenseMatrix.rows
DenseMatrix.cols
+ operator for Matrix and Scalar addition
* operator for Matrix and Scalar addition
DenseMatrix.to_s
DenseMatrix.inspect

5 more are left to be wrapped from DenseMatrix which I'm doing tonight. Next week I should be able to finish everything by wrapping SparceMatrix methods and writing the tests.

Also, I have the following questions:

1. Should the - and ** operators be implemented as well? (The C++ API does not provide this directly). In case I'm implementing it, should it be at CWrapper level or Ruby level?

 

2. Should we also implement a to_array function? I was wondering whether that would be useful..

3. Should I have 2D arrays (and NMatrix objects) be converted (sympified) to DenseMatrix type with convert() function? I think this would be quite useful.

Regards,

Rajith

[Abinash Meher]

Hi Rajith,

Please see my replies inline.

Regards,

Abinash Meher

On Mon, Jun 27, 2016 at 12:40 AM, Rajith Vidanaarachchi <rajith.vid...@gmail.com> wrote:

Hi Abinash,

The blog post for week #5 is available at : https://rajithsays.wordpress.com/2016/06/26/gsoc-wek-5-progress/

In summary, yesterday and today I wrapped several functions:

DenseMatrix.get(row, col)
DenseMatrix.set(row, col, SymEngine::Basic)
DenseMatrix.inv
DenseMatrix.det
DenseMatrix.transpose
DenseMatrix.submatrix(row_start, col_start, row_end, col_end, row_step, col_step)
DenseMatrix.rows
DenseMatrix.cols
+ operator for Matrix and Scalar addition
* operator for Matrix and Scalar addition
DenseMatrix.to_s
DenseMatrix.inspect

5 more are left to be wrapped from DenseMatrix which I'm doing tonight. Next week I should be able to finish everything by wrapping SparceMatrix methods and writing the tests.

Also, I have the following questions:

1. Should the - and ** operators be implemented as well? (The C++ API does not provide this directly). In case I'm implementing it, should it be at CWrapper level or Ruby level?

They will be good to have. If you are trying to implement it the most DRY way to do it will be in the C++ API. That's not a priority so you can raise issues in the symengine repo and comeback to it when you want to. I am for doing it in C++ is because there is no meaning of doing it in the Cwrapper. CWrapper is all glue code and implementations shouldn't be a part of it. But if there is some implementation that is specific to the Ruby interface then it can go to either the Ruby C API code or the Ruby code. If it's a temporary implementation that is much likely to be turned obsolete by a similar one in the C++ API I would do it in Ruby code.

 

2. Should we also implement a to_array function? I was wondering whether that would be useful..

Do you have any use cases where that would be useful? Having a to_array method will need to have a way to decide row-major order and column-major order too (which can be done by arguments). 

3. Should I have 2D arrays (and NMatrix objects) be converted (sympified) to DenseMatrix type with convert() function? I think this would be quite useful.

Yes, it will be indeed! This should be prioritized earlier than the other features.

[Rajith Vidanaarachchi]

Hi Abinash,

I wasn't able to update much in the past couple of days due to some personal issues. But I tried to do at least a little bit each day.
Anyhow, I'm back on working and am left with doing the tests, on which I got started today. I will write the blog post for the past week as soon as possible as well.

Thanks for the patience.

Regards,

Rajith

[Rajith Vidanaarachchi]

Hi,

I've written the blog post for weeks 6 & 7 here:
https://rajithsays.wordpress.com/2016/07/09/gsoc-weeks-6-7-progress/

I managed to catch up with the most part of the work during this week. There's a few issues with the Matrix Ruby Wrapper which I'll get to asap.

I'm guessing I can wrap the lambdify in less than a week, so I will start on the exception handling within the next week as well.

Regards,

Rajith

[Rajith Vidanaarachchi]

Hi,

I was working on exposing the lambdify functions to Ruby today.

I remembered this issue (https://github.com/symengine/symengine.rb/issues/35) and considered both options discussed.

1. Expose symengine's lambda_double which can output a double

For this, exposing the function is quite straight forward.
But I couldn't find how to return a cfunction pointer to the ruby interface as a lambda.

2. 2. Extend StrPrinter to print Math.cos instead of cos



For this method, the StrPrinter will be extended for a Ruby Printer, which prints the Ruby Equivalent to the SymEngine basics.
i.e. Rational(3,2) for 3/2 etc. and the functions sin, cos etc as Math.sin, Math.cos etc.



After that, calling eval on the generated string is quite straight forward.



Here, a problem I encountered was on defining lambdas with variable number of arguments. I was thinking of sending an array of values to the lambda funciton. i.e. Lambda.call( [var1, var2, etc...] )




I'm hoping to hear from you guys possible alternatives to both options, and issues you see with the approaches.


I'm currently leaning towards Option 2, because of the problem of returning the cfunction through ruby as a lambda in option 1.

Regards,

Rajith

[Victor Shepelev]

As far as I can understand, the problem is:

We have SymEngine expression like `sin(x) * 5 - cos(y)^2 * 10` and we want the Ruby lambda, evaluating the results, am I right?

Then, we can just do something like makin a string "lambda{|x,y| Math.sin(x) * 5 - cos(y)**2 * 10}", can't we? We know all the variables in expression, and the expression itself can be formatted into string, so it is kinda straightforward?..

I think, we can even have a map of SymEngine function to Ruby function somewhere, (mapping sin to Math.sin, and, for ex, raising exception or making several complicated functions when Ruby's libraries have no equivalent).

[Rajith Vidanaarachchi]

Thanks Viktor,

I did not realize that I can send the whole lambda in the string.
(I was trying as follows: my_lambda = lambda {|x, y| eval("x + y")} .. so that's why I was stuck)

The symengine, to ruby mapping needs some tweaks, such as Rationals. i.e 3/2 would be taken as ints, resulting in 1), so they need to be converted to a format like  "Rational(3,2)".

I guess the complicated functions you mentioned can be solved with a call to symengine's evalf function in most cases.

I think I'm good to go with this info at hand. Will update on the progress.

Regards,

Rajith

[Rajith Vidanaarachchi]

Hi all,

Blogpost for this week: https://rajithsays.wordpress.com/2016/07/16/gsoc-week-8-progress/

When looking at catching exceptions (for next week), I found this to refer to: https://github.com/symengine/symengine/issues/418

Would be grateful to know any other tips on re-raising C++ exceptions in the Ruby C API too.

Regards,

Rajith

[Will Levine]

Hi Rajith,
Just a warning about a potential pitfall: if you use rb_raise() to
raise a Ruby exception from within C/C++ code, be very careful:
rb_raise() basically functions like a goto (using setjmp/longjmp) and
will skip all of your cleanup code. Memory will not be deallocated,
destructors will not be called, etc. This has caused some problems in
NMatrix. You can get away with using rb_raise() if you are careful,
but basically it's a lot cleaner to raise Ruby exceptions from within
Ruby code rather than from C/C++ code.

I like the solution proposed in the bug you linked: catch C++
exceptions in your C wrappers, indicate the error by returning an
error code, then check the error code and raise a Ruby exception if
necessary. It's annoying to have to check error codes, but I don't see
a better way to do it.

On Sat, Jul 16, 2016 at 12:21 PM, Rajith Vidanaarachchi

[Rajith Vidanaarachchi]

Hi,

Thanks for the info.

I will be careful with rb_raise(). I believe I'm using rb_raise already in some of the code, I'll review them to make sure that memory is deallocated properly.

- Rajith

[Rajith Vidanaarachchi]

Hi guys,

The blog post for this week can be found here : https://rajithsays.wordpress.com/2016/07/24/gsoc-week-9-progress/

The exception handling basically works right now, but I need to make the exceptions thrown in ruby to be more descriptive. So I will be working on that next week (Making proper exceptions in the C++ code, right now, std::runtime_error is used for everything). Looks like exception handling part can be finished on time.

Regards,

Rajith

[Rajith Vidanaarachchi]

Hi,

I have been away from home for this week, and will be returning this Sunday. Although I couldn't put together a lot of work this week, I managed to wrap up Exception Handling on SymEngine today. (I will compensate for the lost week after the GSoC period).

About the wrap up plan, I hope to wrap up Exceptions and Matrices on both SymEngine and SymEngine.rb repos by the end of the GSoC.

I have to write a couple of more blog posts too, will also do that on Monday.

Regards,

Rajith

On Mon, Jul 25, 2016 at 12:02 AM, Rajith Vidanaarachchi <rajith.vid...@gmail.com> wrote:

Hi guys,

The blog post for this week can be found here : https://rajithsays.wordpress.com/2016/07/24/gsoc-week-9-progress/

The exception handling basically works right now, but I need to make the exceptions thrown in ruby to be more descriptive. So I will be working on that next week (Making proper exceptions in the C++ code, right now, std::runtime_error is used for everything). Looks like exception handling part can be finished on time.

Regards,

Rajith

>>> <rajith.vidanaarachchi@gmail.com>:

>>>>>>>>>>>>>> it, send an email to sciruby-dev+unsubscribe@googlegroups.com.

>>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "SciRuby Development" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send

>>>> an email to sciruby-dev+unsubscribe@googlegroups.com.

>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "SciRuby Development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an

>>> email to sciruby-dev+unsubscribe@googlegroups.com.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "SciRuby Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to sciruby-dev+unsubscribe@googlegroups.com.

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

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

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

[Rajith Vidanaarachchi]

Hi guys,

I have written a wrap-up blog post for submission to GSoC.
https://rajithsays.wordpress.com/2016/08/19/gsoc-epilogue/

Please let me know your ideas. (I will update the blogpost until I submit it on 22nd Monday)

I am hoping to complete the Exception Handling Ruby Wrapper code by tonight (just have to add some tests there), which will also enable the Parser Ruby Wrapper to be merged.

Then the only code which will stay unmerged will be in the Matrix Ruby Wrapper PR. Realistically, this will be hard to get merged before the deadline on the 23rd. But I will continue work on it, as I'm free.

Regards,

Rajith

On Fri, Aug 12, 2016 at 9:40 PM, Rajith Vidanaarachchi <rajith.vid...@gmail.com> wrote:

Hi,

I have been away from home for this week, and will be returning this Sunday. Although I couldn't put together a lot of work this week, I managed to wrap up Exception Handling on SymEngine today. (I will compensate for the lost week after the GSoC period).

About the wrap up plan, I hope to wrap up Exceptions and Matrices on both SymEngine and SymEngine.rb repos by the end of the GSoC.

I have to write a couple of more blog posts too, will also do that on Monday.

Regards,

Rajith

[Abinash Meher]

Hi Rajith,

The report looks very well organised. It shows how much of time and effort you have put into the project. Great work! A couple of improvements that I would like to suggest are:

• Adding the complete text of the links in the table is unnecessary. You can just abbreviate the PRs and add hyperlinks e.g. PR#50
  
• The comments part seems cramped up. Allot more space to that if you can. Doing the above will help. That will leave you with more place to elaborate.
  
• The Work Product Submission Guidelines also mention of a "documentation of what and why". While the current report and the reasons for certain design decisions make perfect sense for people involved with the project, it might not be that obvious for people who are new to the project just by going through the report. It would be great to have the relevant documentation within the source code for the parts which are not that obvious. Along with that I would suggest you to extend the Beginner Contributor Guides for the new things that you added, like exception handling, and add a link to that in the report as well.

Let's get the pending PRs wrapped up soon. Mention me when you want it to be reviewed.

Thanks a lot for your efforts! 🙂

Regards,

Abinash Meher

On Fri, Aug 19, 2016 at 10:42 AM, Rajith Vidanaarachchi <rajith.vid...@gmail.com> wrote:

Hi guys,

I have written a wrap-up blog post for submission to GSoC.
https://rajithsays.wordpress.com/2016/08/19/gsoc-epilogue/

Please let me know your ideas. (I will update the blogpost until I submit it on 22nd Monday)

I am hoping to complete the Exception Handling Ruby Wrapper code by tonight (just have to add some tests there), which will also enable the Parser Ruby Wrapper to be merged.

Then the only code which will stay unmerged will be in the Matrix Ruby Wrapper PR. Realistically, this will be hard to get merged before the deadline on the 23rd. But I will continue work on it, as I'm free.

Regards,

Rajith

[Rajith Vidanaarachchi]

Hi Abinash,

I submitted the blog post, along with the improvements you mentioned.

The parser PR is also complete, and needs to be merged. But I submitted the work anyway, as I didn't want to wait until the last day.

I will continue contributing to SymEngine, so this won't be a good bye, but I would like to shout out a big thank you for all the mentors and others who helped during the past three months. :)

Regards,

Rajith

On Fri, Aug 19, 2016 at 1:59 PM, Abinash Meher <abinashda...@gmail.com> wrote:

Hi Rajith,

The report looks very well organised. It shows how much of time and effort you have put into the project. Great work! A couple of improvements that I would like to suggest are:

• Adding the complete text of the links in the table is unnecessary. You can just abbreviate the PRs and add hyperlinks e.g. PR#50
  
• The comments part seems cramped up. Allot more space to that if you can. Doing the above will help. That will leave you with more place to elaborate.
  
• The Work Product Submission Guidelines also mention of a "documentation of what and why". While the current report and the reasons for certain design decisions make perfect sense for people involved with the project, it might not be that obvious for people who are new to the project just by going through the report. It would be great to have the relevant documentation within the source code for the parts which are not that obvious. Along with that I would suggest you to extend the Beginner Contributor Guides for the new things that you added, like exception handling, and add a link to that in the report as well.

Let's get the pending PRs wrapped up soon. Mention me when you want it to be reviewed.

Thanks a lot for your efforts! 🙂

Regards,

Abinash Meher