[01:09:26] tgr: Hi [01:11:10] tgr: I have completed my application on the outreachy website. Kindly check it out, I am alsocreating the phabricator one Asap [01:12:57] As far as the instructions you provided yesterday are concerned, I tried it out but I get a message in the logs and that is: Debug connection closed too soon [01:13:18] I think I have set it up correctly [01:14:31] hi smartyrad [01:15:33] please copy the application (except for the eligibility info) to Phabricator, the outreachy site doesn't have the facilities to discuss an application there [01:16:01] (plus my eyes start to hurt if I have to look at it for more than two minutes :) [01:16:42] IIRC debug connection closed to soon usually means that debugging works but there was nothing to stop for [01:16:53] ie no breakpoint was hit in the execution [01:18:59] tgr: Yes, I understand. It will be done within the next 2 hrs :) [01:19:57] tgr: As far as the breakpoint is concerned , I remember giving a breakpoint within the captcha.php which surely was loaded during the loading of the create account page [01:22:05] hm [01:22:29] you can set Break on the first line... in the Run menu if you want to test that things work [01:22:51] if that works, breakpoints should too [01:23:12] I was also wondering as to whether it has got something to do with the fact that my /var/www equivalent folder is /srv/http as I'm using Arch currently [01:23:45] if you are using vagrant, it ignores all that [01:24:02] the guest machine is what matters and that's a debian [01:24:55] tgr: Oh I see, I'll just try it out once again. Now that you mentioned that, I am pretty sure that I must've missed something [01:25:34] (you are right though - "Debug connection closed too soon" can mean that the path mapping is wrong) [01:32:05] tgr: I checked my mappings again. Everything looks fine to me and makes sense as well [01:33:17] I tried your suggestion of break on first line. Seems to be working as the debugger has started in my IDE but as I am breaking on the first line, I guess that's why I am not getting the server unavailable error [01:34:09] yeah, the browser will just hang since your IDE is pausing execution [01:34:37] you can step through the code line-by-line with the small icons on the top of the debug window [01:34:52] but it's not fun to do so from the first line [01:35:15] you can try enabling the debug log, that will probably give you enough information to figure out what's wrong [01:35:26] we really should enable that by default [01:38:37] give me half an hour and I'll do that [01:40:14] tgr: It works now! [01:41:02] Don't know why it wasn't before though as I haven't modified a thing [01:42:06] But it's pretty cool though. I'll run the Simpler captcha code and try to check whether the variables are being set or not and if not then I'll step into the code and debug it :) [01:42:13] Thanks a ton! [01:45:14] great [01:46:13] in case you are not familiar with it, apart from the icons to step through the code in various ways, there is one to evaluate arbitrary code [01:46:18] that can be very useful [02:06:14] tgr: I can confirm that the setsession and the exists method is working. All that is left to go through the code step by step and seeing where it's goign wrong [02:40:34] tgr: I have tried to understand as to what's happening [02:40:58] The issue lies with the logic used [02:41:34] in the hook's function [02:42:03] i.e. The one that we have defined that is called by the hook [02:46:22] tgr: But I'm not sure what the issue may be i.e. before, before the captcha loaded, we used to have a callback function that used to call https://gerrit.wikimedia.org/r/#/c/383299/7/SimplerCaptcha/SimplerCaptcha.class.php@50 . Now we are using the BeforeInitialize hook to call the same function which now looks like https://pastebin.com/7guyRrW1 [02:47:52] As I stepped through the code in the debugger, I realised that the IF statement does pass like it should but for some reason SimpleCaptcha() is not displayed even though the data for simplecaptcha etc is fetched [02:49:05] tgr: I get a strong feeling that that's because the captcha is loading before this sort of "check" function is even being called [02:49:17] What do you feel? [02:49:40] well, put another breakpoint in onAuthChangeFormFields and then you can see which comes first [02:50:13] in theory the auth form is part of a special page, so there is no reason for it to be built before the end of setup [02:50:21] but I might be wrong [02:50:36] the MediaWiki setup sequence is rather messy [03:04:34] tgr: I did try it out. I guess, technically the authforms shouldn't be called if the method to be called by our hook is called first right? [03:05:36] And thus the breakpoint shouldn't be reached. But when I added a breakpoint to onAuthChangeFormFields, the code did pause there [03:09:59] there is no relation, all hooks are called [03:10:21] or at least one hook being called does not depend on whether the other is called [03:11:03] tgr: In that case, how do we find which one was called first? [03:11:26] whichever breakpoint your debugger stops on first [03:11:52] I would just step through both functions first and make sure there isn't some simple mistake [03:12:07] like a typo in the session key [03:15:15] tgr: I can confirm that the hook we defined is being called first. So that's not the issue. [03:15:29] tgr: Fixed it! [03:18:00] Don't ask me how cause I feel like such a fool now ( Had missed the session check within the onAuth method!) [03:19:23] tgr: I'll submit the patch rightaway. Sorry for all the trouble but on the brighter side , I did learn a lot about debugging :) [03:21:30] tgr: I forgot to mention that I recently found out that EventLogging does indeed create an entry for the schemas [03:21:52] as in, SQL entry? [03:21:57] But unlike the documentation claims, it doesn't create a new table [03:22:22] tgr: Yes, a table entry. I'll add some screenshots [03:23:05] the documentation is mostly about how it works on the Wikimedia servers [03:23:46] there is a python demon which receives the messages, converts them into SQL and inserts them into the right table [03:23:51] creates them if it has to [03:24:30] apparently that was too much trouble to set up in vagrant so whoever wrote the vagrant role just sent the messages to a logfile instead [03:26:21] tgr: By python demon, do you mean the python debugger mentioned here https://www.mediawiki.org/wiki/Extension:EventLogging/Guide#Debugging? [03:28:38] no, the demon is https://github.com/wikimedia/eventlogging [03:28:52] the debugger is what replaces it in vagrant [03:30:31] That's something I didn't use [03:33:10] well, you can't because it's not in vagrant :) [03:33:40] unfortunately the documentation does not mention that and I forgot about it [03:33:56] when it's set up properly, events end up in the database [03:36:34] Ah I see. I was just checking where the event data is stored. So just for your reference, in my installation the schema details have been stored in the "Logging" table and "Search Index" [03:38:09] I mean , I don't any data is stored as such but I did find the schema names and their descriptions in "Search Index" [03:38:21] *think [11:31:42] tgr: Hi [11:32:22] I have created a patch here https://gerrit.wikimedia.org/r/#/c/383299 . Kindly do check it out when you find time :)