search

xlab-uiuc / slooo

Slooo: A Fail-slow Fault Injection Testing Framework
11 stars 1 forks source link

Assignment #2 #37

Closed tianyin closed 2 years ago

tianyin commented 2 years ago

@varshith15 @Essoz

This is Assignment #2 https://docs.google.com/document/d/1POR9TDpPL3FC5H07K49Ad-WJWNt2sWNO2A48ttsHbHE/edit

Would you be interested in doing it, so that you know how Slooo can be used by the studemts?

tianyin commented 2 years ago

I created two samples

Sample #1 will be done by @varshith15

Sample #2 will be done by @Essoz

varshith15 commented 2 years ago

@tianyin Am i supposed to do for Copilot?

tianyin commented 2 years ago

@varshith15 hehe, no, you are supposed to do any one of your choice (as the assignment states :)

tianyin commented 2 years ago

If you want to do RethinkDB, it's perfectly fine too!

varshith15 commented 2 years ago

@tianyin there seems to be a link to the copilot paper

tianyin commented 2 years ago

yes, it is trying to explain what is a throughput-latency figure.

varshith15 commented 2 years ago

I want to do it for copilot but in this https://github.com/princeton-sns/copilot the code is not well explained, there's no proper documentation as well. There are a lot of options which are not explained.

I remember you mentioning that we can use @Stuart0l s code.

tianyin commented 2 years ago

@varshith15 I suggest you to do RethinkDB.

You will find it is not as simple as you thought and you can find the gap in the current Slooo.

Essoz commented 2 years ago

Hi (prof) Tianyin, sorry for mentioning this again. Can you share access to lessoxx@gmail.com?

varshith15 commented 2 years ago

And also @tianyin why are we doing this and not working on the paper instead?

tianyin commented 2 years ago

why are we doing this and not working on the paper instead?

This is good question!

Let me tell my reason, besides the obvious selfishness of asking you to help the course.

So, for a tool paper, and more broadly for a tool work, one (if not the only) criteria is its usefulness -- a tool is defined by how useful it is. I strongly believe that the exercise to engage the students to use your tool will make your work a lot more stronger and solid. Just look at how much progress we have made in the past several days. Slooo is a much stronger work than the sloppy code a week ago.

Very honestly, this is a once-in-every-n-year opportunity because I don't teach the 598 course often (last time I taught the course is Spring 2019). So, unless @shuaimu is going to teach a similar course next semester and is willing to engage you and the tool, I don't see how in a short term, we can improve the work in a similar pace and engagement (including me, the students, the team, the TA, etc).

Back to the paper argument:

why are we doing this and not working on the paper instead?

My frank answer is that writing a 4-page paper is too simple... I know you find it hard to write as a first-time writer, but it is simple for me and @shuaimu. The reason I didn't actively work on it, because I don't feel the work is not too solid and have too much to say (even for a 4-page tool paper) and the team is lack of energy and hard to push (or, more fairly, I don't have the energy and incentive to push it forward).

The vibe is completely changed as I'm an instructor.

So, my proposal is to take advantage of this opportunity to understand how the tool will be used by the students to do the testing (I suspect many students will use the tool) and to improve the tooling continuously and progressively in this semester, till early May.

Yes, we may miss the paper deadline, but the work will be significantly improved. If you are thinking about the longer term -- with the significantly improved work, you will have a much stronger paper -- think about how strong your evaluation on real use cases would be!