| Thursday, November 21st, 2013, 00:25 UTC | ||
| [00:25:42] | dekarl (dekarl!~dekarl@p4FCEFD9F.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [00:35:37] | dekarl (dekarl!~dekarl@p4FE85548.dip0.t-ipconnect.de) has joined #mythtv | |
| [00:38:03] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 245 seconds) | |
| [01:16:12] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv | |
| [01:19:14] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Read error: Connection reset by peer) | |
| [01:19:36] | knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [01:19:36] | knightr (knightr!~Nicolas@69-165-170-178.dsl.teksavvy.com) has quit (Changing host) | |
| [01:19:36] | knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv | |
| [02:54:37] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [02:55:33] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [03:07:45] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 246 seconds) | |
| [03:08:48] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [03:26:15] | _nyloc_ (_nyloc_!~quassel@p5B26F443.dip0.t-ipconnect.de) has joined #mythtv | |
| [03:30:13] | nyloc (nyloc!~quassel@p3EE2C610.dip0.t-ipconnect.de) has quit (Ping timeout: 272 seconds) | |
| [04:32:53] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 252 seconds) | |
| [04:34:47] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:40:08] | wolfgang4 (wolfgang4!~wolfgang@ppp-82-135-84-119.dynamic.mnet-online.de) has joined #mythtv | |
| [04:43:41] | wolfgang3 (wolfgang3!~wolfgang@ppp-46-244-222-177.dynamic.mnet-online.de) has quit (Ping timeout: 272 seconds) | |
| [05:47:14] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [06:14:11] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [06:22:17] | len_ (len_!~quassel@67-6-37-92.mpls.qwest.net) has quit (Remote host closed the connection) | |
| [07:07:55] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [08:01:29] | Chutt_ (Chutt_!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [08:04:28] | Chutt__ (Chutt__!~ijr@2605:a000:1208:c08c:2d4b:d6ef:d786:24f4) has joined #mythtv | |
| [08:05:05] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Ping timeout: 272 seconds) | |
| [08:07:13] | Chutt_ (Chutt_!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Ping timeout: 245 seconds) | |
| [08:20:15] | Chutt__ (Chutt__!~ijr@2605:a000:1208:c08c:2d4b:d6ef:d786:24f4) has quit (Read error: Connection reset by peer) | |
| [10:27:35] | _charly_ (_charly_!kroseneg@sunrise.schmidham.net) has quit (Ping timeout: 272 seconds) | |
| [11:45:17] | neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv | |
| [13:35:23] | biggaz__ (biggaz__!~biggaz@host86-179-169-93.range86-179.btcentralplus.com) has joined #mythtv | |
| [13:42:09] | biggaz__ (biggaz__!~biggaz@host86-179-169-93.range86-179.btcentralplus.com) has quit (Ping timeout: 240 seconds) | |
| [14:20:21] | earthw0rm (earthw0rm!~biggaz@host86-179-168-11.range86-179.btcentralplus.com) has joined #mythtv | |
| [14:34:16] | biggaz_ (biggaz_!~biggaz@host109-150-87-117.range109-150.btcentralplus.com) has joined #mythtv | |
| [14:36:21] | earthw0rm (earthw0rm!~biggaz@host86-179-168-11.range86-179.btcentralplus.com) has quit (Ping timeout: 248 seconds) | |
| [14:46:21] | biggaz_ (biggaz_!~biggaz@host109-150-87-117.range109-150.btcentralplus.com) has quit (Ping timeout: 272 seconds) | |
| [15:21:09] | tonsofpcs (tonsofpcs!482b2962@rivendell/member/tonsofpcs) has joined #mythtv | |
| [15:51:28] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [15:53:55] | stuartm: | dblain: I can't help thinking that we need a simple struct-like type for most of the enums since we need to supply not just their name, but also translated strings for use in the UI without a mess of 'EnumValueToTranslatedString() endpoints' |
| [15:55:12] | stuartm: | IMHO we also need the ability to return all possible (usable) values to the services user – a GetEnum("DupMethod") type endpoint |
| [15:55:27] | stuartm: | but I'm not really sure how best to achieve that |
| [15:56:11] | stuartm: | Q_ENUM seems too simple (unfortunately) |
| [15:57:25] | Chutt (Chutt!~ijr@2605:a000:1208:c08c:c19a:4af7:74ff:85bf) has joined #mythtv | |
| [16:03:38] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [16:08:31] | dblain: | stuartm: Q_ENUM is still the solution. But it will require the Serializer classes to take on the burden of returning both # and name of the enum. (a sperate endpoint or enhancement to the WSDL urls, will still be needed for returning a complete list of name/values for any given enum) |
| [16:09:13] | dblain: | ie: XML serializer will use an attribute for the value <ProgramType tc=1>Comedy</ProgramType> |
| [16:09:52] | dblain: | while json can serialize a a subtype. ProgramType:{1,"Comedy"} |
| [16:10:22] | dblain: | (my json my be incorrect... but I think it convays my intentions) |
| [16:11:51] | _charly_ (_charly_!kroseneg@sunrise.schmidham.net) has joined #mythtv | |
| [16:15:57] | stuartm: | dblain: what about the translated strings/descriptions for use in a UI? What I'm trying to avoid for the WebFrontend is redefining those strings in JS so they need to be updated in two places, and I suspect services users might prefer not having to keep their own versions too |
| [16:16:51] | stuartm: | the solution so far has been endpoints like Dvr::RecStatusToString() but I'm not sure that's sustainable when you consider just how many enums we may be talking about |
| [16:18:15] | dblain: | stuartm: How are we going to handle knowing what language a certain browser session is? Is there a host header or cookie that is set/could be set to the users language of choice? |
| [16:18:44] | stuartm: | browsers send an Accept-Language header |
| [16:19:38] | stuartm: | but we may also ask or permit users to choose their preferred language – in most cases though, for the WebFrontend, it would be safe to assume that the language should be the same as the one configured for the backend |
| [16:19:57] | dblain: | I'll have to look into it, but maybe the serialization classes can access that header and use it to perform the translation?... Tricky part is, we don't always want to translate everything... do we? |
| [16:20:06] | stuartm: | multi-lingual households are the exception rather than the rule |
| [16:20:28] | dblain: | (or the setting) |
| [16:22:23] | stuartm: | dblain: it's really only for the UI that we want to be translating, which is why I was thinking of a more complex type than Q_ENUM, e.g. an object with 3/4 properties – integer value, constant name, translated name, translated description (longer string for use in help text etc) |
| [16:22:35] | dblain: | We'd need to define what is translated in the data returned... not sure if that is a viable option. The list properties to be translated could be abstracted out, but it could get messy... unless we limit translations to enums only |
| [16:23:27] | dblain: | stuartm: my only problem with that is I wanted to keep the classes/methods using normal C++ datatypes. |
| [16:23:57] | stuartm: | if you look at libmyth/recordingtypes.h you can see the sort of stuff I'm talking about |
| [16:24:28] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [16:26:04] | dblain: | stuartm: thinking more about this, I don't think we want to return that much data every time... I'm leaning more towards a dedicated service to return metadata on the enum (similar to the WSDL url's), but with all the variations you listed. |
| [16:26:46] | stuartm: | dblain: well we're already defining many larger custom classes/objects, is another more generic one so different? This is why I'm asking though, to see what other options might be available |
| [16:26:48] | dblain: | That way, a client can call it once and create a lookup/map of all potential values. this would allow us to always send one value down with the data (reduces size) |
| [16:27:16] | stuartm: | dblain: that fits in with what I was thinking |
| [16:27:46] | dblain: | Oh, I was assuming by your description, we would be sending down the variations on each record returned. |
| [16:27:57] | stuartm: | client requests the enum 'definition', listing all possible values/strings which they they store and use as required |
| [16:28:24] | stuartm: | dblain: no, sorry I guess I wasn't explaining myself very well |
| [16:28:50] | dblain: | stuartm: I'm fine with having a complex datatype for returning enum metadata. |
| [16:30:32] | dblain: | Question is, where does the enhanced data live? It would be nice if we could define it at the same time/place as we define the standard enum. (I still want to try and keep the actual datatype used by the properties and methods a simple enum) |
| [16:31:41] | dblain: | Translated value should be easy to generate at run-time, but longer text and help would be more difficult. |
| [16:32:29] | dblain: | This is where C# custome attibutes really shines (it allows custom metadata to be stored with types to be accessed with reflection) |
| [16:33:08] | ** dblain need to proof read before hitting enter... please ignore spelling ** | |
| [16:34:23] | stuartm: | yeah, the exact implementation is where I run out of inspiration, the original enums and methods for creating the strings need to be somewhere accessible to the serialiser, they need to be standardised to some extent but exactly how it all fits together I haven't a clue (yet) |
| [16:39:24] | dblain: | If you can wait a few days, I can take a look. It really is an extension/specialization of the WSDL support. |
| [16:39:24] | stuartm: | most of the enums have toString() or toDescription() functions which can easily be templated – http://code.mythtv.org/trac/browser/mythtv/my . . . vr.cpp#L1052 |
| [16:40:31] | jheizer: | Since there is going to be GetEnum() lookup function, what if the enum values are returned in all the specific cases now and just the lookup was used for details/translations |
| [16:40:31] | stuartm: | dblain: I'd be grateful, there's a lot I don't know about when it comes to the serialiser and wsdl |
| [16:40:36] | jheizer: | Could even have GetEnum("enumtype", language) |
| [16:42:05] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [16:46:16] | stuartm: | jheizer: the Accept-Language header seems more portable, combined with a 'Language' arg to the services constructors for the scripting interface. For now I'm happy to ignore the translation issues for the WebFrontend as it's something that's easily sorted later and I'd rather address one issue at a time |
| [16:46:43] | stuartm: | knightr: has suggested that switching the translator on the fly for particular strings is not as easy as I imagine |
| [16:47:36] | stuartm: | well, not as easy as the QT docs make it seem |
| [16:48:03] | jheizer: | Yeah, not as worried about them either, was more just thinking 2 bird with one stone and not have to modify all the current returns to be struts. |
| [16:48:16] | jheizer: | Since you are talking about adding a full lookup list function anyway |
| [16:49:41] | jheizer: | I started refactoring all my services calls last night in MobileMyth so I can more easily adapt to large changes and can help test along the way. |
| [16:50:11] | stuartm: | jheizer: well that's what we're proposing, return values for the classes will be enums (vs the current ints/strings), we'll then have a metadata lookup method that tells us a) All possible values for the enum b) Translated strings corresponding to each value |
| [16:51:39] | jheizer: | uh ok, by " extension/specialization of the WSDL support." I thought you guys were talking about making the strut of values the return of any enum properties of objects. |
| [16:51:50] | jheizer: | Nevermind, carry on. We are talking the same thing. |
| [16:52:06] | jheizer: | I miss understood |
| [16:57:51] | stuartm: | jheizer: well I'm not exactly sure what dblain means by that, but that's only because I don't know enough about wsdl |
| [16:58:48] | stuartm: | I trust dblain to know what he's doing and that his solution will be good, he's got everything else right so far :) |
| [16:59:03] | jheizer: | agreed |
| [17:01:21] | stuartm: | I'll go back to temporary hacks so I can get this schedule editor page finished, this time safe in the knowledge that it will only be temporary |
| [17:01:33] | dblain: | stuartm, jheizer: I meant that the WSDL code does all the introspection work to enumerate the enum's metadata... I would enhance/re-use/create a shared service, using that code as a starting point. |
| [17:41:48] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:42:04] | knightr: | stuartm, we already no longer multi-language household for MythFrontend so until that`s addressed I am not sure what there is to gain by trying to address this in the web frontend... |
| [17:44:43] | knightr: | We could, theorically, use the lower level QTranslator::translate() function to support many languages in different sessions but then everything using regular tr() calls (or similar) would no longer work correctly, it would use the translator installed at the app level... |
| [17:45:22] | knightr: | so everything in the libs (for example) would not but usable for the web frontend... |
| [17:46:35] | knightr: | the only way I can think of of properly supporting more language at the same time I believe you don't like is the have one web frontend process per session, we could then tie the translator to that process like we normally do... |
| [17:46:58] | knightr: | s/more language/more than one language |
| [17:47:11] | knightr: | s/is the have/is to have |
| [17:48:05] | knightr: | as for running lupdate on the qsp I believe they would need to be QtScript only, not a mix of QtScript and HTML like they currently are... |
| [17:51:22] | knightr: | oops, I really need a coffee... I meant that we already no longer support multi-language households in MythFrontend (the word "support" was missing...) |
| [17:52:46] | knightr: | I think that if we wanted to support a multi-language household we would need to add multi-user support first... |
| [17:54:01] | knightr: | (and change the language based on the user and fetch the movie/tv metadata for all of the users configured languages...) |
| [18:11:02] | dblain: | knightr: one solution for the qsp/jsp issue... Internally it parses each file creating a pure script in memory. We could have a tool that leverages that code and write them out to a file for lupdate to process. (not ideal solution, but I think it would get around the problem you mentioned) |
| [18:16:21] | knightr: | dblain, I thought about that too but we end up with something similar to what we currently do... |
| [18:16:40] | knightr: | (parse the files to generate intermediate files...) |
| [18:18:09] | knightr: | best bet would be to output that HTML from QtScript but that's a PITA too... |
| [18:18:32] | knightr: | (I kinda prefer the JSP-like look of those QSPs..) |
| [18:23:54] | knightr: | cleanest solution would be to submit a patch to the Qt guys to make it able to parse those files but there is no telling if they would accept it and it would take ages for it to be available to all our translators so not a solution... |
| [18:24:43] | knightr: | gotta go, ttyl... |
| [18:29:59] | stuartm: | I've thought a lot about different ways of keeping the script and the html separate, but ultimately there really isn't a practical way and it's already confusing enough with files for the css, the client side JS in addition to pure qsp files only serving up responses to AJAX calls |
| [18:31:55] | stuartm: | one page displayed to the user is the product of so many different components that it becomes quite complicated |
| [18:33:52] | stuartm: | modern websites and web applications are a lot of work to create/maintain :/ |
| [18:35:53] | stuartm: | on small change I might make to what I've done so far is to abstract some of the logic into script only includes to ultimately reduce code duplication between the desktop and mobile templates |
| [18:38:52] | dblain: | stuartm: When I was first putting the web server together, I thought about a type of "code behind" similar to asp.net, where the code is isolated from the presentation(html). It would of required a server side DOM of the html page and a lot of extra code to render the page... in the end I felt it was overly complicated for what it would be used for. |
| [18:39:44] | dblain: | small memory footprint and speed was high on my priority at the time. |
| [18:40:22] | SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has joined #mythtv | |
| [18:40:40] | stuartm: | dblain: what we've got is fine, it's no more or less complicated than php (inc various template libs), there really isn't any other way of doing it |
| [18:42:32] | stuartm: | we've already isolated 99% of the code simply by using the services API, there will always be that 1% (or more) of glue – some approaches use a markup based system of loops which are expanded in a pre-processor but that's really no different or better than what we've got now |
| [18:42:40] | dblain: | This other approach would of added specialized html tags which caused script code to render the html to replace it... but ultimately I agree... plus, we aren't designing a new web application platform :) (just have to keep telling myself that!) |
| [18:45:13] | stuartm: | IMHO, there's not enough of a difference between <foreach object="recordings"> ... </foreach> and for (var i=0; i < recordings.length; i++) { ... } |
| [18:46:13] | dblain: | it would of been more like <myth:GuideGride attribute='parameter'... /> |
| [18:47:05] | dblain: | with the myth namespace definition at the top of the file specifing the class that contains the GuideGrid method |
| [18:47:50] | dblain: | it would of been the method's responsibility to render out the raw html |
| [18:49:04] | dblain: | The code could be either script or c++.... but like I said, it's a bit of overkill for what we are using it for. |
| [18:49:48] | stuartm: | dblain: I think you'd end up sacrificing the flexibility we've got now with something like that, there's only so much you can do with css/js alone, as much as w3c might want otherwise, many display problems can only be solved through manipulation of the markup – whether it's adding additional divs or moving content to different parts of the screen etc |
| [18:50:02] | ** dblain puts on the "lets create a new web app platform hat"... unless everone want's that design! :D ** | |
| [18:50:55] | dblain: | It would simplify some things, but add new complexities ... I'm happy with what we have now... for now at least :) |
| [18:54:12] | stuartm: | dblain: at some level I do actually like that idea, it's similar to the way the frontend UI works with xml simply declaring where a widget is placed and some details of it's behaviour |
| [18:55:26] | stuartm: | at one time I very seriously considered having mythui 'render' into html, so we'd only need to define frontend screens the once, and they'd work inside a browser |
| [18:56:51] | stuartm: | it's fair to say I was quite excited by the challenge of making that a reality, even if it never really was very practical it would have been fun |
| [18:57:26] | dblain: | stuartm: thinking about it... to add what I said above (which is not the entire design I originally was thinking of), might not be too difficult and would be in addition to what is available now... but also, the same behavior can be emulated with <%=GuideGrid(parameters);%> |
| [18:58:43] | stuartm: | having spent some weeks on this webfrontend now, I'm not ready to throw what I've got into the bin and start all over |
| [18:58:59] | dblain: | stuartm: The shared markup (with unique themes) sound interesting... |
| [18:59:14] | dblain: | don't blame you! |
| [18:59:52] | stuartm: | we can definitely revisit this later though |
| [19:00:05] | dblain: | BTW: other than escaping issues with spanish channel guide data, the WebFrontent renders ok with IE11 |
| [19:00:17] | stuartm: | great |
| [19:00:29] | stuartm: | what sort of escaping issues? |
| [19:00:36] | dblain: | Haven't tried you lazy load code yet. |
| [19:01:17] | dblain: | I haven't tracked down the cause yet, but once it hits a description with any spanish, it stops applying the css. |
| [19:02:11] | dblain: | when I have time, I'll see if I can isolate the data that causes it. |
| [19:03:49] | stuartm: | could be some markup that I didn't account for in my html escaping, but I can't think what that might be – not for Spanish at least, doubt it's tripping up on ordinary accents |
| [19:04:47] | jheizer: | & in a title would be my first guess |
| [19:05:48] | stuartm: | we escape & < > ' " |
| [19:06:56] | dblain: | It could be an IE issue too... I'm not too worried about it. |
| [19:07:12] | dblain: | When I get annoyed enough, I'll track it down. |
| [19:08:08] | stuartm: | muy extraño |
| [19:13:21] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [19:14:38] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Client Quit) | |
| [19:45:08] | biggaz_ (biggaz_!~biggaz@host-78-151-255-200.as13285.net) has joined #mythtv | |
| [19:47:44] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [20:32:22] | joki (joki!~joki@p548628A9.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [20:37:36] | joki (joki!~joki@p5486383E.dip0.t-ipconnect.de) has joined #mythtv | |
| [20:45:09] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Read error: Connection reset by peer) | |
| [20:54:02] | biggaz_ (biggaz_!~biggaz@host-78-151-255-200.as13285.net) has quit (Quit: Leaving) | |
| [21:59:50] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [22:28:25] | SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:32:49] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Read error: Connection reset by peer) | |
| [22:33:09] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has quit (Ping timeout: 248 seconds) | |
| [22:33:11] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [22:33:35] | danielk22 (danielk22!~danielk@exchange.wgen.net) has left #mythtv () | |
| [22:34:02] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginm.net) has joined #mythtv | |
| [22:46:25] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 272 seconds) | |
| [22:59:28] | rsiebert_ (rsiebert_!~quassel@g225048189.adsl.alicedsl.de) has joined #mythtv | |
| [23:02:18] | rsiebert (rsiebert!~quassel@g225051034.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds) | |
| [23:07:53] | len_ (len_!~quassel@67-6-37-92.mpls.qwest.net) has joined #mythtv | |
| [23:13:56] | Gibby (Gibby!~Gibby@184.170.249.223) has quit (Ping timeout: 245 seconds) | |
| [23:41:46] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [23:43:06] | buu: | This is slightly vague but is there anyway for a loaded an active plugin to get notified when a user performs an action in another plugin/area of the app? Specifically I'm interested in 'launches internal player' like from 'watch tv' or 'watch recording'? |
| [23:43:46] | buu: | also are PLUGIN action names in buttons case insensitive? |
| [23:43:59] | buu: | peper03: Oh sorry, I forgot to update you: I applied the patch and the dvd now plays. |
| [23:58:21] | buu: | Also how the heck does " 890 UIUtilE::Assign(this, m_nameEdit, "username", &err);" work if m_nameEdit is a MythUITextEdit*? My C++ is a bit rusty but shouldn't you have to initialize/allocate m_nameEdit to point to something before you can pass it to ::Assign ? |
| [23:59:15] | buu: | I mean it would make sense if m_nameEdit was pointing to an object, we're obviously passing that pointer along, but as far as I can tell, its never assigned anything |
| [23:59:24] | buu: | Or is that some kind of insane C++ macro thing? |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.