Gris Ge
2014-05-14 15:58:58 UTC
# Timeline is based on GMT +8
[2014-05-14 22:55] <fge> IRC meeting start in 5 minutes.
[2014-05-14 23:01] <fge> tasleson: Can we start?
[2014-05-14 23:02] <tasleson> Yes
[2014-05-14 23:02] <fge> I am sending the path for pool_create() of SMI-S. Can I have 5 extra minutes?
[2014-05-14 23:03] <tasleson> Sure
[2014-05-14 23:03] <tasleson> I'm here all day :-)
[2014-05-14 23:12] <fge> tasleson: Back.
[2014-05-14 23:12] <tasleson> ok
[2014-05-14 23:12] <fge> tasleson: Anything you want to talk about?
[2014-05-14 23:13] <tasleson> Yes, the display code
[2014-05-14 23:18] <fge> I created this etherpad to edit on: https://etherpad.mozilla.org/3GKzQ62uyI
[2014-05-14 23:18] <fge> for summerizing ideas.
[2014-05-14 23:23] <fge> tasleson: OK. Let's summery your point here.
[2014-05-14 23:24] <tasleson> OK
[2014-05-14 23:24] <fge> We import lsm.System and add more method -- lsm.System._value_convert() in cmdline.py(or data_display.py)
[2014-05-14 23:24] <fge> is that what you mean OO way?
[2014-05-14 23:26] <tasleson> No, utilizing the class hierarchy with the base class and derived classes and abstract methods is a prime example of polymorphism.
[2014-05-14 23:27] <tasleson> In addition there are no private methods on lsm.System
[2014-05-14 23:27] <tasleson> or any of the other data classes
[2014-05-14 23:27] <tasleson> All the display logic is moved out into cmdline.py, it could be moved to another file to make it smaller if wanted
[2014-05-14 23:28] <fge> tasleson: I am checking you patch to get a clear view.
[2014-05-14 23:30] <tasleson> I basically took what we had in _data.py and ripped it out and put it into a separate object hierarchy. There is very little new code, it's moved code.
[2014-05-14 23:30] <fge> so we have SystemDisplay, DiskDisplay and etc.
[2014-05-14 23:31] <tasleson> Yeah, each of which is derived from the corresponding classes
[2014-05-14 23:31] <fge> How could display_data() map lsm.System to SystemDisplay?
[2014-05-14 23:32] <fge> OK.I got it display_cast()
[2014-05-14 23:32] <tasleson> Yes
[2014-05-14 23:32] <tasleson> That was the point I was trying to discuss with Andy.
[2014-05-14 23:32] <tasleson> Is there a better way to do that specific thing
[2014-05-14 23:33] <tasleson> Ideally I wanted a constructor for SystemDisplay that took a Display object as a parameter, but couldn't find a way to do that directly
[2014-05-14 23:35] <tasleson> I talked with Andy some yesterday and I created a branch with the code in it for him to see what he thinks.
[2014-05-14 23:35] <tasleson> He has better python skills that me :-)
[2014-05-14 23:36] <tasleson> s/that/than
[2014-05-14 23:38] <fge> Just curious, why don't we just use current simple DisplayData way? Other than the reason of OO.
[2014-05-14 23:38] <fge> You OO design is pretty complex to me especially when SystemDisplay is iheriate from lsm.System and cmdline.Display two classes.
[2014-05-14 23:40] <fge> BTW. As cmdline.py don't have to serialized into JSON, we can use OrderDict now which save a lot codes on value converting.
[2014-05-14 23:41] <tasleson> I guess for me it was easier to grasp replacing two classes System, & PluginData instead of re-working everything else.
[2014-05-14 23:44] <tasleson> What I find interesting is that both designs were done by you originally :-)
[2014-05-14 23:44] <fge> Yeah. My mind is keep changing.
[2014-05-14 23:45] <tasleson> I think the good thing is that we both agree that we should get the private stuff out of _data.py
[2014-05-14 23:46] <fge> Yeah. How about you create a demo patch for lsm.Volume only?
[2014-05-14 23:47] <fge> Then we can compare which one is better, the display way of lsm.System, or lsm.Volume.
[2014-05-14 23:47] <tasleson> Current method and Method B are already done, so your referring to Method B
[2014-05-14 23:47] <tasleson> Method A?
[2014-05-14 23:48] <fge> Currently, we have code for Method A: display way of lsm.System
[2014-05-14 23:48] <fge> Never mind.
[2014-05-14 23:48] <fge> I will split your patch out to keep lsm.Volume only for Method B.
[2014-05-14 23:49] <tasleson> Sorry, I'm confused. The patch I submitted covers all the data types.
[2014-05-14 23:49] <fge> The I can compare the elegance and maintainbility.
[2014-05-14 23:49] <fge> and clarity.
[2014-05-14 23:50] <tasleson> I think if we want to do a full comparison, you should submit a patch for Method A in it's entirety.
[2014-05-14 23:50] <fge> OK. Will do.
[2014-05-14 23:51] <tasleson> Then we can have Andy take a look and see what he thinks
[2014-05-14 23:51] <tasleson> What topics do you have?
[2014-05-14 23:54] <fge> Nope.
[2014-05-14 23:54] <fge> I just created another patch of lsmd.
[2014-05-14 23:54] <fge> it will load plugin/simc/.libs/simc_lsmplugin.
[2014-05-14 23:54] <fge> It's a duplicate.
[2014-05-14 23:55] <tasleson> ok
[2014-05-14 23:56] <fge> sent.
[2014-05-14 23:56] <fge> I believe I am done today.
[2014-05-14 23:56] <tasleson> OK, have a good evening!
[2014-05-14 23:57] <fge> You have a nice day.
[2014-05-14 23:58] <fge> In case anyone else want to share anything, please ping 'tasleson' :)
[2014-05-14 22:55] <fge> IRC meeting start in 5 minutes.
[2014-05-14 23:01] <fge> tasleson: Can we start?
[2014-05-14 23:02] <tasleson> Yes
[2014-05-14 23:02] <fge> I am sending the path for pool_create() of SMI-S. Can I have 5 extra minutes?
[2014-05-14 23:03] <tasleson> Sure
[2014-05-14 23:03] <tasleson> I'm here all day :-)
[2014-05-14 23:12] <fge> tasleson: Back.
[2014-05-14 23:12] <tasleson> ok
[2014-05-14 23:12] <fge> tasleson: Anything you want to talk about?
[2014-05-14 23:13] <tasleson> Yes, the display code
[2014-05-14 23:18] <fge> I created this etherpad to edit on: https://etherpad.mozilla.org/3GKzQ62uyI
[2014-05-14 23:18] <fge> for summerizing ideas.
[2014-05-14 23:23] <fge> tasleson: OK. Let's summery your point here.
[2014-05-14 23:24] <tasleson> OK
[2014-05-14 23:24] <fge> We import lsm.System and add more method -- lsm.System._value_convert() in cmdline.py(or data_display.py)
[2014-05-14 23:24] <fge> is that what you mean OO way?
[2014-05-14 23:26] <tasleson> No, utilizing the class hierarchy with the base class and derived classes and abstract methods is a prime example of polymorphism.
[2014-05-14 23:27] <tasleson> In addition there are no private methods on lsm.System
[2014-05-14 23:27] <tasleson> or any of the other data classes
[2014-05-14 23:27] <tasleson> All the display logic is moved out into cmdline.py, it could be moved to another file to make it smaller if wanted
[2014-05-14 23:28] <fge> tasleson: I am checking you patch to get a clear view.
[2014-05-14 23:30] <tasleson> I basically took what we had in _data.py and ripped it out and put it into a separate object hierarchy. There is very little new code, it's moved code.
[2014-05-14 23:30] <fge> so we have SystemDisplay, DiskDisplay and etc.
[2014-05-14 23:31] <tasleson> Yeah, each of which is derived from the corresponding classes
[2014-05-14 23:31] <fge> How could display_data() map lsm.System to SystemDisplay?
[2014-05-14 23:32] <fge> OK.I got it display_cast()
[2014-05-14 23:32] <tasleson> Yes
[2014-05-14 23:32] <tasleson> That was the point I was trying to discuss with Andy.
[2014-05-14 23:32] <tasleson> Is there a better way to do that specific thing
[2014-05-14 23:33] <tasleson> Ideally I wanted a constructor for SystemDisplay that took a Display object as a parameter, but couldn't find a way to do that directly
[2014-05-14 23:35] <tasleson> I talked with Andy some yesterday and I created a branch with the code in it for him to see what he thinks.
[2014-05-14 23:35] <tasleson> He has better python skills that me :-)
[2014-05-14 23:36] <tasleson> s/that/than
[2014-05-14 23:38] <fge> Just curious, why don't we just use current simple DisplayData way? Other than the reason of OO.
[2014-05-14 23:38] <fge> You OO design is pretty complex to me especially when SystemDisplay is iheriate from lsm.System and cmdline.Display two classes.
[2014-05-14 23:40] <fge> BTW. As cmdline.py don't have to serialized into JSON, we can use OrderDict now which save a lot codes on value converting.
[2014-05-14 23:41] <tasleson> I guess for me it was easier to grasp replacing two classes System, & PluginData instead of re-working everything else.
[2014-05-14 23:44] <tasleson> What I find interesting is that both designs were done by you originally :-)
[2014-05-14 23:44] <fge> Yeah. My mind is keep changing.
[2014-05-14 23:45] <tasleson> I think the good thing is that we both agree that we should get the private stuff out of _data.py
[2014-05-14 23:46] <fge> Yeah. How about you create a demo patch for lsm.Volume only?
[2014-05-14 23:47] <fge> Then we can compare which one is better, the display way of lsm.System, or lsm.Volume.
[2014-05-14 23:47] <tasleson> Current method and Method B are already done, so your referring to Method B
[2014-05-14 23:47] <tasleson> Method A?
[2014-05-14 23:48] <fge> Currently, we have code for Method A: display way of lsm.System
[2014-05-14 23:48] <fge> Never mind.
[2014-05-14 23:48] <fge> I will split your patch out to keep lsm.Volume only for Method B.
[2014-05-14 23:49] <tasleson> Sorry, I'm confused. The patch I submitted covers all the data types.
[2014-05-14 23:49] <fge> The I can compare the elegance and maintainbility.
[2014-05-14 23:49] <fge> and clarity.
[2014-05-14 23:50] <tasleson> I think if we want to do a full comparison, you should submit a patch for Method A in it's entirety.
[2014-05-14 23:50] <fge> OK. Will do.
[2014-05-14 23:51] <tasleson> Then we can have Andy take a look and see what he thinks
[2014-05-14 23:51] <tasleson> What topics do you have?
[2014-05-14 23:54] <fge> Nope.
[2014-05-14 23:54] <fge> I just created another patch of lsmd.
[2014-05-14 23:54] <fge> it will load plugin/simc/.libs/simc_lsmplugin.
[2014-05-14 23:54] <fge> It's a duplicate.
[2014-05-14 23:55] <tasleson> ok
[2014-05-14 23:56] <fge> sent.
[2014-05-14 23:56] <fge> I believe I am done today.
[2014-05-14 23:56] <tasleson> OK, have a good evening!
[2014-05-14 23:57] <fge> You have a nice day.
[2014-05-14 23:58] <fge> In case anyone else want to share anything, please ping 'tasleson' :)
--
Gris Ge
Gris Ge