pydev-code — For registered developers

[Pydev-code] Preparing for PyDev 3.0 release

[Fabio Z. <fa...@gm...>]

Hi all,

The current plan is to release PyDev 3.0 next week (as discussed
previously, this will be the first release that requires Java 7 to run and
breaks compatibility with Eclipse versions older than 3.8).

So, the idea is not to push anything big from now on until the release --
but bugfixes, docs and testing are very welcome :)

Cheers,

Fabio

p.s.: I've just pushed a new nightly build for those that want to test the
release.

Re: [Pydev-code] Auto-update of PyDev interpreter infos

[Fabio Z. <fa...@es...>]

Thanks -- and no problem :)


On Fri, Oct 18, 2013 at 12:41 PM, Jonah Graham <jo...@ki...>wrote:

> OK, Filled as 214 and 215.
>
> (Accidentally filled on wrong tracker first time around, sorry about that)
>
>
> On 18 October 2013 16:31, Fabio Zadrozny <fa...@es...> wrote:
> > Hi Jonah,
> >
> > Thanks for reviewing that. I'll take a look at those.
> >
> > Can you report that in the tracker?  (number 2 is ok and I think I know
> why
> > that happens and how to fix it, as for number 1, you mean that you had
> > opened the interpreter view and the process started while you were
> editing
> > things? -- if that's it, I should probably disable the update while
> you're
> > doing the edition).
> >
> > Cheers,
> >
> > Fabio
> >
> >
> >
> >
> > On Fri, Oct 18, 2013 at 11:37 AM, Jonah Graham <jo...@ki...>
> > wrote:
> >>
> >> Hi Fabio,
> >>
> >> I have just had a first go using your recent dev work on auto-updated
> >> PyDev interpreter infos. On the whole it looks great and it an
> >> excellent update to PyDev.
> >>
> >> However I found a few issues, and I am unsure how to reproduce them.
> >> Perhaps you know about them already so I leave it up to you.
> >>
> >> 1) I seemed to be modifying my PYTHONPATH in the preferences when the
> >> process was kicked off. As a result PyDev lost the changes I had just
> >> made.
> >>
> >> 2) The order of my interpreters changed in the GUIs. (I may be a
> >> little unusual, as I am testing some changes across many interpreters
> >> I currently have 6 different Pythons (2.4-3.2 + pypy latest)
> >>
> >>
> >> Thanks,
> >> Jonah
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> October Webinars: Code for Performance
> >> Free Intel webinars can help you accelerate application performance.
> >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> >> from
> >> the latest Intel processors and coprocessors. See abstracts and
> register >
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> pydev-code mailing list
> >> pyd...@li...
> >> https://lists.sourceforge.net/lists/listinfo/pydev-code
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> > _______________________________________________
> > pydev-code mailing list
> > pyd...@li...
> > https://lists.sourceforge.net/lists/listinfo/pydev-code
> >
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>

Re: [Pydev-code] Auto-update of PyDev interpreter infos

[Jonah G. <jo...@ki...>]

OK, Filled as 214 and 215.

(Accidentally filled on wrong tracker first time around, sorry about that)


On 18 October 2013 16:31, Fabio Zadrozny <fa...@es...> wrote:
> Hi Jonah,
>
> Thanks for reviewing that. I'll take a look at those.
>
> Can you report that in the tracker?  (number 2 is ok and I think I know why
> that happens and how to fix it, as for number 1, you mean that you had
> opened the interpreter view and the process started while you were editing
> things? -- if that's it, I should probably disable the update while you're
> doing the edition).
>
> Cheers,
>
> Fabio
>
>
>
>
> On Fri, Oct 18, 2013 at 11:37 AM, Jonah Graham <jo...@ki...>
> wrote:
>>
>> Hi Fabio,
>>
>> I have just had a first go using your recent dev work on auto-updated
>> PyDev interpreter infos. On the whole it looks great and it an
>> excellent update to PyDev.
>>
>> However I found a few issues, and I am unsure how to reproduce them.
>> Perhaps you know about them already so I leave it up to you.
>>
>> 1) I seemed to be modifying my PYTHONPATH in the preferences when the
>> process was kicked off. As a result PyDev lost the changes I had just
>> made.
>>
>> 2) The order of my interpreters changed in the GUIs. (I may be a
>> little unusual, as I am testing some changes across many interpreters
>> I currently have 6 different Pythons (2.4-3.2 + pypy latest)
>>
>>
>> Thanks,
>> Jonah
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> pydev-code mailing list
>> pyd...@li...
>> https://lists.sourceforge.net/lists/listinfo/pydev-code
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>

Re: [Pydev-code] Auto-update of PyDev interpreter infos

[Fabio Z. <fa...@es...>]

Hi Jonah,

Thanks for reviewing that. I'll take a look at those.

Can you report that in the tracker?  (number 2 is ok and I think I know why
that happens and how to fix it, as for number 1, you mean that you had
opened the interpreter view and the process started while you were editing
things? -- if that's it, I should probably disable the update while you're
doing the edition).

Cheers,

Fabio




On Fri, Oct 18, 2013 at 11:37 AM, Jonah Graham <jo...@ki...>wrote:

> Hi Fabio,
>
> I have just had a first go using your recent dev work on auto-updated
> PyDev interpreter infos. On the whole it looks great and it an
> excellent update to PyDev.
>
> However I found a few issues, and I am unsure how to reproduce them.
> Perhaps you know about them already so I leave it up to you.
>
> 1) I seemed to be modifying my PYTHONPATH in the preferences when the
> process was kicked off. As a result PyDev lost the changes I had just
> made.
>
> 2) The order of my interpreters changed in the GUIs. (I may be a
> little unusual, as I am testing some changes across many interpreters
> I currently have 6 different Pythons (2.4-3.2 + pypy latest)
>
>
> Thanks,
> Jonah
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>

[Pydev-code] Auto-update of PyDev interpreter infos

[Jonah G. <jo...@ki...>]

Hi Fabio,

I have just had a first go using your recent dev work on auto-updated
PyDev interpreter infos. On the whole it looks great and it an
excellent update to PyDev.

However I found a few issues, and I am unsure how to reproduce them.
Perhaps you know about them already so I leave it up to you.

1) I seemed to be modifying my PYTHONPATH in the preferences when the
process was kicked off. As a result PyDev lost the changes I had just
made.

