Hi Fabio,
On 2013-07-23 13:39, Fabio Zadrozny wrote:
> On Tue, Jul 23, 2013 at 4:46 AM, Andreas Pakulat
> <andr...@froglogic.com> wrote:
>> thanks for the hint about the pycompletionserver.py. Currently we
>> already have a change or two to PyDev and roll our own but we would
>> rather use the official version.
>>
>> Unfortunately our interpreter is embedded into a commandline tool
>> that
>> does not support being used like a normal python interpreter. So
>> thats
>> why choosing it as an interpreter is not suitable at the moment.
>> What
>> it does is basically load the main script file (i.e. parse it but
>> does
>> not run it immediately), then add a few modules to the python
>> interpreter via C API, import those modules into the global
>> namespace of
>> the main script file and also import several functions into the
>> global
>> namespace. This was done as a convenience for the users but now
>> clearly
>> bites back at us when trying to teach PyDev about these specialties.
>
> Ok, so, it's not really a custom interpreter, just a different
> main... Not sure if that's the best approach (I'd probably go toward
> a
> more common approach of having a different main entry which then
> would
> run the script after configuring the environment, such as most web
> frameworks do or maybe a custom sitecustomize).
>
> Still, if you bundle it as an executable, it shouldn't be all that
> hard to make it look like a real python interpreter (i.e.: one that
> could really be used as an interpreter -- that way you wouldn't need
> to change PyDev at all and everything should just work). This is
> probably the preferred approach.
There are a few more technical details involved that cannot be easily
changed which make it a bit harder to turn the tool into something that
can just run python code as-is.
Howerver I now realized that even that will not be sufficient to fully
support our usecase. Squish tests are naturally running on a particular
application that is to be tested. In various of the Squish editions we
expose the complete internals of the Application (or rather the UI
toolkit used) to the script side. This means a user testing an Eclipse
application has full access to the Java and Eclipse API and can write
code like this in his scripts:
mystr = java_lang_String("Hello World")
findObject("Shell").setText(mystr)
And the binding of these classes, modules and functions is only done
once an application is actually started. In addition the binding is
somewhat dynamic, so if the application loads additional code lazily
then Squish will only know about that once the code is actually loaded.
This is as far as I can see not really supportable, so I now went the
route of simply moving errors being reported by PyDev to warnings so our
users scripts don't have 90% of their lines flagged in red :)
Thanks for the tips though, we be able to use them to make at least
some of the problems go away in the future provided the user has the
application running.
Andreas
--
Andreas Pakulat squ...@froglogic.com
froglogic GmbH - Automated UI and Web Testing
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
pydev-code mailing list
pydev-code@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pydev-code
