Hi, I think your idea makes sense. I will resubmit the test case once I finish working on a patch to implement command script import, as in the previous emails. Thanks, Enrico
Sent from my iPod On Oct 12, 2011, at 10:41 PM, Johnny Chen <[email protected]> wrote: > 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