2) The order of my interpreters changed in the GUIs. (I may be a
little unusual, as I am testing some changes across many interpreters
I currently have 6 different Pythons (2.4-3.2 + pypy latest)


Thanks,
Jonah

Re: [Pydev-code] Jython auto-interpreter

[Fabio Z. <fa...@gm...>]

I think that your approach of using the env variables seems fine if there's
no other standard place which would have the libraries...

Now, if there are other standards (i.e.: for instance if the jar is usually
on /usr/share/java and the /Lib is in /usr/jython/Lib), maybe we could
accommodate that (still, I'm not really knowledgeable what would be
standard in this cases, so, if you feel there are no standards besides the
JYTHON_HOME, just looking for it seems to be Ok for me).

Cheers,

Fabio


On Wed, Oct 16, 2013 at 11:54 AM, Andrew Ferrazzutti <afe...@re...>wrote:

> Hi Fabio,
>
> I have another concern regarding Jython. I know that at the moment PyDev
> only supports Jython jars as interpreters, but the auto-interpreters don't
> really take this into account properly. Once the auto-configurer (and also
> the manual configurer) finds a jython.jar file, it tries to add the Lib and
> Lib/site-packages folders as system libraries by appending those pathnames
> to the directory of the jar it just found. In most cases, though, the jar
> that is found exists outside of a dedicated Jython folder, and library
> directories (correctly) don't exist there.
>
> For example, other than paths specified by environment variables like
> JYTHON_HOME, the paths that are searched for jython.jar are
> /usr/share/java, /usr/bin, and /usr/local/bin (see
> JythonInterpreterProviderFactory.java). These directories all contain a
> jython.jar, but of course have no Lib folder.
>
> I recently made a change to the auto-interpreter for it to reject
> jython.jar directories that lack a Lib folder, but the fact that paths
> which will definitely not have Lib folders are searched seems somewhat
> pointless. Since the ideal case is to use a jython.jar from a directory
> containing all appropriate library folders, I think it would be more
> appropriate to only search paths specified by environment variables, and
> for PyDev to better notify the user of which env variables the
> auto-interpreter uses as Jython search paths.
>
> Let me know what you think.
>
> Andrew
>

[Pydev-code] Jython auto-interpreter

[Andrew F. <afe...@re...>]

Hi Fabio,

I have another concern regarding Jython. I know that at the moment PyDev only supports Jython jars as interpreters, but the auto-interpreters don't really take this into account properly. Once the auto-configurer (and also the manual configurer) finds a jython.jar file, it tries to add the Lib and Lib/site-packages folders as system libraries by appending those pathnames to the directory of the jar it just found. In most cases, though, the jar that is found exists outside of a dedicated Jython folder, and library directories (correctly) don't exist there.

For example, other than paths specified by environment variables like JYTHON_HOME, the paths that are searched for jython.jar are /usr/share/java, /usr/bin, and /usr/local/bin (see JythonInterpreterProviderFactory.java). These directories all contain a jython.jar, but of course have no Lib folder.

I recently made a change to the auto-interpreter for it to reject jython.jar directories that lack a Lib folder, but the fact that paths which will definitely not have Lib folders are searched seems somewhat pointless. Since the ideal case is to use a jython.jar from a directory containing all appropriate library folders, I think it would be more appropriate to only search paths specified by environment variables, and for PyDev to better notify the user of which env variables the auto-interpreter uses as Jython search paths.

Let me know what you think.

Andrew

[Pydev-code] Jython and the CLASSPATH

[Andrew F. <afe...@re...>]

Hi Fabio,

I've been doing some testing with PyDev's Jython and its ability to work with with external libraries, and noticed that .jars put into the Java CLASSPATH are ignored. For clarification, I added the path to a custom .jar in my system's CLASSPATH, and when using Jython from my terminal, was able to import the .jar and its classes. In PyDev, though, an error is raised by both the Interactive Console and a script when trying to import the same CLASSPATH .jar.

Since "__classpath__" is listed as one of the default System libs for Jython interpreters in PyDev, I expected this to work without any extra configuration, but maybe I'm missing something. I also tried adding CLASSPATH as an environment variable in the Jython Interpreter preferences, but PyDev said that CLASSPATH is managed by other things and wouldn't allow my change.

Is there something I have to do for PyDev's Jython to see CLASSPATH .jars? Or is this a bug?

Thanks,
Andrew

[Pydev-code] PyDev on Travis CI

[Jonah G. <jo...@ki...>]

Hi all,

I have been experimenting with using Travis CI to build PyDev continuously.

I have been making some progress with this in my free(ish) time:

Now most all tests run (normal and Workbench tests, some setup errors
to resolve, but significant progress). The last build took 22 minutes
on Travis, on my machine it takes about 1/2 that using Maven offline
mode on my machine.
https://travis-ci.org/jonahkichwacoders/Pydev/builds/11482482

This is the JUnit results (if you look at the end of the log file in
the travis build it has a link to the S3 location
https://s3-us-west-2.amazonaws.com/pydevbuilds/artifacts/11482482/11482483/report/junit-noframes.html

This is my current TODO list for Travis:
https://github.com/jonahkichwacoders/Pydev/blob/development/travis.TODO

Fabio, if you have a bit of free time to look at this preliminary work
I would be grateful. Especially as you surely have knowledge and
insight that may save me time going forward. Prior to a Pull Request I
will rework the commits though as there is currently a lot of back and
forth as I try and figure stuff out. Something that would particularly
helpful is any recent runs of the PyDev test suite you have that I can
use as a baseline so that I can focus on the tests which are failing
because of running on Travis as opposed to known errors.

Thanks to Aleksander Kurtakov for putting in the initial tycho setting
files that I have extended. Please do let me know if you have any
pre-Pull Request comments on what I have done so far. Of particular
interest to me is your use case for Tycho with PyDev as I want to
minimise breaking what your intentions were.

Thanks!
Jonah

[Pydev-code] PyDev 2.8.2 released

[Fabio Z. <fa...@gm...>]

Hi All,

PyDev 2.8.2 has been released

Details on PyDev: http://pydev.org
Details on its development: http://pydev.blogspot.com
Become a supporter and help to keep it going forward:
https://sw-brainwy.rhcloud.com/

Release Highlights:
-------------------------------

* The type inference engine now accepts comments in the format **#@type a:
str** to get the type.

* Interpreter configuration properly deals with characters with ampersand.

* Interactive console can now work with PySide and wxPython to create
widgets without blocking.

* Debugger now working properly with Jython 2.1.

* Markups in sphinx or epydoc format can now have a different color in
docstrings.

* Code-completion for the sphinx markup is provided in docstrings.

* Fixed issue when resolving module names (which could make PyDev find
modules as Lib.math instead of math if the interpreter folder was added to
the PYTHONPATH and not only the Lib folder).

* When configuring project source folders (PYTHONPATH), it's possible to
make use of the PROJECT_DIR_NAME variable.

* **Patches by Trey Greer**:

* PyLint 1.0 is now properly supported.

* **Patches by Jonah Graham:**

* Fixed issue in interactive console interaction with XML-RPC.

* Interactive console history is saved to persistent location.

* It's possible to filter variables in the variables view menu (can be
activated with Ctrl+F10 focusing the variables view > PyDev,
select/deselect filters).

* Eclipse variables are expanded in the initial interpreter commands for
the interactive console.

* An evaluate button (same as Ctrl+Alt+Enter) is now available in the
toolbar.

* **Patches by by Anselm Kruis:**

* Fixed issues related to having the interpreter or workspace in locations
with non-ascii characters.

* **Patches by Jeremy Carroll:**

* It's now possible to use PEP-8 style imports (default now, can be
unconfigured at window > preferencs > pydev > editor > code style >
imports).

* It's possible to configure the organize imports to remove unused imports
(must be enabled in window > preferencs > pydev > editor > code style >
imports).

* **Patches by Andrew Ferrazzutti:**

* Better heuristics to discover file in workspace related to open files
when debugging.

* Improvements in the PyDev project configuration and wizard.

* It's possible to mark/unmark folders as source folders with a right-click
context menu.

* Auto-Configuration of interpreter streamlined.

* **Patches by Andre Berg:**

* It's possible to have a change action which will keep a variable updated
when file is changed (i.e.: __date__ = '2013-01-01' would be updated when
file is saved to a new date).


What is PyDev?
---------------------------

PyDev is a plugin that enables users to use Eclipse for Python, Jython and
IronPython development -- making Eclipse a first class Python IDE -- It
comes with many goodies such as code completion, syntax highlighting,
syntax analysis, refactor, debug and many others.


Cheers,

--
Fabio Zadrozny
------------------------------------------------------
Software Developer

PyDev - Python Development Environment for Eclipse
http://pydev.org
http://pydev.blogspot.com

Re: [Pydev-code] Interpreter not configred dialog: "Don't Ask Again"

[Fabio Z. <fa...@gm...>]

Hi Andrew,

You're correct, there's no way to undo that... probably having a
preference-page showing that might be a good idea :)

Cheers,

Fabio


On Tue, Sep 3, 2013 at 11:16 AM, Andrew Ferrazzutti <afe...@re...>wrote:

