User:Jamesboston/nsIProcess/meeting-112308

15:58 < jboston> I'm trying to interpret this: https://bugzilla.mozilla.org/show_bug.cgi?id=442393#c12 15:58 < firebot> jboston: Bug 442393 nor, --, ---, nobody@mozilla.org, NEW, nsIProcess.kill() does not work on Win32 15:58 * humph reads 15:58 < jboston> I don't know what "You should be able to use xpcshell itself" means. 15:59 <@humph> I wonder if he means similar to how the httpd is done 15:59 <@humph> http://mxr.mozilla.org/mozilla-central/source/netwerk/test/httpserver/ is what I mean, used for testing only 16:00 <@humph> I don't know what he means exactly 16:01 <@humph> why not just add a .zip with the bins to the bug? 16:01 <@humph> in a new attachment? 16:01 <@humph> that's what I'd do 16:02 < jboston> I thought that some sort of automated test for inclusion in the tree is required. 16:03 <@humph> it is, yeah 16:03 <@humph> I think you want to get mfinkle to comment. 16:07 <@humph> jboston: ted would be another good resource here 16:08 <@humph> who is also unlikely to surface on a sunday afternoon. 16:27 < Gijs> humph, jboston: perhaps he means that you could run another instance of xpcshell from the unit test? 16:27 <@humph> Gijs: if you can shed light, please do so 16:27 < Gijs> you could make it load a different test files so as to get different error codes or whatever 16:28 < Gijs> well, I am not sure if I understand his comment correctly 16:28 < Gijs> I'm not at all knowledgeable in this area 16:28 < Gijs> all I'm saying is that, if you need a process to run and kill, to see if the API works, instead of writing a separate program specifically for this purpose, you can get away with just running xpcshell itself 16:29 < Gijs> and perhaps that's what he means 16:29 <@humph> Gijs: can you give jboston some tips on doing this, or point at something that's doing it now? 16:29 <@humph> I think you're right 16:29 < Gijs> ehm 16:29 < Gijs> I don't know of any test that does that right now, nor exactly how it would be done 16:30 < Gijs> I believe there is some MDC docs on the functionality xpcshell provides itself (load etc.) - which may include documentation for exiting with a specific return code 16:31 < Gijs> actually, I was confused - I was thinking of the spidermonkey executable ( |js| - the plain JavaScript shell) 16:32 < Gijs> for xpcshell, presumably you should be able to use the "normal" Mozilla Platform interfaces to pick an exit code 16:32 * humph didn't know you could start another xpcshell from inside xpcshell 16:32 < Gijs> well 16:32 < Gijs> I was under the impression we're dealing with a patch for nsIProcess.run/kill 16:32 < Gijs> you could just use that to run xpcshell, right? 16:32 < Gijs> it's just another executable... 16:32 < Gijs> I'm not saying it's an xpcshell feature to clone itself or anything... 16:33 * humph strokes his whiskers 16:33 <@humph> that's very interesting 16:33 <@humph> very interesting indeed 16:34 * Gijs tries to find an interface that lets you specify an exit code 16:38 * Gijs fails :( 16:38 < Gijs> my build env sucks at the moment, however 16:41 < Gijs> hmm 16:41 < Gijs> what's an easy way to check rv values? 16:41 < Gijs> from an exiting app, I mean? 16:42 < Gijs> (on Linux) 16:42 <@humph> echo $? 16:44 < Gijs> excellent 16:44 < Gijs> so, from within xpcshell, just call quit(n); 16:44 <@humph> hot 16:44 < Gijs> (I suspected that'd work, but wanted to be sure before suggesting it) 16:44 < Gijs> jboston: so presumably, on linux for instance, you'd want to run something like: run-mozilla.sh xpcshell foo.js 16:45 < Gijs> for various foo.js 16:45 < Gijs> each of which does something different 16:45 < Gijs> not sure how you should crash xpcshell explicitly 16:45 <@humph> timeless will know 16:45 < jboston> Gijs: Thank-you. 16:45 < Gijs> yeah, was just about to suggest that 16:45 < Gijs> jboston: the most sucky thing is going to be figuring all the paths out, though! 16:46 * Gijs doesn't know enough about xpcshell unit tests to be able to help with that 16:46 <@humph> shouldn't be that bad. ted will know 16:46 < Gijs> anyway, this should get you into the realm of the last 20% taking up 80% of the time ;) 16:46 <@humph> :) 16:46 < Gijs> humph: meh, xpcshell (and mozilla in general) are picky about environment variables, working dirs and so on 16:47 < Gijs> that's why you're calling that run-mozilla.sh script 16:47 <@humph> yes 16:47 < Gijs> so yeah, it'd scare me :) 16:47 * Gijs goes back to refactoring his app (much more boring, but oh well) 17:03 < mfinkle> jboston: brief pong 17:03 < mfinkle> I meant, xpcshell is already a binary 17:03 < mfinkle> launch it with a JS script 17:03 < mfinkle> should work, right? 17:04 < mfinkle> why would the binaries need to be special? 17:04 < jboston> mfinkle: Ok. I'll try that approach. Thank-you. 17:04 <@humph> mfinkle: ideas about paths for him? 17:04 <@humph> Gijs thinks that will be pain 17:08 < mfinkle> humph, jboston: I have no idea about path issues 17:08 < mfinkle> I'd just try it and see what happens 17:09 < mfinkle> bbl 17:09 < jboston> mfinkle: Ok. I'll experiment with that. 17:10 < ted> also, FWIW, $(RUN_TEST_PROGRAM) == run-mozilla.sh 17:10 < ted> where it matters 17:11 < ted> also, you can very easily build custom binaries 17:11 < ted> just make TestProgram.cpp, and set SIMPLE_PROGRAMS = TestProgram 17:11 < ted> in the makefile 17:12 < ted> then you'll wind up with TestProgram.exe in $(DIST)/bin 17:14 < jboston> ted: Thanks. That was what I was looking for. I get stuck on makefiles.