From: George F. <fa...@sh...> - 2012-09-01 04:02:11
|
Well that got your attention didn't it. I was looking at the MH code from svn and it occurred to me that there is an awful lot of stuff which probably can be dumped, moved or depreciated. Old interfaces that are no longer available etc. In the interests of making this code better I was wondering if any of you would be interested in helping pair the MH code down to size. I thought it would be good to knock out all the examples, put them somewhere else and dump old interfaces that are no longer used. You know start with things like: Insteon - the new branch X10 Weeder Zwave UPB 1wire Omnistat W800 Make it more modular to add new things. I'm I right out of my tree or what? Comments? Why? Well I was looking at adding an interface and it occurred to me that there is much stuff that just doesn't need to be pulled out of svn for a basic MH install. Cheers George |
From: Jon B. <jb...@co...> - 2012-09-01 17:48:41
|
This may sound like an flippent comment but I don't mean it that way. Switch to python. If you going to do a massive change to the code base it would be easier to start over in modern python over perl. Its easier for users and developers in the long run but would be VERY painful in the short term. Jon On Fri, Aug 31, 2012 at 9:02 PM, George Farris <fa...@sh...> wrote: > Well that got your attention didn't it. > > I was looking at the MH code from svn and it occurred to me that there > is an awful lot of stuff which probably can be dumped, moved or > depreciated. > > Old interfaces that are no longer available etc. > > In the interests of making this code better I was wondering if any of > you would be interested in helping pair the MH code down to size. > > I thought it would be good to knock out all the examples, put them > somewhere else and dump old interfaces that are no longer used. You > know start with things like: > Insteon - the new branch > X10 > Weeder > Zwave > UPB > 1wire > Omnistat > W800 > > Make it more modular to add new things. > > I'm I right out of my tree or what? > > Comments? > > Why? Well I was looking at adding an interface and it occurred to me > that there is much stuff that just doesn't need to be pulled out of svn > for a basic MH install. > > > Cheers > George > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Alan W. <arw...@we...> - 2012-09-01 18:53:00
|
Personally, I think we need more along the lines of dummies guide to misterhouse or 24 hours to a fully automated home. The basic stuff takes a while to get the hang of and over time some of the most basic information to find (especially if you are not a perl programmer or haven't played in misterhouse for years) is just simple how do I do this stuff. I'm still working on some of the most basic stuff currently, such as scenes, groups. They were easier for me to grasp with x10 than Insteon has been, but some recent posts have helped clear the fog. Other items I still have trouble with is the weather, as my weatherbug module craps out some of the time so I just disabled it for now. I want to get that one running. Some better explanation of security, or maybe a pointer to the existing better explanation of security (e.g. passwords) A how to on starting from scratch on an insteon device that doesn't exist in MH. Or how to stop MH from giving me dim commands for relay switches, that would be nice too. Alan |
From: JimMH <jsk...@sb...> - 2012-09-07 17:34:47
|
Alan Womack-2 wrote: > > Personally, I think we need more along the lines of dummies guide to > misterhouse or 24 hours to a fully automated home. > > The basic stuff takes a while to get the hang of and over time some of > the most basic information to find (especially if you are not a perl > programmer or haven't played in misterhouse for years) is just simple > how do I do this stuff. > > I'm still working on some of the most basic stuff currently, such as > scenes, groups. They were easier for me to grasp with x10 than > Insteon has been, but some recent posts have helped clear the fog. > > Other items I still have trouble with is the weather, as my weatherbug > module craps out some of the time so I just disabled it for now. I > want to get that one running. > > I am in a similar position. I have limited time to devote to this and find the documentation lacking. I think everyone knows that. People on this list have been good about steering me in the right direction. And some people put a LOT of time and effort into the project and are to be commended for that. I have even thought of writing up some documentation on a few things as I figure them out. I am able to do only minor, simple hacks to code but might be able to do some documentation. I think a lot of the people here can figure out most of the stuff for themselves either because they have been using mh for a while or they know perl well, etc. But that isn't me. I am trying to learn some but it is a slow process. Weather is a good example. Various module update different variables - some can be adjusted for what variables they update by things set in the ini file and others are hard coded. Kind of a mess and not at all well documented. But I don't see that as reason to do a rewrite of all of mh. I think sticking to perl and doing incremental changes is the best way to go to avoid the very big task of rewriting everything. Neil did somewhat of a dummies guide in his book but then based it on the files on the cd (making it go out of date quickly) and modified directories, etc from other install guides that I found hard to follow or at least understand. He started a "24 days" guide but I think didn't finish. Then there are some differences getting everything installed under different distros... I have some old hardware and have made a few "where did the code for xxx go?" requests myself. Maybe some of us with limited perl skills can help by documenting how we got basic things set up and working... -- View this message in context: http://old.nabble.com/Misterhouse-2.0-tp34376343p34403886.html Sent from the Misterhouse - User mailing list archive at Nabble.com. |
From: Jim C. <jam...@gm...> - 2012-09-01 20:10:40
|
OK, but only since you asked. Let me start by saying that Misterhouse is awesome. It's an older open source solution that solves a problem that is still relevant today. I've been using Misterhouse for about a year, and I was unsure when selecting it, but the other viable options that included Insteon support did not exist. I was surprised at the level of community participation that this project still enjoys. Misterhouse is at the core a rule engine that focusses on home automation. It evaluates the current state of the environment and takes action. It's 10:00 PM? Time to turn the porch lights off. Motion in the back yard after midnight? Turn the flood lights on. But why does it try to implement it's own rule engine? Should it not use a lower level library to solve this problem? Like something that is already in CPAN?<http://search.cpan.org/dist/VS-RuleEngine/lib/VS/RuleEngine.pm> Why is there such a tight coupling between the UI and Misterhouse? It would be nice if I could run Misterhouse as a standalone process and have Apache handle the user interface with mod_perl. Or not. Any device like my Android phone should able able to hook and provide a nice UI to turn the lights on. And let's be honest about the current UI, it's a little clunky (and that's being generous). There are no unit tests in the Misterhouse (at least that I've seen). Perl has a nice unit testing framework.<http://perldoc.perl.org/Test/More.html> Make use of it. It will force the contributing developers to write more modular code and the resulting code base will be more maintainable. And finally, stick with Perl. It's still relevant. Perl is stable, well supported and most likely has a module to already do what you want to do. Thanks, Jim On Sat, Sep 1, 2012 at 2:52 PM, Alan Womack <arw...@we...> wrote: > Personally, I think we need more along the lines of dummies guide to > misterhouse or 24 hours to a fully automated home. > > The basic stuff takes a while to get the hang of and over time some of > the most basic information to find (especially if you are not a perl > programmer or haven't played in misterhouse for years) is just simple > how do I do this stuff. > > I'm still working on some of the most basic stuff currently, such as > scenes, groups. They were easier for me to grasp with x10 than > Insteon has been, but some recent posts have helped clear the fog. > > Other items I still have trouble with is the weather, as my weatherbug > module craps out some of the time so I just disabled it for now. I > want to get that one running. > > Some better explanation of security, or maybe a pointer to the > existing better explanation of security (e.g. passwords) > > A how to on starting from scratch on an insteon device that doesn't exist > in MH. > > Or how to stop MH from giving me dim commands for relay switches, that > would be nice too. > > Alan > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Johan <lis...@ce...> - 2012-09-03 14:32:27
|
Quoting Jim Cox <jam...@gm...>: > Let me start by saying that Misterhouse is awesome. It's an older open > source solution that solves a problem that is still relevant today. I've > been using Misterhouse for about a year, and I was unsure when selecting > it, but the other viable options that included Insteon support did not > exist. I was surprised at the level of community participation that this > project still enjoys. Yes, it is awesome. ;-) <snip> > Why is there such a tight coupling between the UI and Misterhouse? It > would be nice if I could run Misterhouse as a standalone process and have > Apache handle the user interface with mod_perl. Or not. Any device like > my Android phone should able able to hook and provide a nice UI to turn the > lights on. And let's be honest about the current UI, it's a little clunky > (and that's being generous). I think steps are being taken in that direction. I didn't try it, but I noticed there is an AJAX interface available. With this, you can create your own webapplication and interact with MH through AJAX. <snip> > And finally, stick with Perl. It's still relevant. Perl is stable, well > supported and most likely has a module to already do what you want to do. There are also a lot of people that wrote their own code for very specific things and don't want to rewrite them in another language. :-) Best regards, Johan. |
From: Marc M. <ma...@me...> - 2012-09-02 15:57:26
|
On Sat, Sep 01, 2012 at 10:48:14AM -0700, Jon Boehm wrote: > This may sound like an flippent comment but I don't mean it that way. > > Switch to python. > > If you going to do a massive change to the code base it would be easier to > start over in modern python over perl. Its easier for users and developers > in the long run but would be VERY painful in the short term. You do realize this would mean rewriting _everything_ in misterhouse, like about a hundred modules written by people who may or may not be around now, and for hardware that he or you don't have therefore making the new code untestable? You have the right to prefer python (I'm personally mostly agnostic between the 2), but this is not a serious suggestion, sorry. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Jon B. <jb...@co...> - 2012-09-02 22:29:15
|
It is a serious suggestion. Modules that aren't important enough to be ported will be dropped. I goes to the point of the original post. Jon On Sun, Sep 2, 2012 at 8:57 AM, Marc MERLIN <ma...@me...> wrote: > On Sat, Sep 01, 2012 at 10:48:14AM -0700, Jon Boehm wrote: > > This may sound like an flippent comment but I don't mean it that way. > > > > Switch to python. > > > > If you going to do a massive change to the code base it would be easier > to > > start over in modern python over perl. Its easier for users and > developers > > in the long run but would be VERY painful in the short term. > > You do realize this would mean rewriting _everything_ in misterhouse, > like about a hundred modules written by people who may or may not be > around now, and for hardware that he or you don't have therefore making > the new code untestable? > > You have the right to prefer python (I'm personally mostly agnostic > between the 2), but this is not a serious suggestion, sorry. > > Marc > -- > "A mouse is a device used to point at the xterm you want to type in" - > A.S.R. > Microsoft is to operating systems .... > .... what McDonalds is to gourmet > cooking > Home page: http://marc.merlins.org/ > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Marc M. <ma...@me...> - 2012-09-03 05:28:59
|
On Sun, Sep 02, 2012 at 03:28:41PM -0700, Jon Boehm wrote: > It is a serious suggestion. Modules that aren't important enough to be > ported will be dropped. I goes to the point of the original post. Then, it's time to put your money where you mouth is then. Please show us your rewrite of mh in python, and convince us that it's worth switching to it, and convince the people like me who spent many hours writing one or more drivers in perl, to rewrite them all in python. Cheers, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Monte F. <mo...@bv...> - 2012-09-02 23:56:03
|
I completely agree with Marc. A rewrite of mh in a new language isn't a good idea. Too much development time has gone into too many relevant modules; by people who don't have the time to start those modules over from scratch. -Monte On Sep 2, 2012, at 3:28 PM, Jon Boehm <jb...@co...> wrote: > It is a serious suggestion. Modules that aren't important enough to be ported will be dropped. I goes to the point of the original post. > > Jon > > On Sun, Sep 2, 2012 at 8:57 AM, Marc MERLIN <ma...@me...> wrote: > On Sat, Sep 01, 2012 at 10:48:14AM -0700, Jon Boehm wrote: > > This may sound like an flippent comment but I don't mean it that way. > > > > Switch to python. > > > > If you going to do a massive change to the code base it would be easier to > > start over in modern python over perl. Its easier for users and developers > > in the long run but would be VERY painful in the short term. > > You do realize this would mean rewriting _everything_ in misterhouse, > like about a hundred modules written by people who may or may not be > around now, and for hardware that he or you don't have therefore making > the new code untestable? > > You have the right to prefer python (I'm personally mostly agnostic > between the 2), but this is not a serious suggestion, sorry. > > Marc > -- > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > Microsoft is to operating systems .... > .... what McDonalds is to gourmet cooking > Home page: http://marc.merlins.org/ > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Larry R. <lro...@gm...> - 2012-09-03 00:16:25
|
ok, have not been active developing for quite some time, but i would agree to keep the language, but put everything else as modules and dummyfy the setup. Coming back to perl after years of not touching it has led me to some confusion. I see many subs in the main routine that need to be removed and added as hooks and modules. On Sun, Sep 2, 2012 at 7:55 PM, Monte Freeman <mo...@bv...> wrote: > I completely agree with Marc. A rewrite of mh in a new language isn't a good > idea. Too much development time has gone into too many relevant modules; by > people who don't have the time to start those modules over from scratch. > > -Monte > > > On Sep 2, 2012, at 3:28 PM, Jon Boehm <jb...@co...> wrote: > > It is a serious suggestion. Modules that aren't important enough to be > ported will be dropped. I goes to the point of the original post. > > Jon > > On Sun, Sep 2, 2012 at 8:57 AM, Marc MERLIN <ma...@me...> wrote: >> >> On Sat, Sep 01, 2012 at 10:48:14AM -0700, Jon Boehm wrote: >> > This may sound like an flippent comment but I don't mean it that way. >> > >> > Switch to python. >> > >> > If you going to do a massive change to the code base it would be easier >> > to >> > start over in modern python over perl. Its easier for users and >> > developers >> > in the long run but would be VERY painful in the short term. >> >> You do realize this would mean rewriting _everything_ in misterhouse, >> like about a hundred modules written by people who may or may not be >> around now, and for hardware that he or you don't have therefore making >> the new code untestable? >> >> You have the right to prefer python (I'm personally mostly agnostic >> between the 2), but this is not a serious suggestion, sorry. >> >> Marc >> -- >> "A mouse is a device used to point at the xterm you want to type in" - >> A.S.R. >> Microsoft is to operating systems .... >> .... what McDonalds is to gourmet >> cooking >> Home page: http://marc.merlins.org/ >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ________________________________________________________ >> To unsubscribe from this list, go to: >> http://sourceforge.net/mail/?group_id=1365 >> > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Marc M. <ma...@me...> - 2012-09-03 05:28:57
|
On Fri, Aug 31, 2012 at 09:02:14PM -0700, George Farris wrote: > Well that got your attention didn't it. > > I was looking at the MH code from svn and it occurred to me that there > is an awful lot of stuff which probably can be dumped, moved or > depreciated. > > Old interfaces that are no longer available etc. Keep in mind that people may be using those old interfaces not for sale anymore :) > In the interests of making this code better I was wondering if any of > you would be interested in helping pair the MH code down to size. What is the end goal exactly? Are you offering to become new maintainer for mh (since effectively there is no real overall maintainer currently), and that you have identified that somehow dumping a bunch of drivers you mean old will help you maintain the code? > I thought it would be good to knock out all the examples, put them > somewhere else and dump old interfaces that are no longer used. You > know start with things like: > Insteon - the new branch > X10 > Weeder > Zwave > UPB > 1wire > Omnistat > W800 > > Make it more modular to add new things. > > I'm I right out of my tree or what? I'm not too sure what you're offering yet :) What do you mean by "more modular"? Are you offering to do a big rewrite of the main loop that will be incompatible with old drivers? If not, why remove them if they don't cause harm? > Why? Well I was looking at adding an interface and it occurred to me > that there is much stuff that just doesn't need to be pulled out of svn > for a basic MH install. I'm just flying back from linuxcon in San Diego, and as part of the linux panel, someone asked what happens to really old drivers that maybe no one uses anymore. The answer Linus and Greg gave was that effectively they keep all drivers and only ever consider removing one when it's the last user of a deprecated interface that is being removed from the kernel. Honestly, I don't see mh being at that stage. Right now it just needs general love and people to work on it more than a cleanup to remove code and drivers. (for instance finishing the insteon branch, as in your other Email which I will reply to now). Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: George F. <fa...@sh...> - 2012-09-03 23:04:27
|
I see a lot of value in a complete redesign and using Python would be a great step, BUT, it a heck of a lot of work and I don't think I'm up to a year of porting full steam. If anyone wants to try this, Kudos to you. Now if we just had a Perl to Python script:-) > > I was looking at the MH code from svn and it occurred to me that there > > is an awful lot of stuff which probably can be dumped, moved or > > depreciated. > > > > Old interfaces that are no longer available etc. > > Keep in mind that people may be using those old interfaces not for sale > anymore :) > Yes certainly and I wouldn't want them to go away. I do think that if we could modularize the code a little bit more that we would start with the most used though. Keep in mind that at this point I'm suggesting this for developers not for end users although they would certainly benefit. One of the hardest problems is figuring out how to add a new driver. Starting by reducing the code to a few modules and then adding them back seems to be the best way and would offer up much reuse of existing code I think. > What is the end goal exactly? > Are you offering to become new maintainer for mh (since effectively > there is no real overall maintainer currently), and that you have > identified that somehow dumping a bunch of drivers you mean old will > help you maintain the code? > Well there is a thought, have to think about that one. It's a good point though. A problem may be that my Perl skills are just enough to get by but... > I'm not too sure what you're offering yet :) > What do you mean by "more modular"? > Are you offering to do a big rewrite of the main loop that will be > incompatible with old drivers? > If not, why remove them if they don't cause harm? > > > Why? Well I was looking at adding an interface and it occurred to me > > that there is much stuff that just doesn't need to be pulled out of svn > > for a basic MH install. > > (for instance finishing the insteon branch, as in your other Email which > I will reply to now). > > Marc Right, okay so as a start could we look at moving all non-essential stuff out of the main svn branch so when one checks out the code we get just what is required for MH to run. Or, rearrange the directory structure a bit and write a doc for the top level directory explaining what each directory is for and how it all fits goes together. As an example lets pull all but the ia5 web stuff out and move it to examples. I guess what I'm trying to suggest first is just getting rid of the clutter, move it out of the way but not delete it. George |
From: George F. <fa...@gm...> - 2012-09-05 19:21:17
|
On Wed, 2012-09-05 at 10:49 -0700, Marc MERLIN wrote: > On Wed, Sep 05, 2012 at 08:42:32AM -0700, George Farris wrote: > > That's what happened with the Linux kernel when they went from the old > > a.out to elf format libraries. It was a big rewrite but well worth it. > > Just for the record :) > That is absolutely not what happened, I was there, there was no rewrite, > just a change of c library, and addition of binary format in the binary > loader. > > Marc Maybe I should have used the term refactoring instead of whole sale rewrite. Refactoring is closer except in cases like Apache, PHP and Mozilla to name a few, where there was a rewrite. |
From: Marc M. <ma...@me...> - 2012-09-05 19:34:29
|
On Wed, Sep 05, 2012 at 12:21:09PM -0700, George Farris wrote: > Maybe I should have used the term refactoring instead of whole sale > rewrite. Refactoring is closer except in cases like Apache, PHP and > Mozilla to name a few, where there was a rewrite. I still don't agree, but it's irrelevant. Enough time has been spent on Email. It's time to "show me the code" :) Please come back when you have a tree with the work you've done and would like people to look at and contribute to. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Ron B. <rb...@be...> - 2012-09-05 02:42:14
|
On 09/04/2012 09:52 PM, Marc MERLIN wrote: > On Tue, Sep 04, 2012 at 06:06:05PM -0700, George Farris wrote: >> This sounds good. Marc do you think you could add a link called >> Developers to the Misterhouse home page points to the wiki page so we >> can slowly populate it with this kind of info. > > I don't have access to > http://misterhouse.sourceforge.net/ > and I'm not sure who does. > > Bruce may be the only one. Speaking about Bruce may I ask what is his current participation in MH? The reason I ask is that I believe he may be the only who can set the direction for this project going forward. MH was his creative effort and the "original" developer in my estimation has the right and the authority to dictate future development. I am beginning to feel that we are at an impasse. > > That said all the info is on the wiki now: > http://misterhouse.wikispaces.com/ > > I think you just need to make an account. If you need perms, give me your > account name and I can give you access. > > Marc > -- www.usefulramblings.org |
From: Marc M. <ma...@me...> - 2012-09-05 05:24:31
|
On Tue, Sep 04, 2012 at 10:41:49PM -0400, Ron Blout wrote: > On 09/04/2012 09:52 PM, Marc MERLIN wrote: > > On Tue, Sep 04, 2012 at 06:06:05PM -0700, George Farris wrote: > >> This sounds good. Marc do you think you could add a link called > >> Developers to the Misterhouse home page points to the wiki page so we > >> can slowly populate it with this kind of info. > > > > I don't have access to > > http://misterhouse.sourceforge.net/ > > and I'm not sure who does. > > > > Bruce may be the only one. > > Speaking about Bruce may I ask what is his current participation in MH? > The reason I ask is that I believe he may be the only who can set the > direction for this project going forward. MH was his creative effort > and the "original" developer in my estimation has the right and the > authority to dictate future development. He retired from this project a long time ago since he didn't have a use for it anymore (from what I remember reading). It's not great not to have a leader that knows most of the code, but this does not stop individual contributers from adding code, drivers, and fixes, which is what has been going on. Trust me, work on drivers help a lot more per unit of time spent than grand projects to rewrite or reorganize the entire code. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Ron B. <rb...@be...> - 2012-09-03 16:38:52
|
On 09/01/2012 12:02 AM, George Farris wrote: > Well that got your attention didn't it. I have been a MH user for many years but recently I am becoming concerned about the Insteon support within MH, especially since MH does not support the lastest Insteon protocol. To invest the money required by upgrading to Insteon requires a reliable software product. While I prefer Linux to Windows I might be forced to go to a Windows based application to manage my Insteon devices reliably. I am NOT trashing the efforts that many on this project have made, but many of those people who were familiar with Insteon are no longer able to participate at the level they once did, and some not at all. Again we are talking about a new release of MH. What MH needs more then anything else is a project manager. Someone who will be responsible for defining the path for MH. I am sure there is no shortage of talent on this thread but someone must have a vision for MH and direct everyone's efforts towards meeting this vision. At this moment my release of MH with Insteon support works. But if I were asked by someone where to get the latest code of MH which supports both Insteon and X10 I could not tell them. I should be able to do this. I have read where the "Device Editor" is broken in some branches and that "those of us who are familiar with MH know better then to use the Device Editor. We just edit the .mht file and make it work." Really. And this is supposed to boost confidence in this project? This post is not intended as a criticism of any member of this thread. Many have worked hard but without a "captain" we are not all going to arrive at the destination at the same time. > > I was looking at the MH code from svn and it occurred to me that there > is an awful lot of stuff which probably can be dumped, moved or > depreciated. > > Old interfaces that are no longer available etc. > > In the interests of making this code better I was wondering if any of > you would be interested in helping pair the MH code down to size. > > I thought it would be good to knock out all the examples, put them > somewhere else and dump old interfaces that are no longer used. You > know start with things like: > Insteon - the new branch > X10 > Weeder > Zwave > UPB > 1wire > Omnistat > W800 > > Make it more modular to add new things. > > I'm I right out of my tree or what? > > Comments? > > Why? Well I was looking at adding an interface and it occurred to me > that there is much stuff that just doesn't need to be pulled out of svn > for a basic MH install. > > > Cheers > George > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > |
From: George F. <fa...@sh...> - 2012-09-03 23:04:43
|
On Mon, 2012-09-03 at 12:38 -0400, Ron Blout wrote: > On 09/01/2012 12:02 AM, George Farris wrote: > > Well that got your attention didn't it. > > Again we are talking about a new release of MH. What MH needs more then > anything else is a project manager. Someone who will be responsible for > defining the path for MH. I will volunteer for some of this and looking into the Insteon code. Would someone be willing to look at the web side of things? Some of the web code only relates to people inside the US and some is probably just not used. We need to cut the cruft down so we can have a clean base to start with. For example, does anyone use the any of the following modules on the web page: Comics/Pictures <- There are far better ways to do this TV Guide/MP3 <- A media center like XMBC is better Events/Calendar/Clock <- Again far better ways to do this/Google?? Mail/Headline News Phone Calls/Voice Mail If not lets get it out of the way/dump it, we can always add it back later. At this point a re-write in Python is not the direction to go. Thoughts? George |
From: George F. <fa...@gm...> - 2012-09-05 01:06:13
|
On Tue, 2012-09-04 at 17:19 -0700, Marc MERLIN wrote: > So there isn't really anyone right now AFAIK, and this is once again why I'm > suggesting you use git. > I'm not saying we must move mh code from svn to git, although once the > insteon branch gets sorted out, moving the entire repo to github wouldn't > hurt IMO. > I am however saying that you can use git today (with git-svn) to make your > changes locally, publish them, and get people to review them or even use > your tree. > > As github explains, with git, forks are actually a good thing and are > encouraged. It took me a few minutes to get it on my first read, but it > makes sense. > > So again, I don't want to discourage you, I'm just pointing out that an svn > branch isn't the best way to do what you're wanting to do, so please do it > in git and put it on github or elsewhere for others to see. > If you do a great job, your git tree would even become the new main branch > for misterhouse. > > Marc This sounds good. Marc do you think you could add a link called Developers to the Misterhouse home page points to the wiki page so we can slowly populate it with this kind of info. |
From: Marc M. <ma...@me...> - 2012-09-05 01:52:46
|
On Tue, Sep 04, 2012 at 06:06:05PM -0700, George Farris wrote: > This sounds good. Marc do you think you could add a link called > Developers to the Misterhouse home page points to the wiki page so we > can slowly populate it with this kind of info. I don't have access to http://misterhouse.sourceforge.net/ and I'm not sure who does. Bruce may be the only one. That said all the info is on the wiki now: http://misterhouse.wikispaces.com/ I think you just need to make an account. If you need perms, give me your account name and I can give you access. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Marc M. <ma...@me...> - 2012-09-05 15:20:21
|
On Wed, Sep 05, 2012 at 11:06:14AM +0200, Lieven Hollevoet wrote: > However: if we move to github, we would still need a few volunteers to > review and merge pull requests, just like we now need a few people to > agree on letting new contributors commit code to the SVN. Using git would > ease the review process of proposed changes, but the need for a few > 'repository admins' would still be there. Would there be people available > for/willing to doing that? If we have a rotation of at least 5 to 10 people, I'm willing to be one of them. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Lieven H. <li...@li...> - 2012-09-05 18:57:59
|
Op 5-sep.-2012, om 17:20 heeft Marc MERLIN het volgende geschreven: > On Wed, Sep 05, 2012 at 11:06:14AM +0200, Lieven Hollevoet wrote: >> However: if we move to github, we would still need a few volunteers to >> review and merge pull requests, just like we now need a few people to >> agree on letting new contributors commit code to the SVN. Using git would >> ease the review process of proposed changes, but the need for a few >> 'repository admins' would still be there. Would there be people available >> for/willing to doing that? > > If we have a rotation of at least 5 to 10 people, I'm willing to be one of > them. Count me in too if we're with at least 5. Other volunteers, please chime in. If there is enough interest, then let's make this happen. Lieven. |
From: Marc M. <ma...@me...> - 2012-09-04 00:44:34
|
On Mon, Sep 03, 2012 at 04:04:40PM -0700, George Farris wrote: > One of the hardest problems is figuring out how to add a new driver. I'm not sure if I agree. I only wrote limited amounts of new code, but I rewrote most of the hai rcxx driver, and wrote the CM26a driver using the w800 driver as an example, and I didn't find writing drivers was hard. > Starting by reducing the code to a few modules and then adding them back > seems to be the best way and would offer up much reuse of existing code > I think. I don't agree. You're welcome to do this in your tree at home, but certainly not to gut all of mh to make it easier to read for you :) > Right, okay so as a start could we look at moving all non-essential > stuff out of the main svn branch so when one checks out the code we get > just what is required for MH to run. Or, rearrange the directory Do that in your tree at home. You can even publish that tree if you wish and find that it's useful to others. But it'll break anyone else who does need all the drivers you will have just removed. > structure a bit and write a doc for the top level directory explaining > what each directory is for and how it all fits goes together. Documentation never hurts, you're welcome to write some as you figure things out when you read the code, and publish that on the wiki. > As an example lets pull all but the ia5 web stuff out and move it to > examples. I guess what I'm trying to suggest first is just getting rid > of the clutter, move it out of the way but not delete it. How are moving self contained directories out of the way really going to help? Granted I do use ia5, but others may use other ones. How about you just delete this on your tree at home if it's really in the way? On Mon, Sep 03, 2012 at 04:04:56PM -0700, George Farris wrote: > I will volunteer for some of this and looking into the Insteon code. Thank you for any help you can provide. You can try Emailing Gregg directly if you have questions and are offering to continue the code from where he left it (I don't think he is reading the list at this moment). > Would someone be willing to look at the web side of things? Some of the > web code only relates to people inside the US and some is probably just > not used. We need to cut the cruft down so we can have a clean base to > start with. For that, I suggest again you start with a tree on your side. If you use git, you can even host it on github, which would make it easy for you to fork things, get people to try that out and not affect the current running code that everyone relies on. Apart from that, I heartily recommend you start with ignoring the rest of the code and work on the insteon branch and just the 5-6 files that do insteon. That will let you get used to the mh code and perl some more while not having to be bogged down by all the other code :) If you can finish up the insteon code to a point that we agree that it's worth switching the default to that, you'll then have earned enough trust points to make other suggestions and big changes to the code base :) Unfortunately as you've noticed, some like Gregg, or me for now, just don't have time to hack on mh much, but that shouldn't stop new folks like you from stepping in and making their own contributions. > Comics/Pictures <- There are far better ways to do this > TV Guide/MP3 <- A media center like XMBC is better > Events/Calendar/Clock <- Again far better ways to do this/Google?? > Mail/Headline News > Phone Calls/Voice Mail Again, I'm not opposing your actual points, I'm just not convinced that the first step to make mh better right now is to delete a lot of code :) > If not lets get it out of the way/dump it, we can always add it back > later. If that helps, do it on your own branch at home. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: George F. <fa...@sh...> - 2012-09-04 04:20:53
|
On Mon, 2012-09-03 at 17:44 -0700, Marc MERLIN wrote: > On Mon, Sep 03, 2012 at 04:04:40PM -0700, George Farris wrote: > > One of the hardest problems is figuring out how to add a new driver. > > I'm not sure if I agree. I only wrote limited amounts of new code, but I > rewrote most of the hai rcxx driver, and wrote the CM26a driver using the > w800 driver as an example, and I didn't find writing drivers was hard. > Great so then would you be able to provide a layout of what code goes where and what one has to modify to let MH know there is a new driver? > I don't agree. You're welcome to do this in your tree at home, but certainly > not to gut all of mh to make it easier to read for you :) > > > Right, okay so as a start could we look at moving all non-essential > > stuff out of the main svn branch so when one checks out the code we get > > just what is required for MH to run. Or, rearrange the directory > Sorry I didn't mean the main svn branch I meant a copy of the main branch and call it test or next version or whatever handle people want. Obviously we wouldn't modify trunk that was a slip on my part. > > As an example lets pull all but the ia5 web stuff out and move it to > > examples. I guess what I'm trying to suggest first is just getting rid > > of the clutter, move it out of the way but not delete it. > > How are moving self contained directories out of the way really going to > help? > Granted I do use ia5, but others may use other ones. How about you just > delete this on your tree at home if it's really in the way? > Is there not a need for an updated WEB view to Misterhouse? I thought that is one of the things people were after. I was just putting ideas out to try get some interest flowing. > On Mon, Sep 03, 2012 at 04:04:56PM -0700, George Farris wrote: > > I will volunteer for some of this and looking into the Insteon code. > > Thank you for any help you can provide. You can try Emailing Gregg directly > if you have questions and are offering to continue the code from where he > left it (I don't think he is reading the list at this moment). > I've been in touch with Gregg already, thanks for the suggestion though. > > Would someone be willing to look at the web side of things? Some of the > > web code only relates to people inside the US and some is probably just > > not used. We need to cut the cruft down so we can have a clean base to > > start with. > > For that, I suggest again you start with a tree on your side. I think you missed the "Would someone be willing" in the above paragraph, I certainly am not going to work on the web side of MH. > Apart from that, I heartily recommend you start with ignoring the rest of > the code and work on the insteon branch and just the 5-6 files that do > insteon. That will let you get used to the mh code and perl some more while > not having to be bogged down by all the other code :) Well Insteon isn't the only thing I'm interested in. I have code for an Ardunio board coming along to replace a Weeder board, which is where I started looking into adding a driver. So since you have done this could you provide some details about how you did your driver and what files you had to touch. It's way easier than reading 300,000 lines of perl and trying to figure it out solo, not to mention all the rest of the files. > > If you can finish up the insteon code to a point that we agree that it's > worth switching the default to that, you'll then have earned enough trust > points to make other suggestions and big changes to the code base :) > Well not to be blunt but if I finish up the Insteon code it will be for myself, because I want to use it. And "we" can take it or leave it, it won't matter to me. Who is "we" anyway? Don't get me wrong Marc I've seen you reply to messages on this list for a long time, years, and I think you are doing an awesome job because you do respond. I think you deserve much credit for that. I do however get a slight impression that there is some resistance to any change in MH. I'd enjoy working with you and others to move MH forward. > Unfortunately as you've noticed, some like Gregg, or me for now, just don't > have time to hack on mh much, but that shouldn't stop new folks like you > from stepping in and making their own contributions. George |