> Hi Fabio,
>
> The dialog that appears when an interpreter is not configured (defined in
> PyDialogHelpers) has a "Don't Ask Again" button. If that button is clicked,
> is there a way to undo it, to re-allow the dialog to appear if an
> interpreter isn't found? I couldn't find anything in Preferences or
> Customize Perspective.
>
> I ask because having the dialog _never_ show up again may be annoying for
> a user in the long run, especially if the "Don't Ask Again" button is
> clicked by accident, or without understanding that nothing can turn the
> dialogs back on.
>
> So far the only way I've been able to get the dialogs to appear after
> having clicked "Don't Ask Again" is by switching to another workspace
> entirely.
>
> Thanks,
> Andrew
>

[Pydev-code] Interpreter not configred dialog: "Don't Ask Again"

[Andrew F. <afe...@re...>]

Hi Fabio,

The dialog that appears when an interpreter is not configured (defined in PyDialogHelpers) has a "Don't Ask Again" button. If that button is clicked, is there a way to undo it, to re-allow the dialog to appear if an interpreter isn't found? I couldn't find anything in Preferences or Customize Perspective.

I ask because having the dialog _never_ show up again may be annoying for a user in the long run, especially if the "Don't Ask Again" button is clicked by accident, or without understanding that nothing can turn the dialogs back on. 

So far the only way I've been able to get the dialogs to appear after having clicked "Don't Ask Again" is by switching to another workspace entirely.

Thanks,
Andrew

Re: [Pydev-code] EPL headers for IFS sources

[Fabio Z. <fa...@gm...>]

I think that in this case it may make sense to put IFS in the first line.


On Thu, Aug 29, 2013 at 4:48 PM, Andrew Ferrazzutti <afe...@re...>wrote:

> Hi Fabio,
>
> Thanks for the quick reply. As we're on topic, I have one more question
> about licenses. The standard EPL header has only one name on its first line
> (for example, "Copyright (C) 2007  Fabio Zadrozny"), but most (and likely
> all) of the IFS files have more than one author listed in their copyright
> headers. Also, the Git history of these files doesn't provide any
> information on any single original author.
>
> So when I add EPL headers to these files, who should I attribute the
> copyright on the first line to? I've narrowed it down to these choices:
> 1) the names of every original author
> 2) just the file's first listed author
> 3) "IFS Institute for Software"
>
> In any case, I'll be including all of the authors in the list of
> contributors.
>
> Andrew
>
> ----- Original Message -----
> From: "Fabio Zadrozny" <fa...@gm...>
> To: "Andrew Ferrazzutti" <afe...@re...>
> Cc: "pydev-code" <pyd...@li...>, "Aleksandar
> Kurtakov" <aku...@re...>
> Sent: Thursday, August 29, 2013 2:54:44 PM
> Subject: Re: EPL headers for IFS sources
>
> Hi Andrew,
>
> Adding the EPL header to those licenses is OK (just the copyright should
> still be kept for IFS).
>
> Best Regards,
>
> Fabio
>

Re: [Pydev-code] EPL headers for IFS sources

[Andrew F. <afe...@re...>]

Hi Fabio,

Thanks for the quick reply. As we're on topic, I have one more question about licenses. The standard EPL header has only one name on its first line (for example, "Copyright (C) 2007  Fabio Zadrozny"), but most (and likely all) of the IFS files have more than one author listed in their copyright headers. Also, the Git history of these files doesn't provide any information on any single original author.

So when I add EPL headers to these files, who should I attribute the copyright on the first line to? I've narrowed it down to these choices:
1) the names of every original author
2) just the file's first listed author
3) "IFS Institute for Software"

In any case, I'll be including all of the authors in the list of contributors.

Andrew

----- Original Message -----
From: "Fabio Zadrozny" <fa...@gm...>
To: "Andrew Ferrazzutti" <afe...@re...>
Cc: "pydev-code" <pyd...@li...>, "Aleksandar Kurtakov" <aku...@re...>
Sent: Thursday, August 29, 2013 2:54:44 PM
Subject: Re: EPL headers for IFS sources

Hi Andrew,

Adding the EPL header to those licenses is OK (just the copyright should
still be kept for IFS).

Best Regards,

Fabio

Re: [Pydev-code] EPL headers for IFS sources

[Fabio Z. <fa...@gm...>]

Hi Andrew,

Adding the EPL header to those licenses is OK (just the copyright should
still be kept for IFS).

Best Regards,

Fabio


On Thu, Aug 29, 2013 at 3:34 PM, Andrew Ferrazzutti <afe...@re...>wrote:

> Hi Fabio,
>
> I'm in the process of adding missing Eclipse Public License headers to
> PyDev source files (excluding Jython). I was told that the refactoring code
> you acquired from the Institute for Software is under the Eclipse Public
> License. If this is indeed the case, is it acceptable for me to add a
> standard EPL header to those files (the same kind of header I've been
> adding to other source files), on top of the copyright information they
> already have? Or is there some other kind of licensing info that has to be
> put in these files?
>
> Thanks,
> Andrew
>

[Pydev-code] EPL headers for IFS sources

[Andrew F. <afe...@re...>]

Hi Fabio,

I'm in the process of adding missing Eclipse Public License headers to PyDev source files (excluding Jython). I was told that the refactoring code you acquired from the Institute for Software is under the Eclipse Public License. If this is indeed the case, is it acceptable for me to add a standard EPL header to those files (the same kind of header I've been adding to other source files), on top of the copyright information they already have? Or is there some other kind of licensing info that has to be put in these files?

Thanks,
Andrew

Re: [Pydev-code] Python versions to support (was: Re: Java 7 and Apache Commons)

[Derrick H. <ds...@dm...>]

On Sat, Aug 24, 2013 at 11:33:29AM +0100, Jonah Graham wrote:
[...]
|    [2] xmlrpc was not part of 2.1, so pydev uses the local version, but this
|    is the error we get:
[...]
|    � File
|    "/scratch/pydev/Pydev/plugins/org.python.pydev/pysrc/_pydev_xmlrpclib.py",
|    line 159, in ?
|    � � _bool_is_builtin = False.__class__.__name__ == "bool"
|    AttributeError: 'int' object has no attribute '__class__'

For reference, types and classes were unified in Python 2.2.  (int was
not a class in 2.1)  2.2 was released in 2001.

http://www.python.org/download/releases/2.2.3/descrintro/

http://www.python.org/doc/versions/

-Derrick

Re: [Pydev-code] Python versions to support (was: Re: Java 7 and Apache Commons)

[Jonah G. <jo...@ki...>]

On 24 August 2013 12:57, Fabio Zadrozny <fa...@es...> wrote:
> Now, related to the features you're adding, I think it's Ok to require IPython, but if it's not available on the system, the shell should still work for users that don't want to install IPython (i.e.: the current Qt/wx integration should probably be kept working without needing IPython).

For the new GUI features I am adding I am not requiring IPython. The
GUI loop integration has no dependencies, other than being Python 2.6+
(and whichever GUI toolkit you want to use). The code to enable this
is derived from IPython, but does not import IPython.

Obviously my other work that improves on IPython integration does
require IPython. One of the places these cross paths is that the %gui
magic in IPython will actually use the new code that I am writing now.

Other than trying to test as many options as I can, I am nearly
complete this so the pull request is imminent. I don't have access to
Mac OSX, so hopefully someone else can give that a try for me once I
put in the pull request.

Thanks,
Jonah

Re: [Pydev-code] Python versions to support (was: Re: Java 7 and Apache Commons)

[Fabio Z. <fa...@es...>]

On Sat, Aug 24, 2013 at 7:33 AM, Jonah Graham <jo...@ki...>wrote:

> Hi again!
>

Hi Jonah :)


