[lldb-dev] command script import

[Jim Ingham]

That looks good, check it in.  If you have the time to centralize the code that locks what needs locking for Python, that would be great.  This sounds like the sort of thing that might not stay the same over time, so it would be good to have it in one place.

Jim

On Oct 15, 2011, at 3:46 AM, Enrico Granata wrote:

> Hi all,
> 
>> Sorry, a few more quibbles.  
>> 
>> Why not add FileSpec::GetFilenameStrippingExtension or something like that as well, since that's what you really use?  That seems like another useful function.  Don't take out the extension one, that also seems good.
> 
> I added that in the attached patch file.
> 
>> 
>> What a pain that you can't import a Python module w/o adding its containing directory to the Python Path!  There must be some reason why, but sigh...
>> 
> 
> I guess Python is trying to be smart in handling dependencies (that way, if you import foo, and foo needs to import bar, as long as bar is in the path you need not worry about its location on disk). Unfortunately, it looks like there is no trivial way to override that.
> 
>> Why do you have to do this bit:
>> 
>> +    FILE *tmp_fh = (python_interpreter->m_dbg_stdout ? python_interpreter->m_dbg_stdout : stdout);
>> +    
>> +    {
>> +        Locker py_lock(python_interpreter, tmp_fh);
>> 
>> That seems non-obvious and at least merits a comment.
>> 
> 
> This is part of the original implementation of the interaction between LLDB and Python. Basically, Python is single-threaded and LLDB tries to acquire the lock before sending commands. I am not sure about the reason why a file handle to which to write some text is required (informative for the user? trying to enforce a wait that the optimizer will not strip?), but this behavior is consistently replicated throughout ScriptInterpreterPython, so I guess the original coder of that class had her motives.
> A good point would be to move the code that calculates tmp_fh into the Locker class itself. IMHO that would be best served by writing a separate patch because there are so many methods doing exactly that code snippet (I can deal with that once we're done working on this patch if you want).
> 
>> Finally since there seem to be several reasons why LoadScriptingModule could fail in this function, it would be better if it took an Error & parameter and filled that out appropriately.
>> 
> 
> There it is.
> I have also taken the time to check against double import. If we try to double import a same module, Python will report no error, and yet the second import silently does nothing. Now I do check for that condition, and the new command *does* report an error on double import (this would not be harmful in itself, but because we would end up calling __lldb_module_init twice, there might be unwelcome side effects in doing that).
> 
>> Jim
>> 
>> 
> 
> Thanks,
> - Enrico Granata
> 
> <importcmd.diff>

Jim Ingham
Apple Developer Tools