[01:45:48] Yaron, this is what I get: Fatal error: Declaration of SRFOutline::getResultText() must be compatible with that of SMWResultPrinter::getResultText() in /home/wikirio/public_html/extensions/SemanticResultFormats/Outline/SRF_Outline.php on line 82 [01:46:18] Hi - what happened, that you now get that error? [01:49:18] I had, as you though i might have, #$srfgFormats = array('calendar'); on my local settings. [01:49:37] removed that [01:49:57] Ah, okay. [01:50:15] Well, I bet the other part of what I wrote applies here too - the mismatched versions. [01:50:59] the version numbers match? [01:52:01] Was that a question? I don't understand. [01:52:15] SWM 1.5.6, then I should download SRF 1.5.3.7? [01:53:05] Well, ideally, you should upgrade both, but yes. [01:53:50] hum, ok... thanks... [02:07:22] Yaron my friend, I downgraded and it worked! Many thanks! :) [02:07:45] Hum, ok. :) [09:05:33] nischayn22: hey [11:40:49] Hi [11:42:37] I have trouble to pass property values to form in forminput call [11:42:58] {{#forminput:form=Report{{#var:PROD}}TemplateForm|default value={{#AddDotTs:{{#var:PROD}}|{{#var:PROD}}}}|size=|button text=Create report For {{#var:PROD}}|query string=Report{{#var:PROD}}TemplateForm[ID]=XXX|popup}} [11:43:19] here is my forminput, question is that am I using query string correctly [11:43:54] I have property called ID in form and template, but I can not see it appearing through forminput [11:48:03] should query string have template or form defined before property? [12:44:38] New patchset: Yury Katkov; "Added 'two listboxes' input. The new input is inherited from Semantic Forms listbox and has additional javascript." [mediawiki/extensions/SemanticFormsInputs] (master) - https://gerrit.wikimedia.org/r/13875 [12:50:34] hi [12:50:54] New patchset: Yury Katkov; "Added 'two listboxes' input. The new input is inherited from Semantic Forms listbox and has additional javascript." [mediawiki/extensions/SemanticFormsInputs] (master) - https://gerrit.wikimedia.org/r/13875 [12:50:57] is it possible to query for pages in a category that do not have a certain property set? [13:04:06] Hijackal: no, that's not possible [13:07:04] JeroenDeDauw: Hey [13:07:14] lost power after a storm hit here [13:07:26] now things are back to normal :) [13:07:40] nischayn22: heh [13:08:01] nischayn22: did you get the file for resolving the merge conflict? [13:08:09] JeroenDeDauw: looking at your merge conflict now [13:09:41] JeroenDeDauw: were you doing a merge of master onto storerewrite or the other way round? [13:10:56] nischayn22: I was doing a rebase of master while being on storerewrite [13:11:34] JeroenDeDauw: I think the best way to resolve the conflict is to keep the storerewrite's copy of the file [13:11:52] since nothing has been changed on the master version [13:16:26] nischayn22: then why is there a conflict? [13:22:13] JeroenDeDauw: no obvious reason I can see [13:26:10] JeroenDeDauw: I think to resolve it we can do "git checkout --theirs/ours filename" [13:26:26] but then there are many more conflicts after it, last time I did it [13:39:09] nischayn22: looks like you're right [13:39:16] More then one conflict [13:39:29] And doing -X ours results in stuff being broken [13:39:59] hm, too bad. [13:40:07] But thanks for the decisive answer :) [13:49:12] JeroenDeDauw: When do we merge storerewrite on master? [13:49:23] I think things are stable now to be merged [13:53:43] nischayn22: let's first get storerewrite rebased on master [13:53:54] Then we can do testing and see if it works properly [13:54:12] And maybe do a quick overall code review [13:54:20] And if no real issues are there, then we'll merge [13:54:25] JeroenDeDauw: Ok, by testing you meant running those few tests we have? :p [13:54:58] nischayn22: no, manually checking to see if the core SMW functionality is still working [13:55:02] Which is a huge pain ofc [13:55:10] But since we have no tests.. [13:55:39] JeroenDeDauw: do you have a nice test wiki? I mean with some properties of all types and some queries as well [13:55:57] nischayn22: I have my local wiki [13:56:06] Yaron: ^ [13:56:10] last 2 lines [13:56:34] Test wiki? [13:56:37] JeroenDeDauw: I have one too, but it doesn't have queries in it, just a few property-values [13:57:06] I guess in a sense all of the SMW-using wikis on Referata are test wikis, for better or worse. :) [13:57:18] I mean, after a new release. [13:58:03] nischayn22: you could do an export of the SMW community wiki I guess [13:58:24] JeroenDeDauw: how is that possible? [13:58:43] nischayn22: I actually found out that current storerewrite is incompatible with some important extensions [13:58:56] So should also check if it works together with Semantic Forms, Semantic Compiund Queries, ect [13:59:05] nischayn22: Special:Export and Special:Import [13:59:31] JeroenDeDauw: They will only be incompatible if they use the database directly [14:00:18] nischayn22: looks like you'll have to rage a bit to Yaron then :D [14:00:30] What's the issue? [14:00:44] Yaron: do other extensions use the smw db directly? [14:00:54] Yaron: I meant your extensions [14:01:11] cause the tables have been changed :p [14:01:13] Semantic Internal Objects and Semantic Drilldown do... those might be the only two. [14:01:51] Are the SMW DB changes finalized? [14:02:05] Yaron: can't they be functioning with the store interface? [14:02:38] Definitely not SD - it uses temporary tables to improve performance. [14:02:40] nischayn22: I think they are doing some stuff the store simply did not foresee [14:02:42] Yaron: the db changes are needed to optimize the way data is stored, so I think yes they are finalized [14:02:53] SIO, possibly, now that the subobject stuff is there. I haven't looked into it. [14:03:06] In any case, it would be good if these extensions could be updated to not access the tables directly [14:03:22] JeroenDeDauw: Yes, that would be good. [14:03:42] Thinking about it, directly accessing the tables from an extension is bad in many ways [14:03:48] Also I don't see how they figure out what table has what, took me like ages to do that :p [14:04:42] I agree, but, at least for the case of SD, I believe that's impossible. [14:04:50] Yaron: what makes you think that? [14:05:30] JeroenDeDauw: Suppose we do a rebase on master from storerewrite, then when you merge storerewrite onto master, we will again have similar merge conflicts [14:07:19] Well, in Special:BrowseData, SD first creates a temporary table (two, actually, but that's a minor detail), to hold all the pages selected by the current set of chosen filters. [14:07:50] ...then it applies queries on to that set to get the data for all the remaining, unselected filters. [14:08:00] nischayn22: should not be the case [14:08:10] Without those temporary tables, the whole thing runs super slow. [14:11:18] * nischayn22 trying rebasing again [14:12:10] Of course, if SMW provided a wrapper around that kind of querying, it would be great to switch to that. [14:21:31] Yaron: What type of wrapper? [14:21:42] New patchset: Nischayn22; "Conflicts: SemanticMediaWiki.hooks.php includes/storage/SMW_SQLStore2.php languages/SMW_Messages.php tests/phpunit/includes/storage/SMW_SQLStore2Test.php" [mediawiki/extensions/SemanticMediaWiki] (storerewrite) - https://gerrit.wikimedia.org/r/14053 [14:22:19] Some set of functions that let you create a temporary subset of all the pages, based on filters; and then let you query on that, instead of on the entire set. [14:22:32] JeroenDeDauw: ^ I think this one does the merge nicely :) [14:23:31] Yaron: you mentioned temporary tables, so SD doesn't directly access the SMW tables? [14:23:46] It does, in order to create the temporary tables. [14:25:11] Hey guys, what's the best way to reset semantics? SSH? I'm having problems with it showing wrong stuff... Had that in the past... [14:27:04] Edgard_Wikirio: reset? I think that's possible with update job (not sure though) [14:27:45] I did something like: [14:27:46] php SMW_setup.php --delete [14:27:46] php SMW_setup.php [14:27:46] php SMW_refreshData.php -v -s 1 -e 500 [14:27:59] In the past. Not sure if it's the best way though [14:30:15] New patchset: Nischayn22; "Conflicts:" [mediawiki/extensions/SemanticMediaWiki] (storerewrite) - https://gerrit.wikimedia.org/r/14053 [14:37:59] JeroenDeDauw: and merge is better than rebasing :) [14:38:14] rebasing shows one conflict at a time only [14:42:34] Edgard_Wikirio: I think its the only way :p [14:43:12] Edgard_Wikirio: also if you do a page edit then the semantics for that page will be renewed [14:59:02] nischayn22: rebase and merge do different things though :) [14:59:53] JeroenDeDauw: rebase applies commits right? [15:02:35] JeroenDeDauw: do we have a problem with the merge? [15:30:07] New review: Jeroen De Dauw; "SQLStore2Queries line 740: undefined $valueIndex" [mediawiki/extensions/SemanticMediaWiki] (storerewrite); V: 0 C: -1; - https://gerrit.wikimedia.org/r/14053 [15:30:45] nischayn22: looks good mostly [15:32:14] nischayn22: can you set up your own testing wiki and see if stuff still works properly? If you think it does, I will merge it in [15:32:25] But if it then ends up breaking stuff for people, I'll revert [15:32:29] JeroenDeDauw: ok, let me check [15:33:08] JeroenDeDauw: about your comment, that's something to do with the previous commit I guess [15:33:16] Yaron: so beware, in not to much time, master will have stuff that makes SIO and SD die [15:33:31] nischayn22: hard to verify [15:33:37] nischayn22: can you just fix it? :p [15:34:26] JeroenDeDauw: ah, my new code is just gone :( [15:34:47] JeroenDeDauw, nischayn22 - is there documentation for the new schema anywhere? [15:35:16] Yaron: somewhat its there, though I need to change it a bit [15:35:25] www.semantic-mediawiki.org/wiki/SQLStore_Update [15:35:50] nischayn22: yeah, the danger of fixing conflicts :) [15:35:57] JeroenDeDauw: oh, I was looking at the master instead [15:35:59] Okay, cool. Can you please send an email to one of the mailing lists once that page is finalized? [15:36:11] Yaron: sure [15:36:29] Cool, thanks. [15:36:36] Yaron: I very much recommend putting stuff in SMW itself to do what you need to do this time - accessing the tables directly is just a bad idea [15:37:03] And that makes the thing accessing it directly incompatible with other stores [15:37:09] JeroenDeDauw: I think the previous commit had some serious problem gone unnoticed :p [15:37:27] I agree that it's a good idea in theory, though I don't know if it would save any work. [15:37:40] Yaron: what about pre-computing the SD stuff in some way btw? Might solve the performance issues [15:37:47] Though it would make compatibility easier. [15:37:55] What do you mean by that? [15:37:59] Yaron: it's not about saving work, it's about having a sane design :p [15:38:03] Fine. [15:38:15] Yaron: for example what SWL does [15:38:31] Oh, I think I understand. [15:38:36] SD could maintain it's own indexing of the data in a way that it can very efficiently do the queries [15:38:45] I don't know - you'd have to pre-compute essentially any combination of filter values. [15:38:51] That's a heck of a lot of caching. [15:38:55] And in a way that it does not need to interact with SMWs tables directly [15:39:06] ....and a lot would need to be recalculated on every page save. [15:39:16] That doesn't seem feasible to me. [15:39:38] Yaron: it would indeed not be trivial to get it right [15:39:42] But it can be done [15:39:59] And it'd perform better and would work with whatever SMW store is in use [15:40:45] Well, that's the one strong argument, I think - I really want SD to be able to work in the future with RDF triplestores. [15:40:59] nischayn22: could be... I did definitly not see it earlier [15:41:09] Right now, I don't think it can, because I don't think you can create temporary tables in triplestores. [15:45:01] JeroenDeDauw: How do we fix that issue? make a new commit? [15:45:29] or can I amend the previous change? [15:45:38] even though its been merged [15:45:39] nischayn22: you cannot amend what's been merged in already [15:45:46] nischayn22: you could amend the merge commit [15:45:56] Ok, doing that [15:45:57] nischayn22: you can also just add a new change [15:46:14] nischayn22: but you can only do the later if the issue was already there before the merge commit [15:46:39] JeroenDeDauw: the merge has nothing to do with this [15:47:06] sounds like making a new commit is better [15:47:16] nischayn22: in that case, yeah [15:47:29] nischayn22: then I'll merge in the merge :p [15:47:43] Change merged: Jeroen De Dauw; [mediawiki/extensions/SemanticMediaWiki] (storerewrite) - https://gerrit.wikimedia.org/r/14053 [15:54:55] New patchset: Nischayn22; "Fix error in Queries" [mediawiki/extensions/SemanticMediaWiki] (storerewrite) - https://gerrit.wikimedia.org/r/14065 [15:55:04] JeroenDeDauw: ^ [15:55:20] My local wiki didn't show any error after this fix :) [15:55:27] * nischayn22 time for dinner [16:12:07] nischayn22: did it before? :p [16:12:44] JeroenDeDauw: I didn't check I guess [16:12:52] manually checking is very tiring [16:13:50] nischayn22: write tests then :) [16:14:04] We almost have as many tests as actual code in Wikibase o_O [16:14:45] Actually probably rather easy to have some very high level tests [16:15:08] That for instance run a query such as [16:15:08] [[Modification date::+]]|?Modification date [16:15:18] And do not really check much [16:15:29] That'll still catch actual php errors [16:15:43] JeroenDeDauw: I am not familiar with much of the queries code yet [16:15:57] and this will need all the parsing and stuff [16:16:05] nischayn22: you can steal this from the ask api [16:16:12] It's pretty trivial actually [16:16:18] You just need to know which methods to use [16:16:28] The QueryProcessor takes care of the stuff for you [16:16:37] hmm, will have a look [16:16:47] However, I only write tests when I am stuck [16:16:54] But this "class" (or random collection of stuff) is a good example of how not to design stuff [16:17:30] nischayn22: I will have a go at writing a few tests such as I suggested now soonish [16:17:36] Will save myself a lot of time as well [16:20:55] Change merged: Jeroen De Dauw; [mediawiki/extensions/SemanticMediaWiki] (storerewrite) - https://gerrit.wikimedia.org/r/14065 [16:27:16] JeroenDeDauw: I pinged Markus, he seems busy [16:33:56] JeroenDeDauw: I see this bug http://pastebin.com/KJyzcL81 [16:34:07] This is not something I have touched [16:36:06] ah its a known bug [17:05:38] JeroenDeDauw: Aha, the queries are working :) [18:12:37] JeroenDeDauw: Talked to Markus, he recommends a migration script and renaming to Store3 with solid reasoning [18:13:08] nischayn22: known bug? Looks like you need to update Validator [18:13:17] JeroenDeDauw: I did :) [18:13:19] nischayn22: having a migration script would be great yes [18:13:27] nischayn22: and the error went away I guess? [18:13:35] yep it did [18:14:06] JeroenDeDauw: migration script would allow users to keep site live and still do the switching [18:14:33] nischayn22: go for it [18:14:35] I am overwhelmed by the SQL I will have to write thought [18:14:38] *though [18:14:46] Although I personally don't think it's that high priority [18:15:46] JeroenDeDauw: Lets keep it for the end then :D [18:16:13] Most people won't care much if they have to do the usual update process [18:16:23] In the past we never had such migration scripts [18:16:34] and regarding merging with master he suggests keeping Store2 and 3 parallel [18:17:26] For now we can have both sure [18:17:33] But I'd not want to release with both [18:18:00] JeroenDeDauw: Actually we have to release with both if we want a migration script [18:18:28] Meh [18:18:38] *kill all of the old codes* [18:18:45] so the users can continue using Store2 until the cron job is done, and then switch to Store3 later [18:19:14] nischayn22: a maintenance script suffices, no need for cron [18:19:37] nischayn22: like I said, we did not have this in the past [18:19:43] JeroenDeDauw: I don't get the difference between the two [18:20:45] nischayn22: cron is a daemon that makes stuff run periodically [18:20:56] nischayn22: a maintenance script is something you invoke and then just runs [18:21:03] cron can invoke maintenance scripts [18:21:09] JeroenDeDauw: Oh, then I misuse the word [18:21:16] We don't need a cron job [18:21:20] Yeah [18:22:58] Three reasons to ditch the old store: [18:22:58] * it makes it very clear that the new one works (if you still have the old store it the code might be using it without you knowing about it) [18:22:58] * you get rid of the old code and don't have a pile of duplication [18:22:58] * if you keep supporting store v2 and have a step people have to manually make to go to v3, lots of people will not bother and stay with v2 [19:44:34] hi [19:44:52] is it possible to transclude kategories and special pages?