> I now have a follow-up, but this time on versions of Python to support.
>
> In the work I am doing[1] updating the pydevconsole I was testing my
> changes against older versions of Python. IPython currently requires Python
> 2.6+ or 3.2+ and this will be the minimum versions required for the new
> features. During testing I tried using Python 2.1.3 (built from source on
> Ubuntu 12.04 64-bit) and the console does not work[2].
>

> My question therefore is: What is the minimum required versions of Python
> (et al) that PyDev should support going forward?
>
> I suppose this may be a question for PyDev 3+ and that PyDev should
> continue to support the oldest possible version.
>

I think that the core PyDev (i.e.: code analysis, code-completion, editor,
etc) should support at least Jython 2.1+ and Python 2.4+.

Now, if there are advanced features which require more current versions of
Python to work, I don't think this is a big issue.

So, related to the shell, I think the basic features should work with those
same versions, but if there are advanced features that require 2.6+ (such
as an advanced IPython integration) I think this is Ok.

Now, related to the features you're adding, I think it's Ok to require
IPython, but if it's not available on the system, the shell should still
work for users that don't want to install IPython (i.e.: the current Qt/wx
integration should probably be kept working without needing IPython).

Cheers,

Fabio

p.s.: Related to the PyDev 3 feature-set, I think the main thing at this
point will be the way that PyDev deals with the configured interpreter
(which is the most voted feature at this point:
https://sw-brainwy.rhcloud.com/tracker/PyDev/80) and probably virtualenv
support, but PyDev development is very incremental, so, even things still
added on PyDev 2.x (such as the recent code-completion based on types)
could probably be enough for raising the version.



> Thanks
> Jonah
>
> [1] I am doing further work on GUI event loops and deeper integration of
> IPython
> [2] xmlrpc was not part of 2.1, so pydev uses the local version, but this
> is the error we get:
> Error stream: Traceback (most recent call last):
>   File
> "/scratch/pydev/Pydev/plugins/org.python.pydev/pysrc/pydevconsole.py", line
> 21, in ?
>     from pydev_imports import SimpleXMLRPCServer, Queue
>   File
> "/scratch/pydev/Pydev/plugins/org.python.pydev/pysrc/pydev_imports.py",
> line 7, in ?
>     import _pydev_xmlrpclib as xmlrpclib
>   File
> "/scratch/pydev/Pydev/plugins/org.python.pydev/pysrc/_pydev_xmlrpclib.py",
> line 159, in ?
>     _bool_is_builtin = False.__class__.__name__ == "bool"
> AttributeError: 'int' object has no attribute '__class__'
>
>
> On 23 August 2013 09:46, Jonah Graham <jo...@ki...> wrote:
>
>> Hi Fabio,
>>
>> I like your conclusion, especially regarding PyDev 3 vs 2 for the
>> breakage.
>>
>> As for apache commons code, for now that is fine. If I come up with a
>> specific and strong enough need I will re-raise it. I was aware that you
>> had spent considerable time writing good quality utility code and don't
>> want to get rid of any of that. (Perhaps, when you find that elusive free
>> time ;-), you can improve the apache commons join for everyone.
>>
>> (Out of curiosity, will there be a major feature set change to go along
>> with the version change?)
>>
>> Thanks, and looking forward to PyDev 3.0!
>> Jonah
>>
>>
>> On 22 August 2013 18:13, Fabio Zadrozny <fa...@es...> wrote:
>>
>>> Hi Jonah,
>>>
>>> Ok, the poll (
>>> http://pydev.blogspot.com.br/2013/08/pydev-poll-about-minimum-javaeclipse.html)
>>> has been around for some time already, and it seems the major issue there
>>> would be support for older versions of Mac OS, where java can't be
>>> upgraded...
>>>
>>> Anyways, I think that given the feedback, going forward to support only
>>> Java 7 and Eclipse 3.7 onwards is what we should look at...
>>>
>>> Still, I think that this breakage should be pretty visible, so, I'd like
>>> to keep PyDev 2.x releases based on the current dependencies and go forward
>>> to breaking the dependency in PyDev 3.
>>>
>>> The idea would be stabilizing and doing one more release on PyDev 2,
>>> creating a branch to keep it going, doing one more bugfix-only release from
>>> that branch and then creating PyDev 3 where we can start targeting Eclipse
>>> 3.7 onwards and Java 7.
>>>
>>> Regarding the apache commons, I took a (rather quick) look at it and I
>>> don't think they replace all that's used in the PyDev StringUtils... and in
>>> some cases (i.e.: StringUtils.join), their implementation seems to be
>>> considerably slower than the current PyDev implementation which was pretty
>>> optimized, so, I'm a little wary about making that replacement...
>>>
>>> As for adding the apache commons, I'd like to know if you have specific
>>> things you'd like to use (if it's just one or 2 utility classes, I'm not
>>> sure it's worth the extra weight -- in that case, as their license allows,
>>> it may be worth just copying those classes).
>>>
>>> Cheers,
>>>
>>> Fabio
>>>
>>> On Wed, Aug 7, 2013 at 9:18 PM, Fabio Zadrozny <fa...@es...>wrote:
>>>
>>>> Hi Jonah,
>>>>
>>>> I'll do the following: I'll create a blog entry to ask people what they
>>>> think about... personally, I think going forward is nice, but I'd like to
>>>> check with the current user base if that's an issue... (at a time I know
>>>> Mac OS users had problems updating to more recent versions of Java, and
>>>> Eclipse 3.2 was the version used by Aptana Studio 2, but I don't think it
>>>> has to be supported anymore).
>>>>
>>>> So, I'll ask users to be able to give you feedback :)
>>>>
>>>> Cheers,
>>>>
>>>> Fabio
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 11:48 AM, Jonah Graham <jo...@ki...>wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I know that PyDev officially supports Eclipse 3.2+[1]/Java 6+ (or
>>>>> 5?)[2], however I would like to use some features of Java 7 (e.g.
>>>>> java.nio stuff). In addition I would love to be able to use various
>>>>> apache commons stuff (e.g. StringUtils[3]).
>>>>>
>>>>> What are the issues/(other?) with supporting older versions of
>>>>> Eclipse/Java/etc?
>>>>>
>>>>> Thoughts/comments?
>>>>> Thanks,
>>>>> Jonah
>>>>>
>>>>> [1] There is a little bit of code with correct try/catch in
>>>>> PydevPlugin for supporting Eclipse 4+ if it is available.
>>>>> [2] On http://pydev.org/download.html it states Jave 6+ (Java 7
>>>>> recommended), but on http://pydev.org/developers.html for developers
>>>>> the request is still Java 5 API?
>>>>> [3] If PyDev did become dependent on apache commons, then I could go
>>>>> and remove the (then) redundant code in PyDev's StringUtils?
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> 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
>>>>> pyd...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/pydev-code
>>>>>
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Introducing Performance Central, a new site from SourceForge and
>>> AppDynamics. Performance Central is your source for news, insights,
>>> analysis and resources for efficient Application Performance Management.
>>> Visit us today!
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>>>
>>> _______________________________________________
>>> pydev-code mailing list
>>> pyd...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pydev-code
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>
>

[Pydev-code] Python versions to support (was: Re: Java 7 and Apache Commons)

[Jonah G. <jo...@ki...>]

Hi again!

I now have a follow-up, but this time on versions of Python to support.

In the work I am doing[1] updating the pydevconsole I was testing my
changes against older versions of Python. IPython currently requires Python
2.6+ or 3.2+ and this will be the minimum versions required for the new
features. During testing I tried using Python 2.1.3 (built from source on
Ubuntu 12.04 64-bit) and the console does not work[2].

My question therefore is: What is the minimum required versions of Python
(et al) that PyDev should support going forward?

I suppose this may be a question for PyDev 3+ and that PyDev should
continue to support the oldest possible version.

Thanks
Jonah

