Hi Enrico, I'm not sure whether the TestImport.py test case belongs under test/python_api at all? Anyway, you should not make the test case skipUnless it's a Darwin platform.
I shall check in the examples patch for the time being, since the test patch and the examples/customization/import-python patch are a little bit redundant? What do you think? Thanks. On Oct 12, 2011, at 1:08 PM, Enrico Granata wrote: > Hello, > >> On Oct 12, 2011, at 8:00 PM, Johnny Chen wrote: >> I checked in the cleanup patch for TestCommanPython.py. >> As for the 'import' command, can you rework the patch to rely on os.sep >> instead of '/' >> as the pathname components separator? >> >> Thanks. > > > <importcmd.diff> > > Attached is an updated patch file which uses os.sep as suggested, and uses > the new examples/customization directory to store the example import command > (plus a README). If you feel any more changes are required before this is > ready for commit, let me know. > >> On Oct 12, 2011, at 8:11 PM, Jim Ingham wrote: >> >> This is a nice convenience, I was a little worried at first because I want >> to try to avoid introducing top-level name commands when not necessary... I >> want to keep that namespace as clean as possible so people can use it for >> shortcuts. >> >> On thinking a bit, it seems more logical to me if the same functionality was >> done through "command script import"; that could do whatever the current >> script language does to import a module into the scripting language. >> >> It is also pretty consistent with having "command script add/delete/etc..." >> >> If you follow this through further, if we have control of it we could also >> make some convention like if you do: >> >> def __lldb_init_for_interpreter (lldb_interpreter): >> >> we would call this and pass in the LLDB interpreter that was doing the >> import. Then you could put your package's "command script add" commands in >> there. That way you could make up modules that you import and they would >> add all their commands to the LLDB interpreter they were being imported >> into... >> > > My personal preference would be to pass the SBDebugger instead. From the > SBDebugger one can go to the associated SBCommandInterpreter, but doing the > reverse is not possible as far as I can tell. Is there anything sensible that > one could do with the Debugger in this scenario other than just grab the > SBCommandInterpreter and run a few "command script add" commands? While I > cannot think about any obvious example, having access to the list of targets > seems valuable.. > >> We could also add commands to set the PYTHONPATH, etc, like: >> >> command script import --path-component ~/.lldb_python my_script... > > Would this command read like "import a file named my_script.py from a folder > name ~/.lldb_python?" I was thinking about something like > command script import ~/myfile.py which would automatically check whether ~ > is in sys.path and if not append it, and then import myfile > Most probably, it makes sense to delegate this to the ScriptInterpreterPython > for actual implementation, and if LLDB script language is set to anything > different, just reject the command "sorry, do not know how to import for your > current script language" (much like we do for command script add currently) > >> >> This is more work, so I have no problem with adding the example for now. >> But if we do more work on it, I argue more for it's going into "command >> script import..." >> > > I would go for adding the example script for the time being. I can definitely > work on "command script import", but it is going to take a few days, so I > guess having the Pythonic example there won't hurt. Once I get to > implementing the new command, I will also rework the test case to test that > one instead of the script. > I will keep you up to date on progress there. As usual, if you have any > feedback or suggestions, let me know. > >> Jim > > > - Enrico
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
