| Monday, August 8th, 2011, 00:08 UTC | ||
| [00:08:36] | marsilainen (marsilainen!~matt@host-78-145-174-218.as13285.net) has quit (Ping timeout: 255 seconds) | |
| [00:18:09] | andreax (andreax!~andreaz@p57B9517D.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [00:37:50] | danielk22: | paul-h: According to the error message the string being saved was a null string. I just pushed a commit which converts null strings to empty strings in settings updates. That should get rid of that message and some others like it. |
| [00:38:56] | highzeth (highzeth!~hz@hoiseth.no) has joined #mythtv | |
| [00:50:57] | danielk22: | Beirdo: paul-h: loglevelAdd() itself is not thread-safe. However I believe it's only called in verboseInit() where the requisite lock is taken. I'd make sure the build environment is clean before digging further. |
| [00:51:25] | Beirdo: | correct. It's only used inside that lock |
| [00:52:12] | Beirdo: | it sounded like a case of a build environment that got confused somehow |
| [00:56:09] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [01:03:50] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [01:04:16] | gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [01:04:16] | gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [01:04:16] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [01:22:36] | danielk22: | Beirdo: I've uploaded a new mthread patch, this one DOES reduce the number of active threads.. It converts three existing thread pools to MThreadPool which shuts down extra threads after a timeout (default is two minutes). |
| [01:25:10] | Beirdo: | cool |
| [01:25:22] | Beirdo: | there any limit set on the size of the threadpool? |
| [01:28:07] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [01:30:40] | danielk22: | Just like QThreadPool the default max threads is == to the number of cores and you can set a higher value. But you can bypass that by using MThreadPool::startReserved() which I did in the replacement for existing thread pools. |
| [01:31:19] | Beirdo: | K. |
| [01:31:33] | danielk22: | I added another param to startReserved() a time-out in which the threadpool waits for an existing thread to become available before it goes ahead and creates a new one. |
| [01:31:43] | Beirdo: | we should likely look at choosing a more reasonable default though |
| [01:32:35] | Beirdo: | a default of 1 on a single-core box... just means that timeout will be hitting a lot |
| [01:32:59] | Beirdo: | might make for a slower startup than we are used to? I dunno |
| [01:33:03] | Beirdo: | jsut a thought |
| [01:33:54] | danielk22: | Well the timeout we're using is PRT_TIMEOUT which is currently set at 10 ms so I doubt that would be noticed on a single core box. |
| [01:33:58] | Beirdo: | hehe |
| [01:34:08] | Beirdo: | OK, 10ms sure won't be noticed much |
| [01:34:10] | danielk22: | And I don't think they make those anymore do they ? |
| [01:34:30] | Beirdo: | people still use Atoms, etc for their frontends |
| [01:35:03] | Beirdo: | we may actively discourage it in a lot of cases, but people still do it. :) |
| [01:35:39] | Beirdo: | but at 10ms delay, doubt anyone would even see it. I was thinking the timeout was like 500ms or something, and that could be annoying. |
| [01:36:17] | danielk22: | heh, my understanding is that in addition to being dog slow Atoms waste power. But they are a few dollars cheaper so people still buy them. |
| [01:36:28] | Beirdo: | yup, they sure do |
| [01:52:44] | wagnerrp: | danielk22: the desktop ones basically have no power throttling |
| [01:52:56] | wagnerrp: | that stuff sucks up precious die space |
| [01:53:25] | wagnerrp: | and who really cares about a 4W processor when the chipset takes another 20W |
| [01:58:24] | Beirdo: | danielk22: so far so good with v10 :) |
| [02:13:01] | MaverickTech (MaverickTech!~MaverickT@dns2.arel.com.au) has joined #mythtv | |
| [02:16:58] | Dave123 (Dave123!~dave@cpe-74-74-200-106.rochester.res.rr.com) has joined #mythtv | |
| [03:01:00] | cattelan is now known as cattelan_away | |
| [03:04:21] | danielk22: | Beirdo: cool, I just need to test the new thread pool conversions, then I think it will be ready for commit either tomorrow or Tuesday. |
| [03:05:05] | danielk22: | Beirdo: I'm also considering some logging enhancements.. I needed to do some cerr logging for the thread stuff because it executes after the logging is shut down. |
| [03:05:33] | danielk22: | But really we should just switch to immediate mode logging once the logging threads are shut down to get those last few messages. |
| [03:06:14] | danielk22: | + it would be useful to be able to turn on immediate mode logging when debugging crashes.. since those last few messages tend to be critical for that. |
| [03:06:42] | danielk22: | + I think we need to be able to flush messages.. |
| [03:16:03] | Beirdo: | agreed |
| [03:16:58] | Beirdo: | it might end up being a bit tricky to do cleanly |
| [03:17:10] | Beirdo: | but I think both of those will be useful additions |
| [03:17:48] | Beirdo: | it used to attempt to flush the queue before quitting the thread, but with all the changes, it may have been changed |
| [03:21:03] | wahrhaft (wahrhaft!~quassel@cpe-24-210-71-26.columbus.res.rr.com) has joined #mythtv | |
| [03:42:27] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [04:44:08] | Goga777 (Goga777!~Goga777@shpd-92-101-155-129.vologda.ru) has joined #mythtv | |
| [04:59:13] | Goga777 (Goga777!~Goga777@shpd-92-101-155-129.vologda.ru) has quit (Remote host closed the connection) | |
| [06:06:02] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [06:15:26] | MaverickTech (MaverickTech!~MaverickT@dns2.arel.com.au) has quit (Ping timeout: 240 seconds) | |
| [06:52:42] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 250 seconds) | |
| [07:06:34] | NightMonkey (NightMonkey!~NightMonk@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection) | |
| [07:37:12] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [08:05:56] | xris (xris!~xris@mythtv/developer/xris) has quit (Read error: Operation timed out) | |
| [08:17:48] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has quit (Ping timeout: 240 seconds) | |
| [08:35:10] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv | |
| [08:36:58] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Remote host closed the connection) | |
| [08:37:36] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [09:11:07] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [09:56:57] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [10:05:02] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:52] | mike (mike!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [10:06:18] | mike is now known as Guest87941 | |
| [10:27:30] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
| [10:49:23] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [10:56:23] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [11:17:00] | Goga777 (Goga777!~Goga777@shpd-95-53-175-165.vologda.ru) has joined #mythtv | |
| [11:18:58] | MaverickTech (MaverickTech!~MaverickT@124-168-38-107.dyn.iinet.net.au) has joined #mythtv | |
| [11:37:58] | Goga777 (Goga777!~Goga777@shpd-95-53-175-165.vologda.ru) has quit (Remote host closed the connection) | |
| [11:39:52] | stuartm: | http://www.bbc.co.uk/blogs/bbcinternet/2011/0 . . . cted_tv.html << Frustratingly little detail on the technical aspects |
| [11:51:21] | knightr: | iamlindoro, sphery, very promising results so far! I am currently checking to see if it got everything but it looks like it did... |
| [12:05:12] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [12:05:38] | gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [12:05:38] | gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [12:05:38] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [12:37:21] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Remote host closed the connection) | |
| [12:38:10] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [13:10:39] | cattelan_away is now known as cattelan | |
| [13:21:05] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [13:21:38] | zombor_ is now known as zombor | |
| [14:05:44] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Read error: Connection reset by peer) | |
| [14:15:22] | j-rod|afk is now known as j-rod | |
| [14:16:27] | MaverickTech (MaverickTech!~MaverickT@124-168-38-107.dyn.iinet.net.au) has quit (Ping timeout: 252 seconds) | |
| [14:19:09] | j-rod: | sphery: yeah, I can get a backtrace |
| [14:19:34] | j-rod: | it reproduces generally in seconds, let alone 15 minutes |
| [14:19:54] | abqjp (abqjp!~jpabq@mythtv/developer/jpabq) has quit (Ping timeout: 250 seconds) | |
| [14:24:53] | danielk22: | iamlindoro: Can you take a quick look at 9d81b10ad ? I moved the translation of three stings from GameScannerThread to GameScanner. I wasn't sure why m_parent was set, since it isn't used but assumed you had a future use for it in mind. |
| [14:28:33] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [14:32:10] | kth1 (kth1!~kth@dyndsl-080-228-183-212.ewe-ip-backbone.de) has joined #mythtv | |
| [14:32:28] | kth (kth!~kth@unaffiliated/kth) has quit (Ping timeout: 240 seconds) | |
| [14:40:06] | iamlindoro: | danielk22: Looks ok to me, and I can test later... the parent thing is for future potential integration with the metadata factory class |
| [15:06:05] | ** dblain really wishes people would either make two commits (one for feature/structure changes, and one for formatting changes), or just leave the formatting alone :(... Having significate formatting changes mixed in with feature/structual changes makes it hard to read the real functionality changes that was made. ** | |
| [15:10:36] | danielk22: | dblain: it would be easier if you followed the mythtv formatting guidelines. I did preserve the UPnP formatting in places where I wasn't making significant changes. I help you out with the upnp stuff though, all the major changes are in httpserver.{cpp,h} |
| [15:11:35] | danielk22: | I had to touch all the files with ProcessRequest(), but those changes are all trivial. |
| [15:18:55] | kth1 (kth1!~kth@dyndsl-080-228-183-212.ewe-ip-backbone.de) has quit (Ping timeout: 260 seconds) | |
| [15:46:11] | stuartm: | am I following this correctly, we only set the wakeup time for a backend IF it's shutdown by HandleIdleShutdown? |
| [15:50:27] | stuartm: | I think I'd at least like the option of also setting the wakeup time when the backend has been shut down by other methods ... e.g. by selecting 'Shutdown' from the context menu in the main menu |
| [15:57:12] | andreax (andreax!~andreaz@p57B9517D.dip.t-dialin.net) has joined #mythtv | |
| [16:05:32] | andreax1 (andreax1!~andreaz@p57B9313D.dip.t-dialin.net) has joined #mythtv | |
| [16:06:30] | andreax (andreax!~andreaz@p57B9517D.dip.t-dialin.net) has quit (Ping timeout: 250 seconds) | |
| [16:22:35] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has joined #mythtv | |
| [16:35:31] | sailerboy (sailerboy!sailerboy@ipv61.sailerboy.net) has quit (Ping timeout: 260 seconds) | |
| [16:38:52] | sailerboy (sailerboy!sailerboy@ipv61.sailerboy.net) has joined #mythtv | |
| [16:42:15] | Kunalagon (Kunalagon!~Kunalagon@212.200.241.62) has joined #mythtv | |
| [16:55:12] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [16:58:57] | andreax1 (andreax1!~andreaz@p57B9313D.dip.t-dialin.net) has quit (Quit: Leaving.) | |
| [17:00:59] | dblain: | danielk22: The issue I had was with the variable name changes, and rearranging the initialization of variables not being changed that had nothing to do with the main changes of the commit. |
| [17:01:51] | dblain: | I had to read through the entire commit to see why the names were changed, looking for a change in logic for it and it ended up being just a name change... no other logical reason. |
| [17:03:13] | dblain: | I understand no one likes the way I format my code, and it will be changed over time. I just wish they formatting changes would be in a seperate commit so we can verify a that a typo wasn't made in the sake of formatting. |
| [17:04:04] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [17:04:16] | dblain: | s/they/the |
| [17:04:30] | gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [17:04:30] | gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [17:04:31] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [17:06:41] | dblain: | As for helping me, yes, converting all the code to a standard, single implemenation of a threadpool is a good thing, but the fact that you changed existing, working code doesn't help me, it helps the project. |
| [17:11:40] | kormoc_afk is now known as kormoc | |
| [17:18:16] | danielk22: | heh, I meant help you in reviewing the code by pointing out the class where the review worthy changes occurred. |
| [17:19:33] | danielk22: | The thread pool changes are for the project of course ; having one thread pool to debug in the future instead of several. |
| [17:19:53] | dblain: | Agreed that the thread pool changes are a good thing. |
| [17:20:36] | dblain: | I haven't had time to look at your implmenation to see why a standard Qt thread pool would work, but I'm sure you have your reasons. |
| [17:20:49] | danielk22: | Merging the thread pools also pointed to an improvement to the thread pool class, the timeout on startReserved so that we don't start too many threads unnecessarily. |
| [17:20:50] | dblain: | wouldn't... |
| [17:21:16] | marsilainen (marsilainen!~matt@host-78-145-174-218.as13285.net) has joined #mythtv | |
| [17:21:55] | danielk22: | dblain: That is mostly for the sake of the DB connection handling, which was the motivation for MThread as well. |
| [17:22:45] | dblain: | Makes sense... the DB connection issues have been around for a long time. |
| [17:23:28] | dblain: | I was always surprised the way we used a connection from mulitple threads hasn't caused more issues than it has. |
| [17:24:55] | dblain: | danielk22: different topic... As I understand it, you have issues with the way I designed/implemented the API Framework. There were many reasons why I implemented the way that I did. Maybe we can discuss what you concerns are when you have time to review it in more detail |
| [17:25:09] | danielk22: | Yeah, it kinda sorta worked because the Qt DB classes are re-entrant and we only used each connection in one thread at a time.. but the DB connection shutdown and reconnect handling was where we got in trouble. |
| [17:26:15] | danielk22: | dblain: Yeah, to start with I really do like how it handles the json XML generation. It's very clever. |
| [17:26:21] | ** dblain has to start proof reading his messages... many, many spelling mistaks and typos :( ** | |
| [17:27:24] | dblain: | In the grand scheme of things, if I had the power, the DataContract classes would be used as the primary data model classes throughout the code, so there wouldn't be any duplication of definition |
| [17:27:58] | danielk22: | dblain: My main problem is that there it lives in different places and there are things like whole classes pretty much duplicated for thunking purposes. I'm also concerned about the use of C++ exceptions, but that I can live with if it's all contained so the exceptions don't leak into general mythtv code. |
| [17:29:25] | danielk22: | dblain: right, if the contract classes were interfaces that our general data classes used that would avoid a lot of duplication. But it's my undestanding that for reflection to work these need to inherit from QObject which creates it's own problems. |
| [17:29:45] | dblain: | Well, the exceptions are used since the only way to send data back to the caller is through the return value. (no pointers/references as parameters). So I needed a way for the method to signal a problem... exceptions were the logical choice. |
| [17:31:30] | danielk22: | yeah, I understand. The problem here is really the C++ doesn't enforce something like Java throws which creates a maintenance problem when new exceptions are added that weren't in place when someone first used a class. |
| [17:32:09] | danielk22: | As long as there is a top level try catch(...) it shouldn't leak outside of code ready to deal with exceptions. |
| [17:32:46] | dblain: | Yes, it does need to inherit QObject. Lets take ProgramInfo as an example. If the Functionality/code was moved to a service (methods) only class and it always operated on the datacontract's version of the ProgramInfo class, it would be a win/win. The methods could be called by anyone, and the data would not need to be duplicated/mapped to other formats. Hard to convey the details, but I |
| [17:32:46] | dblain: | hope you get the overall meaning. |
| [17:34:02] | dblain: | BTW: My hope was that all the service classes implemented would eventually be the may api for all of myth (direct use, not using the Web Service layer) |
| [17:34:24] | dblain: | s/may/main |
| [17:35:03] | danielk22: | Yeah, I do. That was my first thought about how to avoid the duplication, but the problem is that QObject adds restrictions that make it unsuitable as a pure interface. Notably it must be the first class in multiple inheritence and you can't implement two "interfaces" in one class that inherits from QObject. |
| [17:35:27] | danielk22: | As for the thunk, class ScriptableChannel is an example... there must be a better way to handle this... |
| [17:36:37] | dblain: | The difference between the way we are thinking is that I wouldn't treat the DataContract classes as an interface, but as the actual class that everything uses to hold the data. |
| [17:37:24] | danielk22: | Can you explain with ProgramInfo as an example? |
| [17:37:33] | dblain: | I agree that there should be a better way to handle the ScriptableChannel classes. I think I even said that in the comment. I just haven't had the time to figure one out yet. |
| [17:38:49] | danielk22: | Yeah, if you could explain the problem better there I might be of assistance. Is the problem that out classes have their own metaobject id != QObject meta object id? |
| [17:40:31] | dblain: | The programInfo class doesn't just hold the data that represents a program. I also has methods that perform operations on that data (for example, to serialize it to the mythprotocol string format, ). |
| [17:41:26] | danielk22: | Ah, so you are thinking keep programinfo as is, but give it a container that actually contains it's data? |
| [17:41:27] | dblain: | If we seperate the methods from the data, then the DataContract Class that represents a Program could be used |
| [17:41:33] | dblain: | yes. |
| [17:41:50] | danielk22: | Right, and then you don't have the QObject inheritance problems because you are using composition. |
| [17:42:56] | dblain: | correct, and we would have a single representation of a Program that can be used internally and exposed through services. Plus it gives us greater flexibility with using scripting without having to map data constantly. |
| [17:43:21] | dblain: | As for the Scriptable issue... |
| [17:44:23] | dblain: | I want to make sure that each service exposes functions with type specific return types, so it could easily be used for internal use (non-webservice calls). |
| [17:44:37] | danielk22: | dblain: If you want to go ahead and implement that with program info or a simpler container I'd be glad to do a code review and help come up with a good conversion recipe. |
| [17:46:05] | dblain: | I should of started with the fact that the Scriptable class is only needed for methods that return pointers to QObject derived objects... |
| [17:46:41] | dblain: | To make it type specific, function prototype must return a pointer to the derived type i.e. DTC::Program* |
| [17:48:14] | danielk22: | So the only difference in the example class is that GetChannelInfoList returns DTC::ChannelInfoList* in the Channel class and QOjbect* in the ScriptableChannel class. |
| [17:48:15] | dblain: | The QtScript engine creates a Javascript prototype when we register a QObject derived class. It uses the metadata to build what it thinks is the correct syntax. |
| [17:49:03] | dblain: | when it sees the DTC::ChannelInfoList* (in you example) it creates a prototype that returns a Variant instead of the actual object. |
| [17:49:34] | dblain: | if we return a QOject* it creates a prototype that returns the actual object so it allows us to use it with out casting in javascript. |
| [17:49:38] | danielk22: | Since QtScript engine doesn't know that what GetChannelInfoList returns points to a class with a vtable it never discovers that it is a QObject* |
| [17:50:14] | dblain: | correct. That is also why classes that only return intrinsic types doesn't need the QScriptable wrapper class. |
| [17:50:48] | stuartm: | wagnerrp, sphery: I've working on a very simple patch which implements the 'standby' mode I proposed for the frontend but without the UI bits, I want something I can easily backport to 0.24.2 and I'll leave the UI aspects to go into master – when it's ready I'd appreciate some feedback |
| [17:51:08] | dblain: | It's a tradeoff. If our main service classes returned QObject* all the time, it would work without the wrapper classes, but every call to it from C++ would need to cast. |
| [17:51:10] | danielk22: | So if we made the policy decision that any pointer returned from a service must be QObject* derived we could potentially smarten up QtScript and get rid of the thunk class. |
| [17:51:42] | dblain: | yes, but as I said above, it would make it more difficult to use from within C++. |
| [17:52:35] | stuartm: | I'm a little disappointed in the shutdown/wakeup stuff as it exists right now, it's just not suitable for my production frontend (combined fe/be) and hence the desire to get a working solution into the 0.24 branch |
| [17:52:40] | dblain: | Just like the data classes, I don't like functionality to be duplicated. I hoped that the service classes would be used internal as well as exposed to scripting and web service calls. |
| [17:53:18] | danielk22: | dblain: but I'm saying it would just need to be QObject derived, you could still return DTC::ChannelInfoList*... |
| [17:54:19] | danielk22: | Right now the QtScript engine can't do a dynamic cast to QObject because it doesn't know that the class has a vtable... but we could enforce that in policy. Part II of course is can we make QtScript do the dynamic cast. |
| [17:54:27] | dblain: | That's were I wasn't clear. The method must be defined to return QObject* for the script engine to work correctly. |
| [17:55:01] | wagnerrp: | stuartm: i can look at the handful of protocol issues, but the rest is likely in code ive never read through |
| [17:55:12] | wagnerrp: | might want to mention it to paul-h |
| [17:55:20] | danielk22: | Or a static cast for that matter, if we know all the classes are QObject derived a static_cast is safe. |
| [17:55:53] | danielk22: | dblain: where is the QtScript code? |
| [17:56:02] | danielk22: | (our qtscript code) |
| [17:56:10] | stuartm: | wagnerrp: fair enough |
| [17:56:49] | stuartm: | the mention of protocol issues has me a little worried, have I overlooked something? |
| [17:57:20] | dblain: | danielk22: mythbackend\mediaserver.cpp is where our classes are registered with the QtScript Engine. |
| [17:57:39] | dblain: | That is the point the javascript prototype is automatically generated. |
| [17:58:01] | wagnerrp: | stuartm: not that i know of, the only things i know of are calling BLOCK_SHUTDOWN and ALLOW_SHUTDOWN |
| [17:58:07] | stuartm: | atm I've assumed that's it's enough to have the frontend change the playbacksock to non-blocking mode |
| [17:58:13] | wagnerrp: | as well as making sure reconnection works properly |
| [17:58:22] | danielk22: | dblain: this stuff?: pEngine->globalObject().setProperty("Myth", pEngine->scriptValueFromQMetaObject< ScriptableMyth >() ); |
| [17:58:34] | dblain: | danielk22: The other code that uses the script engine, is in libmythupnp, but it only takes the script code and has the engine execute it. |
| [17:58:39] | dblain: | yes |
| [17:59:02] | stuartm: | wagnerrp: right, that's all that I've done for now, is sending ALLOW/BLOCK when we become idle |
| [18:00:19] | dblain: | danielk22: To make a classes functions be exposed, they must be defined as public slots and the class must be derived from QObject. |
| [18:00:20] | stuartm: | reconnection should be ok, but maybe not as graceful as it could be, I've not tested the changes yet and I need to fake/setup a remote frontend to see how well that works |
| [18:00:41] | danielk22: | dblain: Thanks, I need to do some reading up on this stuff, but I'll do that this week. |
| [18:01:22] | danielk22: | dblain: and we need to use the property macros too, or is that just to to reduce the boilerplate code burden? |
| [18:01:27] | dblain: | danielk22: np, I did a lot of research and tried multiple variations to come up with the cleanest solution. |
| [18:01:30] | stuartm: | I suppose we should allow the frontend to wakeup the backend when it exits 'standby', I'll see about adding that |
| [18:02:28] | dblain: | danielk22: the property macros that I wrote were to reduce redundant code... the Qt property macros must be used at a min in the data contracts classes. |
| [18:02:32] | danielk22: | dblain: Yeah, it's obvious a lot of work went into this. |
| [18:04:45] | dblain: | danielk22: If you have any questions while doing the research, let me know. My schedule is booked, but I try to check IRC and e-mail when I have a few minutes down time. |
| [18:05:02] | danielk22: | It also feels like some of the code duplication was done to avoid stepping on other ppls containers like with ProgramInfo, but it's better to just get this into the core and avoid having containers defined in multiple places even if it means the bugs will affect more people initially, it will mean fewer bugs over time. |
| [18:06:50] | dblain: | danielk22: I definitely tried to avoid making large changes to the base code even if it would of allows no duplication. I didn't feel I had the power to make such a invasive change. |
| [18:07:18] | ** dblain shame on me... didn't proof read again! ** | |
| [18:08:17] | danielk22: | dblain: It's better to just discuss that kind of stuff and then do it and make it available for code review. |
| [18:10:41] | dblain: | True, but there was a lot of big changes going on at that time, and I had been sitting on this code for over a year (it was taking more and more time keeping it in sync). So I figured, it was safest to implement it the way I did. ( hindsight is always 20/20 ) |
| [18:11:11] | stuartm: | just so I'm clear, is the script stuff going to affect the use of these containers internally or will everything remain C++? |
| [18:11:46] | dblain: | stuartm: everything is remaining c++. |
| [18:12:27] | dblain: | If the container is derived from QObject and implements Qt properties, it would also be available when scripting. |
| [18:12:40] | danielk22: | stuartm: yeah, that's what we were just discussing, by using composition classes like ProgramInfo remain exactly the same externally, but internally store their data in a container using Qt properties. |
| [18:12:42] | dblain: | The current DTC:DataContract objects are defined this way. |
| [18:13:38] | stuartm: | dblain: ok cool, as you can probably guess I've not had the time to read through what you've created, I was just concerned that I was going to be rapidly left behind as the APIs and even the language potentially changed |
| [18:13:46] | danielk22: | stuartm: As I understand it they will just gain some methods to extract the scriptable interface. |
| [18:14:08] | stuartm: | danielk22: right, that seems reasonable :) |
| [18:15:23] | paul-h: | stuartm: what are you trying to do? Shut down a combined FE/BE when it's idle? That's what MythWelcome/MythShutdown and the BE shutdown settings and code was designed for |
| [18:16:04] | ** dblain is headed to a meeting, will check back later ** | |
| [18:16:05] | danielk22: | dblain: I'm not sure on the object lifetime of the data container; will it extract a copy with it's own lifetime, or will it be a pointer into the parent (ProgramInfo say). |
| [18:16:26] | wagnerrp: | paul-h: basically, thats the plan |
| [18:16:38] | wagnerrp: | move the functionality that mythwelcome offers directly into mythfrontend |
| [18:16:54] | wagnerrp: | along with an idle timer that will automatically drop back to 'mythwelcome mode' after a certain period of time |
| [18:17:57] | dblain: | danielk22: Depends on how it's implemented and what the requirements are. |
| [18:18:09] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [18:18:37] | paul-h: | wagnerrp: The BE would still do the shutdown not the FE right |
| [18:19:05] | wagnerrp: | the BE would simply be allowed to shutdown on its own now |
| [18:19:32] | wagnerrp: | using the existing mechanism where the master will shutdown itself, and decide to shut down slaves |
| [18:19:48] | wagnerrp: | although, i think there is some work that needs to be done with respect to slave backends running a frontend |
| [18:20:10] | dblain: | danielk22: from a thread safety perspective, It would be safest if the methods returned a copy of the object, but with performance being a concern, there is no reason the data classes can't be made thread safe (each property has a get/set function) and we could return a shared or reference counted pointer. |
| [18:20:12] | wagnerrp: | i think i recall Captain_Murdoch mentioning that it does not check to see if there are any other applications connected on that host at the time |
| [18:25:14] | xris (xris!~xris@xris.forevermore.net) has quit (Changing host) | |
| [18:25:14] | xris (xris!~xris@mythtv/developer/xris) has joined #mythtv | |
| [18:32:23] | anykey_ (anykey_!~guedel@46-126-245-147.dynamic.hispeed.ch) has quit (Ping timeout: 252 seconds) | |
| [18:32:24] | brfransen (brfransen!~brfransen@216.254.250.47) has quit (Read error: Connection reset by peer) | |
| [18:33:16] | anykey_ (anykey_!~guedel@46-126-245-147.dynamic.hispeed.ch) has joined #mythtv | |
| [18:34:26] | brfransen (brfransen!~brfransen@216.254.250.47) has joined #mythtv | |
| [18:59:10] | stuartm: | paul-h: I don't want to use mythwelcome/mythshutdown, I don't really seem them as a user friendly solution, mythwelcome requires the user to remember to exit the frontend for example |
| [19:00:23] | Kunalagon (Kunalagon!~Kunalagon@212.200.241.62) has quit (Quit: Leaving.) | |
| [19:01:51] | stuartm: | and from a setup POV you need mythwelcome to be running before the frontend, so automatic shutdown doesn't 'just work' for distros like mythbuntu without messing with scripts, it just seems tidier altogether if that functionality is part of the frontend |
| [19:04:05] | cattelan is now known as cattelan_away | |
| [19:05:46] | cattelan_away is now known as cattelan | |
| [19:10:54] | stuartm: | paul-h: I've already decided that I'm not going to touch mythwelcome/mythshutdown, so even though they may no longer be required they'll still be available for those who prefer something they are more familiar with |
| [19:21:40] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [19:26:29] | stuartm: | heh, I've missed an entire series of an american remake because they used the same subtitles as the original dutch series which I'd recorded earlier in the year |
| [19:41:44] | Beirdo: | gah, lots of backlog to read :) |
| [19:42:22] | Beirdo: | danielk22: so I take it we don't need the patches now, mthread is in master? |
| [19:42:45] | danielk22: | Beirdo: yep |
| [19:42:55] | Beirdo: | cool ;) |
| [19:43:22] | Beirdo: | I like that shutdown identifies which threads are dangling. |
| [19:43:26] | Beirdo: | nice touch :) |
| [19:43:28] | danielk22: | I couldn't sleep so I did some early morning final testing. |
| [19:43:53] | Beirdo: | Ahh, been there. |
| [19:45:15] | Beirdo: | as for the logging... I think the change to use the QWaitCondition may have been what removed the flush on shutdown (which may not have been working correctly, who knows) |
| [19:45:35] | Beirdo: | basically, we don't want to wait on the shutdown condition until the queue is empty if you wanna flush |
| [19:46:10] | Beirdo: | so rather than in the while(), it would be in the if() where the queue is empty |
| [19:46:45] | Beirdo: | (this is going from memory, not looking right at the code) |
| [19:47:22] | Beirdo: | and we wouldn't want logStop() to return until both threads are done. Not sure if we have that currently or not, it's been a while |
| [19:48:03] | Beirdo: | OK, it waits for logThread, which waits for the dblog thread. |
| [19:48:04] | Beirdo: | OK |
| [19:49:50] | Beirdo: | hmm, looks like it's already all setup that way. |
| [19:50:05] | Beirdo: | I guess we just need to test to make sure it flushes as expected. |
| [19:51:15] | Beirdo: | I'm thinking that the second m_wait->wait() in the DBLoggerThread where it requeues will be an issue |
| [19:52:33] | Beirdo: | that if !m_logger->logqmsg(item) should just discard the message if aborted is true, and the timeout should not be using the wait. That way the wait is only ever triggered when the queue is empty |
| [19:53:35] | Beirdo: | I dunno. I'm not thinking straight yet. Let me go score more coffee |
| [19:54:43] | danielk22: | heh, i haven't had a look at it yet.. so far i'm just making my wish list. |
| [19:55:38] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [19:55:45] | Beirdo: | Cool. Feel free to tinker. I'd appreciate being kept in the loop so if I need to go fix things I understand what's there, but the code's there, this is open source, etc... |
| [19:56:03] | Beirdo: | I try not to be *too* possessive over my code after all :) |
| [19:56:35] | Beirdo: | heh, and I see I need to sweep through there and reformat some ifs... |
| [19:57:11] | Beirdo: | if they but ya while you're going through, feel free. I don't know how I got into the habit of doing if( blah ), but I'm trying to change it to if (blah) |
| [19:57:20] | Beirdo: | old habits do die hard though |
| [19:58:20] | Beirdo: | on a function declaration, do we want void funcname( args ) or void funcname(args)? |
| [19:58:24] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 255 seconds) | |
| [20:12:03] | VManiac16 (VManiac16!~Unknown@69.4.155.83) has quit (Ping timeout: 240 seconds) | |
| [20:16:05] | zombor_ is now known as zombor | |
| [20:24:07] | danielk22: | Beirdo: void funcname(args) |
| [20:24:48] | Beirdo: | OK, another habit to fix. I'll sweep through logging.cpp one of these days, feel free to adjust as you go through though. |
| [20:25:10] | Beirdo: | and same goes for mythsystem, I'm sure :) |
| [20:25:50] | Beirdo: | I'll retrain myself, there's no particular reason that I've done it that way that I know of, and now I have a standard to follow that work just as well, so... :) |
| [20:35:11] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [20:59:39] | MaverickTech (MaverickTech!~MaverickT@124-168-38-107.dyn.iinet.net.au) has joined #mythtv | |
| [21:07:01] | andreax (andreax!~andreaz@p57B9313D.dip.t-dialin.net) has joined #mythtv | |
| [21:09:46] | stuartm: | danielk22: sagfault in MThread when running mythpreviewgen – http://pastebin.com/8iTUrpFP |
| [21:10:02] | stuartm: | well more of a segfault than a sagfault |
| [21:13:46] | danielk22: | stuartm: looks like it might be a double delete, "locker = {val = 6}" and "this=0x60b080" look suspicious. |
| [21:24:02] | danielk22: | ah, the problem is dynamic library static initialization order... We're creating s_readyread_thread before s_all_threads_lock has been initialized... |
| [21:25:27] | Beirdo: | how odd, it hadn't done that for me all weekend... |
| [21:26:02] | jmartens: | Hi all! Who´s fathering the windows patches/build? |
| [21:26:44] | danielk22: | yeah, i'm not seeing it either, but we shouldn't depend on the order that statics are initialized across compilation units anyway. |
| [21:27:01] | Beirdo: | yeah. :) |
| [21:28:07] | stuartm: | that's what I'm here for ;) |
| [21:28:17] | stuartm: | jmartens: that's an interesting question |
| [21:28:27] | danielk22: | stuartm: Can you just move the last line of the SOURCES lines in libmythbase.pro to be the first and confirm that makes the problem go away? Then I'll try to think of how to really solve it :) |
| [21:28:38] | stuartm: | danielk22: sure |
| [21:28:40] | Beirdo: | Hmm, I should use my new devel box to bring up a Windows VM to get a buildbot setup for Windows tested |
| [21:28:40] | jmartens: | stuartm: Interesting? Why? Care to explain? |
| [21:28:55] | jmartens: | Beirdo: I have a windows buildbot running. |
| [21:28:56] | stuartm: | jmartens: because I don't know the answer |
| [21:29:01] | Beirdo: | then kenni had a Windows box he was willing to use. |
| [21:29:10] | jmartens: | stuartm: lol |
| [21:29:37] | Beirdo: | jmartens: care to share the config? We could use a windows buildslave, and the corresponding config |
| [21:30:07] | Beirdo: | if you want your box as an official buildslave, I doubt you'll hear any complaints :) |
| [21:30:23] | Beirdo: | the problem has been that of time and priorities, and we just haven't gotten to it yet |
| [21:30:45] | Beirdo: | same goes for OSX which stuarta is working on, in his copious spare time :) |
| [21:30:54] | jmartens: | We can try... it is a xen based winxp 32 bit system. What needs to be done to hook it up? I have kept it as close to the configuration and build steps you are using. |
| [21:31:17] | stuartm: | where priority for windows still falls below that of OSX and linux by virtue of the fact that most devs don't use windows, or even have it available to them |
| [21:31:21] | Beirdo: | you have the buildbot steps all configured? |
| [21:31:47] | jmartens: | Yes. I even have it running, but it fails as the patch from ticket 9957 is needed. |
| [21:31:55] | j-rod is now known as j-rod|afk | |
| [21:31:59] | Beirdo: | stuartm: yeah, that's always been the case... having a buildslave should drastically reduce the turnaround time on things that we break :) |
| [21:32:36] | Beirdo: | ahh |
| [21:32:50] | Beirdo: | I meant to claim that one, as much of it's in my code anyways. |
| [21:32:53] | Beirdo: | there, claimed |
| [21:33:27] | Beirdo: | I think for the MAX(), I may go about it a different way, but regardless... |
| [21:33:58] | Beirdo: | I'll look at getting that in tonight. |
| [21:34:28] | jmartens: | Beirdo, perhaps you can also have a look at ticket #9969, it makes configuring on windows easier and I see no harm for other builds. |
| [21:34:30] | Beirdo: | jmartens: well, if you have a master.cfg that we can take the Windows buildsteps from as a starter, that would be an incredible help |
| [21:34:50] | jmartens: | I can send you one, where would be convenient to place it? |
| [21:34:52] | Beirdo: | hehe, that also was my code. :) |
| [21:35:11] | Beirdo: | claimed... I don't think nigel will mind. |
| [21:35:24] | Beirdo: | Umm, you could email it to me at gjhurlbu@gmail.com if you want. |
| [21:35:39] | Beirdo: | removing any password info you wish, of course :) |
| [21:36:32] | Beirdo: | well, look at that... just picked up two tickets to work on in a couple hours. :) Always good to get them claimed and worked on. |
| [21:37:41] | andreax (andreax!~andreaz@p57B9313D.dip.t-dialin.net) has quit (Quit: Leaving.) | |
| [21:38:06] | ** stuartm gives Beirdo the evil eye ** | |
| [21:39:04] | Beirdo: | yes? |
| [21:39:37] | Beirdo: | just trying to reduce our pile of open tickets... hehe |
| [21:40:00] | stuartm: | and make the rest of us feel lazy ;) |
| [21:40:06] | Beirdo: | sorry |
| [21:40:42] | Beirdo: | 355 open. jeez. If we ever whittle that down to double digits, I say we should all get together and consume massive quanities of booze. |
| [21:41:23] | stuartm: | danielk22: as expected that did the trick |
| [21:41:49] | Beirdo: | stuartm: you always seem to find those corners in our code :) You and okolsi :) |
| [21:42:09] | stuartm: | Beirdo: 355 is a sorry figure, but there's reason to feel hope, I remember when it was over 600 |
| [21:42:10] | jmartens: | Beirdo, I have sent you the files by mail. |
| [21:42:22] | Beirdo: | Yeah, we've been far far worse off |
| [21:42:39] | stuartm: | Beirdo: I'm a magnet for bad luck and bugs ;) |
| [21:42:52] | Beirdo: | got em. Thanks. Another thing to look at in detail tonight. |
| [21:43:31] | Beirdo: | jmartens: were you thinking of using your box as an official slave for Windows building? |
| [21:43:37] | jmartens: | Beirdo: I am off for know, but feel free to ping me, preferably by mail as I do not monitor irc regularly. |
| [21:44:12] | Beirdo: | OK, will do. We have the usual timezone fun to deal with. |
| [21:44:26] | stuartm: | Beirdo: what concerns me right now is that there's a bit of a drop in the number of active developers which isn't going to make closing the ticket backlog any easier |
| [21:44:40] | jmartens: | Beirdo: I might, but I will have to check my license first to make sure... it was a quick test install I used for other purposes first. I am not sure that it is running a valid license, it might still be the one of the company I work for. |
| [21:44:56] | Beirdo: | yeah, it makes the load on the rest of us heavier, which tends to burn people out... leading to a vicious cycle. |
| [21:45:36] | Beirdo: | jmartens: fair enough. I'll try to get a VM up and running, likely 64-bit XP as well, just for my own testing if nothing else |
| [21:46:27] | Beirdo: | stuartm: I do like fixing tickets though. It can feel quite nice at times. |
| [21:46:52] | Beirdo: | likewise squashing compiler warnings, a sideline you seem to enjoy some too. |
| [21:50:00] | stuartm: | squashing compiler warnings is what I like to do when I need to give my brain a rest :) It's easy, it's better than doing nothing at all but I don't have to think too hard |
| [21:51:33] | stuartm: | occasionally it fixes really obscure bugs too |
| [21:53:57] | stuartm: | some tickets are just as easy, but reviewing/testing can be a pain ;) |
| [21:54:18] | danielk22: | stuartm: don't worry about closing every ticket... many bugs are just too small too worry too much about, at least until you are visiting that same code for some other reason. |
| [21:55:09] | danielk22: | It's the big bugs, like the mysql backend instability we've been chasing that worry me. |
| [21:57:04] | stuartm: | getting the ticket numbers down is more about making the more important tickets easier to see, it's not difficult for tickets to get forgotten/overlooked when there are so many open, but I take your point |
| [21:57:32] | Beirdo: | danielk22: yeah, quantity vs. quality of ticket, for sure... |
| [21:58:00] | Beirdo: | it's still nice to get rid of some of the easier ones that make up the bulk |
| [21:59:35] | Beirdo: | looks like #9966 is showing a NULL string insert. We'll be seeing a few of those for a bit :) |
| [22:01:12] | Beirdo: | stuartm: how are you on the q3ptrlist replacement code I have? |
| [22:01:19] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [22:02:04] | Beirdo: | just looking for a general update, would be nice to get that all committed to master at some point. |
| [22:03:15] | stuartm: | Beirdo: sorry, I just haven't got around to looking at it |
| [22:03:21] | Beirdo: | OK |
| [22:03:41] | Beirdo: | http://www.beirdo.ca/git/mythtv/commit/?h=q3ptrlist |
| [22:03:46] | stuartm: | Beirdo: go ahead and commit, that will force me to make the time ;) |
| [22:03:47] | Beirdo: | in case you needed the URL :) |
| [22:04:44] | Beirdo: | OK, fair enough. I know danielk22 has done a once-over on it, and found some minor stuff to update. It seems to be working, as far as I can tell, but certainly should be mostly there if something was missed. |
| [22:05:17] | Beirdo: | I'll push that in now, and we can watch for more reports, etc. |
| [22:08:26] | Beirdo: | OK, pushed. We'll deal with fixing remaining issues as they come up :) |
| [22:09:53] | Beirdo: | I find it interesting how many new warnings we have with the newer gcc on the new ppc slave. |
| [22:10:25] | Beirdo: | some of those may actually need some attention, hiding latent bugs |
| [22:10:56] | Beirdo: | but many many of them are -Wunused-but-set-variable |
| [22:11:41] | Beirdo: | which, if they aren't bogus, could help us clean up our code significantly, it seems |
| [22:11:52] | stuartm: | yeah, I've been meaning to start fixing some of those ever since I upgraded to gcc 4.6.1 but the important ones get a little lost in the noise created by -Wunused |
| [22:12:29] | Beirdo: | I guess we could hack in a -Wno-unused-but-set-variable to get a short list |
| [22:12:34] | stuartm: | the unused-but-set warnings aren't completely useless, some of them are bound to be bugs, variables that shouldn't have been ignored |
| [22:12:40] | Beirdo: | yeah |
| [22:13:00] | Beirdo: | if you set and don't use, it's either old cruft, or mistakes like that, usually |
| [22:13:18] | Beirdo: | either one could use attention on a rainy day |
| [22:14:30] | Beirdo: | likewise some of the warnings in FreeBSD |
| [22:15:03] | Beirdo: | like... control reaches end of non-void function |
| [22:15:07] | Beirdo: | that's a buglet. |
| [22:15:45] | Beirdo: | ah. #ifdef __linux__... |
| [22:15:52] | Beirdo: | and no return in an else |
| [22:16:30] | stuartm: | yeah, I was going to say that was probably an ifdef issue |
| [22:16:44] | Beirdo: | yup, committing the super-simple fix |
| [22:17:51] | Beirdo: | there. |
| [22:18:54] | stuartm: | ok, frontend idle timer basically works |
| [22:19:26] | Beirdo: | gah, still need to fix the smolt sendProfile.py |
| [22:19:32] | Beirdo: | I keep forgetting |
| [22:20:05] | Beirdo: | it only screams at me every time I start the frontend. |
| [22:21:10] | stuartm: | heh, almost but not quite, the jump point still seems to be triggering keypress events which boot us back out of 'standby' |
| [22:21:33] | Beirdo: | hehe, oops |
| [22:22:41] | Beirdo: | I feel like telling the -users ML thread to try master again for the recent database cleanup that came with mthreads |
| [22:23:21] | stuartm: | just give a suitable health warning |
| [22:23:53] | Beirdo: | well, they are already tinkering with master, and saying "it's worse", but not saying if they have *current* master |
| [22:24:37] | stuartm: | worse? yay |
| [22:24:59] | Beirdo: | well, the code before the cleanup could well have been worse |
| [22:27:12] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Quit: Leaving.) | |
| [22:28:08] | Beirdo: | meanwhile, my setup has seen those deadlocks maybe twice in the last year |
| [22:28:30] | Beirdo: | not something I can reproduce here, oddly enough. |
| [22:30:21] | MaverickTech (MaverickTech!~MaverickT@124-168-38-107.dyn.iinet.net.au) has quit (Ping timeout: 250 seconds) | |
| [22:30:23] | Beirdo: | ugh. #9961. How else to describe "what does it say on the terminal you ran mythfrontend on"? |
| [22:30:59] | Beirdo: | I'm looking to see what qWarning may have been spewed on the crash... he gave me something from a syslog file |
| [22:32:14] | Beirdo: | and from the frontend logs... it crashed bringing up the browser. I'm thinking that may well be the CookieJar issue I was looking at |
| [22:34:20] | marsilainen (marsilainen!~matt@host-78-145-174-218.as13285.net) has quit (Ping timeout: 250 seconds) | |
| [22:51:21] | stuartm: | sphery: how is that jumppoint/screenstack patch coming along? |
| [23:00:46] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [23:54:10] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 264 seconds) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.