[1] I am doing further work on GUI event loops and deeper integration of
IPython
[2] xmlrpc was not part of 2.1, so pydev uses the local version, but this
is the error we get:
Error stream: Traceback (most recent call last):
  File
"/scratch/pydev/Pydev/plugins/org.python.pydev/pysrc/pydevconsole.py", line
21, in ?
    from pydev_imports import SimpleXMLRPCServer, Queue
  File
"/scratch/pydev/Pydev/plugins/org.python.pydev/pysrc/pydev_imports.py",
line 7, in ?
    import _pydev_xmlrpclib as xmlrpclib
  File
"/scratch/pydev/Pydev/plugins/org.python.pydev/pysrc/_pydev_xmlrpclib.py",
line 159, in ?
    _bool_is_builtin = False.__class__.__name__ == "bool"
AttributeError: 'int' object has no attribute '__class__'


On 23 August 2013 09:46, Jonah Graham <jo...@ki...> wrote:

> Hi Fabio,
>
> I like your conclusion, especially regarding PyDev 3 vs 2 for the
> breakage.
>
> As for apache commons code, for now that is fine. If I come up with a
> specific and strong enough need I will re-raise it. I was aware that you
> had spent considerable time writing good quality utility code and don't
> want to get rid of any of that. (Perhaps, when you find that elusive free
> time ;-), you can improve the apache commons join for everyone.
>
> (Out of curiosity, will there be a major feature set change to go along
> with the version change?)
>
> Thanks, and looking forward to PyDev 3.0!
> Jonah
>
>
> On 22 August 2013 18:13, Fabio Zadrozny <fa...@es...> wrote:
>
>> Hi Jonah,
>>
>> Ok, the poll (
>> http://pydev.blogspot.com.br/2013/08/pydev-poll-about-minimum-javaeclipse.html)
>> has been around for some time already, and it seems the major issue there
>> would be support for older versions of Mac OS, where java can't be
>> upgraded...
>>
>> Anyways, I think that given the feedback, going forward to support only
>> Java 7 and Eclipse 3.7 onwards is what we should look at...
>>
>> Still, I think that this breakage should be pretty visible, so, I'd like
>> to keep PyDev 2.x releases based on the current dependencies and go forward
>> to breaking the dependency in PyDev 3.
>>
>> The idea would be stabilizing and doing one more release on PyDev 2,
>> creating a branch to keep it going, doing one more bugfix-only release from
>> that branch and then creating PyDev 3 where we can start targeting Eclipse
>> 3.7 onwards and Java 7.
>>
>> Regarding the apache commons, I took a (rather quick) look at it and I
>> don't think they replace all that's used in the PyDev StringUtils... and in
>> some cases (i.e.: StringUtils.join), their implementation seems to be
>> considerably slower than the current PyDev implementation which was pretty
>> optimized, so, I'm a little wary about making that replacement...
>>
>> As for adding the apache commons, I'd like to know if you have specific
>> things you'd like to use (if it's just one or 2 utility classes, I'm not
>> sure it's worth the extra weight -- in that case, as their license allows,
>> it may be worth just copying those classes).
>>
>> Cheers,
>>
>> Fabio
>>
>> On Wed, Aug 7, 2013 at 9:18 PM, Fabio Zadrozny <fa...@es...>wrote:
>>
>>> Hi Jonah,
>>>
>>> I'll do the following: I'll create a blog entry to ask people what they
>>> think about... personally, I think going forward is nice, but I'd like to
>>> check with the current user base if that's an issue... (at a time I know
>>> Mac OS users had problems updating to more recent versions of Java, and
>>> Eclipse 3.2 was the version used by Aptana Studio 2, but I don't think it
>>> has to be supported anymore).
>>>
>>> So, I'll ask users to be able to give you feedback :)
>>>
>>> Cheers,
>>>
>>> Fabio
>>>
>>>
>>>
>>>
>>> On Wed, Aug 7, 2013 at 11:48 AM, Jonah Graham <jo...@ki...>wrote:
>>>
>>>> Hello,
>>>>
>>>> I know that PyDev officially supports Eclipse 3.2+[1]/Java 6+ (or
>>>> 5?)[2], however I would like to use some features of Java 7 (e.g.
>>>> java.nio stuff). In addition I would love to be able to use various
>>>> apache commons stuff (e.g. StringUtils[3]).
>>>>
>>>> What are the issues/(other?) with supporting older versions of
>>>> Eclipse/Java/etc?
>>>>
>>>> Thoughts/comments?
>>>> Thanks,
>>>> Jonah
>>>>
>>>> [1] There is a little bit of code with correct try/catch in
>>>> PydevPlugin for supporting Eclipse 4+ if it is available.
>>>> [2] On http://pydev.org/download.html it states Jave 6+ (Java 7
>>>> recommended), but on http://pydev.org/developers.html for developers
>>>> the request is still Java 5 API?
>>>> [3] If PyDev did become dependent on apache commons, then I could go
>>>> and remove the (then) redundant code in PyDev's StringUtils?
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>> pyd...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/pydev-code
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Introducing Performance Central, a new site from SourceForge and
>> AppDynamics. Performance Central is your source for news, insights,
>> analysis and resources for efficient Application Performance Management.
>> Visit us today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> pydev-code mailing list
>> pyd...@li...
>> https://lists.sourceforge.net/lists/listinfo/pydev-code
>>
>>
>

Re: [Pydev-code] Java 7 and Apache Commons

[Jonah G. <jo...@ki...>]

Hi Fabio,

I like your conclusion, especially regarding PyDev 3 vs 2 for the breakage.

As for apache commons code, for now that is fine. If I come up with a
specific and strong enough need I will re-raise it. I was aware that you
had spent considerable time writing good quality utility code and don't
want to get rid of any of that. (Perhaps, when you find that elusive free
time ;-), you can improve the apache commons join for everyone.

(Out of curiosity, will there be a major feature set change to go along
with the version change?)

Thanks, and looking forward to PyDev 3.0!
Jonah

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com
jo...@ki...
+44 (0) 1494523014
+44 (0) 7988836817


On 22 August 2013 18:13, Fabio Zadrozny <fa...@es...> wrote:

> Hi Jonah,
>
> Ok, the poll (
> http://pydev.blogspot.com.br/2013/08/pydev-poll-about-minimum-javaeclipse.html)
> has been around for some time already, and it seems the major issue there
> would be support for older versions of Mac OS, where java can't be
> upgraded...
>
> Anyways, I think that given the feedback, going forward to support only
> Java 7 and Eclipse 3.7 onwards is what we should look at...
>
> Still, I think that this breakage should be pretty visible, so, I'd like
> to keep PyDev 2.x releases based on the current dependencies and go forward
> to breaking the dependency in PyDev 3.
>
> The idea would be stabilizing and doing one more release on PyDev 2,
> creating a branch to keep it going, doing one more bugfix-only release from
> that branch and then creating PyDev 3 where we can start targeting Eclipse
> 3.7 onwards and Java 7.
>
> Regarding the apache commons, I took a (rather quick) look at it and I
> don't think they replace all that's used in the PyDev StringUtils... and in
> some cases (i.e.: StringUtils.join), their implementation seems to be
> considerably slower than the current PyDev implementation which was pretty
> optimized, so, I'm a little wary about making that replacement...
>
> As for adding the apache commons, I'd like to know if you have specific
> things you'd like to use (if it's just one or 2 utility classes, I'm not
> sure it's worth the extra weight -- in that case, as their license allows,
> it may be worth just copying those classes).
>
> Cheers,
>
> Fabio
>
> On Wed, Aug 7, 2013 at 9:18 PM, Fabio Zadrozny <fa...@es...> wrote:
>
>> Hi Jonah,
>>
>> I'll do the following: I'll create a blog entry to ask people what they
>> think about... personally, I think going forward is nice, but I'd like to
>> check with the current user base if that's an issue... (at a time I know
>> Mac OS users had problems updating to more recent versions of Java, and
>> Eclipse 3.2 was the version used by Aptana Studio 2, but I don't think it
>> has to be supported anymore).
>>
>> So, I'll ask users to be able to give you feedback :)
>>
>> Cheers,
>>
>> Fabio
>>
>>
>>
>>
>> On Wed, Aug 7, 2013 at 11:48 AM, Jonah Graham <jo...@ki...>wrote:
>>
>>> Hello,
>>>
>>> I know that PyDev officially supports Eclipse 3.2+[1]/Java 6+ (or
>>> 5?)[2], however I would like to use some features of Java 7 (e.g.
>>> java.nio stuff). In addition I would love to be able to use various
>>> apache commons stuff (e.g. StringUtils[3]).
>>>
>>> What are the issues/(other?) with supporting older versions of
>>> Eclipse/Java/etc?
>>>
>>> Thoughts/comments?
>>> Thanks,
>>> Jonah
>>>
>>> [1] There is a little bit of code with correct try/catch in
>>> PydevPlugin for supporting Eclipse 4+ if it is available.
>>> [2] On http://pydev.org/download.html it states Jave 6+ (Java 7
>>> recommended), but on http://pydev.org/developers.html for developers
>>> the request is still Java 5 API?
>>> [3] If PyDev did become dependent on apache commons, then I could go
>>> and remove the (then) redundant code in PyDev's StringUtils?
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>> pyd...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pydev-code
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>
>

Re: [Pydev-code] Java 7 and Apache Commons

[Fabio Z. <fa...@es...>]

Hi Jonah,

Ok, the poll (
http://pydev.blogspot.com.br/2013/08/pydev-poll-about-minimum-javaeclipse.html)
has been around for some time already, and it seems the major issue there
would be support for older versions of Mac OS, where java can't be
upgraded...

Anyways, I think that given the feedback, going forward to support only
Java 7 and Eclipse 3.7 onwards is what we should look at...

Still, I think that this breakage should be pretty visible, so, I'd like to
keep PyDev 2.x releases based on the current dependencies and go forward to
breaking the dependency in PyDev 3.

The idea would be stabilizing and doing one more release on PyDev 2,
creating a branch to keep it going, doing one more bugfix-only release from
that branch and then creating PyDev 3 where we can start targeting Eclipse
3.7 onwards and Java 7.

Regarding the apache commons, I took a (rather quick) look at it and I
don't think they replace all that's used in the PyDev StringUtils... and in
some cases (i.e.: StringUtils.join), their implementation seems to be
considerably slower than the current PyDev implementation which was pretty
optimized, so, I'm a little wary about making that replacement...

As for adding the apache commons, I'd like to know if you have specific
things you'd like to use (if it's just one or 2 utility classes, I'm not
sure it's worth the extra weight -- in that case, as their license allows,
it may be worth just copying those classes).

Cheers,

Fabio

On Wed, Aug 7, 2013 at 9:18 PM, Fabio Zadrozny <fa...@es...> wrote:

> Hi Jonah,
>
> I'll do the following: I'll create a blog entry to ask people what they
> think about... personally, I think going forward is nice, but I'd like to
> check with the current user base if that's an issue... (at a time I know
> Mac OS users had problems updating to more recent versions of Java, and
> Eclipse 3.2 was the version used by Aptana Studio 2, but I don't think it
> has to be supported anymore).
>
> So, I'll ask users to be able to give you feedback :)
>
> Cheers,
>
> Fabio
>
>
>
>
> On Wed, Aug 7, 2013 at 11:48 AM, Jonah Graham <jo...@ki...>wrote:
>
>> Hello,
>>
>> I know that PyDev officially supports Eclipse 3.2+[1]/Java 6+ (or
>> 5?)[2], however I would like to use some features of Java 7 (e.g.
>> java.nio stuff). In addition I would love to be able to use various
>> apache commons stuff (e.g. StringUtils[3]).
>>
>> What are the issues/(other?) with supporting older versions of
>> Eclipse/Java/etc?
>>
>> Thoughts/comments?
>> Thanks,
>> Jonah
>>
>> [1] There is a little bit of code with correct try/catch in
>> PydevPlugin for supporting Eclipse 4+ if it is available.
>> [2] On http://pydev.org/download.html it states Jave 6+ (Java 7
>> recommended), but on http://pydev.org/developers.html for developers
>> the request is still Java 5 API?
>> [3] If PyDev did become dependent on apache commons, then I could go
>> and remove the (then) redundant code in PyDev's StringUtils?
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> pyd...@li...
>> https://lists.sourceforge.net/lists/listinfo/pydev-code
>>
>
>

Re: [Pydev-code] Add 'global functions' to PyDev analyzer

[Andreas P. <an...@fr...>]

Hi Fabio,

On 2013-07-23 13:39, Fabio Zadrozny wrote:
> On Tue, Jul 23, 2013 at 4:46 AM, Andreas Pakulat 
> <an...@fr...> 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 sq...@fr...
froglogic GmbH - Automated UI and Web Testing

Re: [Pydev-code] Add 'global functions' to PyDev analyzer

[Fabio Z. <fa...@es...>]

On Fri, Aug 9, 2013 at 8:19 PM, Jonah Graham <jo...@ki...> wrote:

> Hi,
>
> I need to solve a similar problem. I have some scripts that are user
> editable, but are run by an execfile with some other magic wrapped
> around it. In that magic some new globals are added, which seem in a
> similar way to how web2py is described in
> http://sourceforge.net/p/pydev/feature-requests/534/
>
> What I would like to do is add a new extension point to extend the
> behaviour of CompiledModule:setTokens() and have it essentially add
> new values to "array" within this if statement?
>
>             //as we will use it for code completion on sources that
> map to modules, the __file__ should also
>             //be added...
>             if (array.size() > 0 && (name.equals("__builtin__") ||
> name.equals("builtins"))) {
>                 array.add(new CompiledToken("__file__", "", "", name,
> IToken.TYPE_BUILTIN));
>                 array.add(new CompiledToken("__name__", "", "", name,
> IToken.TYPE_BUILTIN));
>                 array.add(new CompiledToken("__builtins__", "", "",
> name, IToken.TYPE_BUILTIN));
>                 array.add(new CompiledToken("__dict__", "", "", name,
> IToken.TYPE_BUILTIN));
> // extension point data insertion would be here[1]
>             }
>
> Does that sound like a correct solution? Does that seem generally
> useful? If so I can put an initial pull request together for review.
>
> [1] Should the extension point users return AbstractToken, or is there
> a subset of that API that should be exposed (e.g. just name). My
> preference would be AbstractToken, to allow full range of options for
> extension point user.
>

I think it sounds like a proper solution... when getting that, it may be
nice providing the interpreter itself, the shell and the result of
manager.getCompletePythonPath(
 nature.getProjectInterpreter(), nature.getRelatedInterpreterManager())
which are in that same context, as PyDev itself could check if web2py is
installed when asked for the builtins and if it is it could provide the
web2py tokens to support it properly.

The extension point users should probably return a List<IToken>.

Cheers,

Fabio


>
> Jonah
>
>
> On 23 July 2013 12:39, Fabio Zadrozny <fa...@es...> wrote:
> > On Tue, Jul 23, 2013 at 4:46 AM, Andreas Pakulat <an...@fr...>
> > wrote:
> >>
> >> Hi Fabio,
> >>
> >> 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.
> >
> > Now, if that's difficult for you, the
> pycompletionserver.py/importsTipper.py
> > adjustment probably requires less fiddling to integrate.
> >
> > Regarding a better approach within PyDev itself, please create a feature
> > request for that in https://sw-brainwy.rhcloud.com/tracker/PyDev/ (this
> is
> > also a request web2py users have -- for which there's a discussed
> workaround
> > detailed at the old tracker:
> > http://sourceforge.net/p/pydev/feature-requests/534/).
> >
> >>
> >>
> >> Its of course also possible to import those registered modules in the
> >> script file or in one that is being imported into the main script.
> >>
> >> What I ended up doing now which seems to work with 2 caveats (see
> >> further down) is that I'm using the extension points
> >> pydev_interpreter_new_custom_entries, pydev_modules_observer and the
> >> completion extension point. The first one registers the names of the
> >> modules we add via the C API as 'builtins', the second one adds tokens
> >> to the __builtin__ module for those modules and the functions we import
> >> into the global namespace. It also populates our modules with their
> >> functions when the PyDev code needs them (a script importing our squish
> >> module for example). All this seems to avoid errors being flagged for
> >> our Squish API, but does not yet provide the modules and functions for
> >> completion. Hence using the completion extension point to support that.
> >>
> >> The two minor issues with this are:
> >>
> >> 1. For the builtins registration using the
> >> pydev_interpreter_new_custom_entries extension point the users need to
> >> remove and re-add the interpreter so that PyDev fetches the builtins
> >> again.
> >>
> >> Maybe there's a way to do the above programatically upon startup of a
> >> plugin?
> >>
> >> 2. When using 'import squish' in a script now a warning is flagged
> >> about this shadowing a builtin module which is correct from what PyDev
> >> knows but not really happening in the actual interpreter that executes
> >> the tests.
> >>
> >> The second point is not much of a problem as its just a warning and
> >> hence does not jump out at the user as much as an error (in particular
> >> an error in script code that Squish just generated).
> >>
> >> Andreas
> >>
> >>
> >> On 2013-07-22 22:39, Fabio Zadrozny wrote:
> >> > Hi Andreas,
> >> >
> >> > Actually, if you really have a custom interpreter and this is added
> >> > in its startup, it's strange that it doesn't work already (PyDev
> >> > always spawns a shell for the completion and upon startup it'll load
> >> > the __builtin__ -- or builtins -- module and do a dir() in it).
> >> >
> >> > So, if it's custom interpreter, it's mostly a matter of filling the
> >> > __builtins__ at the startup... If that's not the case, you could
> >> > change PyDev to add some custom code at the module scope at
> >> > /org.python.pydev/pysrc/pycompletionserver.py (but you'll have to
> >> > maintain your own fork if you choose this path).
> >> >
> >> > Cheers,
> >> >
> >> > Fabio
> >> >
> >> > On Fri, Jul 19, 2013 at 12:15 PM, Andreas Pakulat
> >> > <an...@fr...> wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I'm currently working on improving our usage of PyDev, in particular
> >> >> starting to let PyDev not only syntax highlight but also analyze the
> >> >> code our users write. Unfortunately this has one drawback, we use a
> >> >> custom interpreter and add several global functions to it (this is
> >> >> done
> >> >> by having a module for these functions and then importing everything
> >> >> from this module by default into the global namespace).
> >> >>
> >> >> I know about the setting for the PyDev analyzer to not show errors
> >> >> on
> >> >> certain undefined functions/variables, but the number of functions
> >> >> makes
> >> >> this single lineedit/preference pretty cumbersome to extend.
> >> >>
> >> >> I'm wondering wether there's a different way (via code maybe?) to
> >> >> teach
> >> >> PyDev about a list of functions it should consider to be
> >> >> 'predefined',
> >> >> similar to the builtin modules?
> >> >>
> >> >> I'm currently using PyDev 2.6, but could upgrade to 2.7.5 if that
> >> >> makes
> >> >> it easier to achieve what I want.
> >> >>
> >> >> Andreas
> >> >>
> >> >> --
> >> >> Andreas Pakulat sq...@fr...
> >> >> froglogic GmbH - Automated UI and Web Testing
> >> >>
> >> >>
> >> >>
> >> >>
> ------------------------------------------------------------------------------
> >> >> See everything from the browser to the database with AppDynamics
> >> >> Get end-to-end visibility with application monitoring from
> >> >> AppDynamics
> >> >> Isolate bottlenecks and diagnose root cause in seconds.
> >> >> Start your free trial of AppDynamics Pro today!
> >> >>
> >> >>
> >> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >> >> [1]
> >> >> _______________________________________________
> >> >> pydev-code mailing list
> >> >> pyd...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/pydev-code [2]
> >> >
> >> >
> >> >
> >> > Links:
> >> > ------
> >> > [1]
> >> >
> >> >
> >> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&amp;iu=/4140/ostg.clktrk
> >> > [2] https://lists.sourceforge.net/lists/listinfo/pydev-code
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > See everything from the browser to the database with AppDynamics
> >> > Get end-to-end visibility with application monitoring from
> >> > AppDynamics
> >> > Isolate bottlenecks and diagnose root cause in seconds.
> >> > Start your free trial of AppDynamics Pro today!
> >> >
> >> >
> >> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >> >
> >> > _______________________________________________
> >> > pydev-code mailing list
> >> > pyd...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/pydev-code
> >>
> >> --
> >> Andreas Pakulat sq...@fr...
> >> froglogic GmbH - Automated UI and Web Testing
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> See everything from the browser to the database with AppDynamics
> >> Get end-to-end visibility with application monitoring from AppDynamics
> >> Isolate bottlenecks and diagnose root cause in seconds.
> >> Start your free trial of AppDynamics Pro today!
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> pydev-code mailing list
> >> pyd...@li...
> >> https://lists.sourceforge.net/lists/listinfo/pydev-code
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > pydev-code mailing list
> > pyd...@li...
> > https://lists.sourceforge.net/lists/listinfo/pydev-code
> >
>
>
> ------------------------------------------------------------------------------
> 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
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>

Re: [Pydev-code] configuring Python Interpreter for more unusual setups

[Fabio Z. <fa...@es...>]

Hi Jonah,

I'm answering inline...

On Sat, Aug 10, 2013 at 9:46 PM, Jonah Graham <jo...@ki...>wrote:

> I have a follow-up questions related to configuring the Python
> Interpreter for what may be considered more "unusual" setups.
>
> The state of play today:
> 1) When creating the interpreter info, the Python reported
> sys.executable is used as the exeOrJar value. (i.e. <executable> in
> interpreterInfo.py output). This means if you select /usr/bin/python
> in the GUI, but that actually a link to /usr/bin/python2.7, the
> exeOrJar added is /usr/bin/python2.7.
> 2) The default selected Python Path is based on whether the folder is
> in sys.prefix (i.e. <lib path="ins">/<lib path="out"> in
> interpreterInfo.py output)
> 3) Jython interpreter must be a jar file[1]
>
> Both of these issues affect configuring PyDev for an interpreter that
> has a custom launch script around it. Two examples are jython on
> Ubuntu and cctbx.python (http://cci.lbl.gov/cctbx_build/). The wrapper
> scripts set up the interpreter properly (e.g. adding -Dpython.home or
> setting LD_LIBRARY_PATH). However, because PyDev uses the advertised
> sys.executable, these interpreters don't work after creation.
>
> What I would like to propose is:
> 1) that the sys.executable is no longer used, and instead PyDev uses
> the path supplied by the user. [2]
>

I think that the major issue I remember in this approach is that java had
problems running files which weren't the actual interpreter (link or shell
script)... but if this is well tested, I guess it's something to check (on
windows/linux I can check here, but I don't have access to mac os to check
that there...). Also, PyDev passes a number of different arguments, so, the
target does have to work as a Python replacement, otherwise you may end up
with the wrong PYTHONPATH when running a project.


> 2) the default paths included are all the paths in sys.path (apart
> from the ones PyDev is inserting, e.g. org.python.pydev/pysrc)
>

I think by default we could add all but the ones from PyDev and the ones
that map to some source folder for a project in the workspace (there's a
button on the config window which does that, but it should probably be the
default).


> 3) Allow Jython to be configured as a wrapper script (i.e. launch as
> exe) (this is actually an orthogonal change, but somewhat related. I
> see this has been an issue before:
>
> http://stackoverflow.com/questions/10671446/error-configuring-jython-2-5-1-on-eclipse-3-7-2-on-ubuntu-12-04


This one is probably a bit trickier as you'd have to mess with doing the
actual launch differently, and the wrapper script would need to accept the
parameters that PyDev uses to configure the paths -- and maintain
compatibility with configuring through the .jar (it's still doable, but a
bit more tricky than the others).


>
> [3])
>
> Frankly, I fear that there are many unknown (to me) issues with making
> this kind of change.
>
> If this sounds broadly acceptable, I will formulate this as an actual
> pull request for proper review. However, if this is unlikely to be
> accepted in any way, I would much appreciate the heads up so that I
> can start looking to permanently solve my interpreter info issues
> another way.
>

I think this is doable and a request that does come up from time to time,
the only thing is checking issues for how java itself interacts with those
launches, possible buffering issues, etc. If you can come up with a patch
running on the different OSes properly, I see no reason not to apply it.


>
> [1] /usr/bin/jython on Ubuntu can be configured as a Python
> interpreter but not a Jython interpreter. However I don't know how
> much real mileage you can really get on that.
>

It should work partially, mostly because you can't get completions from JDT
when configuring Jython with a dependency on a java project as specified in
http://pydev.org/manual_101_project_conf2.html (actually, any executable
which is a 'perfect' Python replacement could be configured as Python, but
Jython/IronPython have special configurations, so, other places may not
work very well -- which is not the case for PyPy, where the recommendation
is setting it up as a Python interpreter).


> [2] As mitigation, if this seems too much of a change, is to add a
> checkbox on the New... or alternatively an addition step in the wizard
> that lets the user select sys.executable value or user entered value
>

If it does work properly this shouldn't be needed...


> [3] I don't know if there are other places in PyDev that rely on
> Jython.jar being run with the same java as is known to Eclipse. For
> example, on Ubuntu it is fairly easy to have /usr/bin/jython use a
> different java than Eclipse is run with.
>

This shouldn't be a problem. As before, the main thing here is the
code-completion on things from the java core.


>
> Thanks for taking time to consider this,
> Jonah
>
>
> On 1 August 2013 21:59, Jonah Graham <jo...@ki...> wrote:
> > Hi Andrew and Fabio,
> >
> > I would like to add my two-cents on this topic. Echoing what Fabio
> > said, I think that PyDev should not include a pre-configured Python
> > (or other environment), however if redhat is providing pydev packages
> > ready to use, it should include pydev configured for the python
> > packages. (Same applies to other distributions, where possible.)
> >
> > I think this should be an external plug-in to pydev, using the
> > extensions available.
> >
> > One option is to fully configure the interpreter. Dawn has a similar
> > use case where jython is packaged to allow scripting of the Dawn suite
> > of tools. At Dawn we use:
> >
> https://github.com/DawnScience/scisoft-ui/blob/master/uk.ac.diamond.scisoft/src/uk/ac/diamond/scisoft/JythonCreator.java
> > to create a Jython Interpreter info automatically. I assume that
> > froglogic's squish does something similar as it includes an Eclipse
> > based IDE using PyDev and a  Python build in its install tree and the
> > Python is all configured in PyDev.
> >
> > Another option is to use/extend my recently contributed changes to
> > PyDev to allow the "Auto" button to be extended. For example, the
> > default implementation of Auto just searches for python, an improved
> > version could look for python2 or python3.2 or whatever else is
> > installed by the package manager. In this situation, a new plug-in
> > that uses package info can contribute to PyDev's Auto by using
> > org.python.pydev.pydev_interpreter_provider to provide a list of all
> > installed Python's known. This new extension point has the option to
> > run an install process too when selected, i.e. it could run yum or
> > whatever to install python.
> >
> > I originally implemented this new feature to make it easier for
> > scientists (who may have limited previous knowledge of
> > installing/configuring Python) to get started with Dawn. It gives the
> > option during Auto to install EPD Free's distribution of Python
> > https://www.enthought.com/products/epd/free/. The advantage of EPD is
> > that it is already preconfigured with all the packages the scientists
> > are likely to need.
> >
> > See https://github.com/fabioz/Pydev/pull/38 for the pull request that
> > added the feature.
> >
> > One final thought. I am about to do some work to make it easier to use
> > cctbx python with PyDev (for Dawn again). cctbx has some extra
> > settings that need to be set-up correctly. I haven't investigated this
> > much yet, but I may extend the above mentioned extension point to
> > allow further configuring of the interpreter info after creation. (The
> > current extension point stops at providing an IInterpreterProvider
> > which provides install option and path/name of installed python).
> > There has also been some discussion of making Sage work with Dawn and
> > PyDev, but I don't know how much demand there is for that yet.
> >
> > BTW Dawn's website in case you haven't come across it:
> > http://www.dawnsci.org/ Much of the work I am currently doing for
> > PyDev is funded by Diamond Light Source http://diamond.ac.uk/ to work
> > on improving Dawn.
> >
> > Jonah
> >
> >
> > On 1 August 2013 19:20, Fabio Zadrozny <fa...@gm...> wrote:
> >> Hi Andrew,
> >>
> >> Actually, it *should* be much better now than at that bug report:
> >>
> >> Right now, when PyDev is activated (i.e.: a Python editor is opened or
> >> something that requires the interpreter), PyDev will already try to
> >> auto-configure an interpreter, searching on different locations
> depending on
> >> your platform.
> >>
> >> After doing that, it'll still ask the user to confirm if that's correct,
> >> which I think is something good to have so that he can at least check
> we got
> >> the correct interpreter.
> >>
> >> This happens at
> >>
> org.python.pydev.ui.interpreters.AbstractInterpreterManager.ConfigureInterpreterJob
> >> (you can test on a brand new workspace opening a .py file).
> >>
> >> So, I think the issue is mostly dealt with...
> >>
> >> What can still be done to improve the situation is that when the new
> project
> >> wizard (which you're familiar with) is opened, if the user still has no
> >> interpreter configured, we'll try to configure it automatically there
> too
> >> (because right now, if he goes there without a configured interpreter,
> he
> >> has to manually click the link to choose the interpreter and press
> >> 'auto-config': this could be done for him as we know he'll have to click
> >> that link before proceeding because he has no interpreter configured --
> you
> >> can check ConfigureInterpreterJob as a reference for how to do that).
> >>
> >> Cheers,
> >>
> >> Fabio
> >>
> >>
> >> On Thu, Aug 1, 2013 at 2:38 PM, Andrew Ferrazzutti <afe...@re...
> >
> >> wrote:
> >>>
> >>> Hi Fabio,
> >>>
> >>> Alex recently assigned me to the bug where PyDev doesn't come a
> >>> pre-configured Python environment. Considering this bug was reported
> six
> >>> years ago, I'm assuming there's some reason why it hasn't been
> addressed. Is
> >>> there a certain way you wanted this to be fixed? Alex suggested using
> an
> >>> extension point to automatically search for /usr/bin/python or
> somewhere
> >>> similar for a usable binary. If there's some other method you'd rather
> use
> >>> I'm all ears.
> >>>
> >>> Andrew
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Get your SQL database under version control now!
> >> Version control is standard for application code, but databases havent
> >> caught up. So what steps can you take to put your SQL databases under
> >> version control? Why should you start doing it? Read more to find out.
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> pydev-code mailing list
> >> pyd...@li...
> >> https://lists.sourceforge.net/lists/listinfo/pydev-code
> >>
>
>
> ------------------------------------------------------------------------------
> 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
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>