New default run settings are not intuitive

[Steve]

I saw some commits in the change log recently related to the Run Settings.  One of the changes leads to unexpected behavior.

It appears the default interpreter option changed.  I just rolled back to an old commit to confirm.  The radio button for "Execute in a new dedicated python interpreter" used to be selected by default.  The new default is "Execute in current Python or IPython interpreter" is checked.  Because of this new default setting after the initial run (F5) additional presses of F5 do nothing.  I finally figured this out by realizing it was new files and it must have to do with the run config for new files versus files I had previously debugged.  I think don't think new behavior is optimal.

-Steve

[Carlos Córdoba]

I made the change so that after pressing F5 on new files, they always be
evaluated in the current interpreter (Python or IPython). I just checked
that it's working as I designed it (on Windows and Linux), i.e. If you
press F5 again, then the file will be ran again in the selected console
with the "runfile" function.

I did it because I saw (in my courses and workshops) that people gets
easily confused with the "Run dialog" and don't know what option to
select. Besides, now that we have a very good IPython integration, I
expect most people will take advantage of it and won't need the "Execute
in a new dedicated python interpreter" option.

However, if you want to get back the old behavior, you can mark the
checkbox at the end of the dialog that reads:

"Always open this dialog on a first file run".

Cheers,
Carlos

El 26/04/13 17:04, Steve escribió:

> --
> You received this message because you are subscribed to the Google
> Groups "spyder" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to spyderlib+...@googlegroups.com.
> To post to this group, send email to spyd...@googlegroups.com.
> Visit this group at http://groups.google.com/group/spyderlib?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Pierre Raybaut]

Carlos,

I'm quite busy these days and I've just played around with latest Spyder revision, just to fix Issue 1363 (for which you asked for my help). Doing so, I've been confronted to this new behavior of the 'Run configuration' dialog which has been renamed to 'Run settings' (why not). First, I find it very risky to introduce a change of behavior of this magnitude at this stage of 2.2 release process (Release Candidate). Second, I was confronted in less than 5 minutes to a bug (an unexpected behavior actually) related to this change: when executing a program which kills the Python process (hard crash or a simple call to sys.exit), Spyder seems to be unresponsive and unable to re-run it as the current interpreter has been terminated... So, that's how I've discovered this new behavior, a quite unpleasant experience.

I really think that such changes should have been introduced at an early stage of development, not just before releasing the final 2.2.

Cheers,

Pierre

2013/4/27 Carlos Córdoba <ccord...@gmail.com>

I made the change so that after pressing F5 on new files, they always be evaluated in the current interpreter (Python or IPython). I just checked that it's working as I designed it (on Windows and Linux), i.e. If you press F5 again, then the file will be ran again in the selected console with the "runfile" function.

I did it because I saw (in my courses and workshops) that people gets easily confused with the "Run dialog" and don't know what option to select. Besides, now that we have a very good IPython integration, I expect most people will take advantage of it and won't need the "Execute in a new dedicated python interpreter" option.

However, if you want to get back the old behavior, you can mark the checkbox at the end of the dialog that reads:

"Always open this dialog on a first file run".

Cheers,
Carlos

El 26/04/13 17:04, Steve escribió:

I saw some commits in the change log recently related to the Run Settings.  One of the changes leads to unexpected behavior.

It appears the default interpreter option changed.  I just rolled back to an old commit to confirm.  The radio button for "Execute in a new dedicated python interpreter" used to be selected by default.  The new default is "Execute in current Python or IPython interpreter" is checked.  Because of this new default setting after the initial run (F5) additional presses of F5 do nothing.  I finally figured this out by realizing it was new files and it must have to do with the run config for new files versus files I had previously debugged.  I think don't think new behavior is optimal.

-Steve
--
You received this message because you are subscribed to the Google Groups "spyder" group.

To unsubscribe from this group and stop receiving emails from it, send an email to spyderlib+unsubscribe@googlegroups.com.

To post to this group, send email to spyd...@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "spyder" group.

To unsubscribe from this group and stop receiving emails from it, send an email to spyderlib+unsubscribe@googlegroups.com.

[Uwe Fechner]

Well, I am happy about this change.

I also teach (currently two groups of 8 students each) data analysis with Python,
and I have to agree that the old behaviour was problematic for newbies.
I like the new behaviour a lot.

Best regards:

Uwe

Am 27.04.2013 17:20, schrieb Carlos C�rdoba:
> I made the change so that after pressing F5 on new files, they always be evaluated in the current
> interpreter (Python or IPython). I just checked that it's working as I designed it (on Windows and
> Linux), i.e. If you press F5 again, then the file will be ran again in the selected console with
> the "runfile" function.
>
> I did it because I saw (in my courses and workshops) that people gets easily confused with the
> "Run dialog" and don't know what option to select. Besides, now that we have a very good IPython
> integration, I expect most people will take advantage of it and won't need the "Execute in a new
> dedicated python interpreter" option.
>
> However, if you want to get back the old behavior, you can mark the checkbox at the end of the
> dialog that reads:
>
> "Always open this dialog on a first file run".
>
> Cheers,
> Carlos
>

> El 26/04/13 17:04, Steve escribi�:

[Carlos Córdoba]

Hi Pierre,

Good to hear from you again! I gave a lot of thought to this change, and I didn't want to do it so close to the final release, but I was busy fixing other complex bugs.

From the source code point of view, things are almost exactly as before: I just changed the dialog's default to "current interpreter" and added a checkbox to let the user decide between the old and the new behavior, so the bug you mention was most probably there before.

Experienced or old time users can mark the mentioned checkbox and things for them will be as they always have been. But newbies (as Uwe mentions) will have a much easier and pleasant time with Spyder without being confronted with a complex set of options from the start.

I hope you understand my motivation: my aim is to lead Spyder to a wider audience, i.e. people who is learning or giving their first steps with Python, but maintaining all the configurability and adaptability it currently has.

I'll work hard to solve any bugs that show up (starting with yours :-) and time will tell if I took the right decision or not.

Cheers,
Carlos

El 28/04/13 07:58, Pierre Raybaut escribió:

Carlos,

I'm quite busy these days and I've just played around with latest Spyder revision, just to fix Issue 1363 (for which you asked for my help). Doing so, I've been confronted to this new behavior of the 'Run configuration' dialog which has been renamed to 'Run settings' (why not). First, I find it very risky to introduce a change of behavior of this magnitude at this stage of 2.2 release process (Release Candidate). Second, I was confronted in less than 5 minutes to a bug (an unexpected behavior actually) related to this change: when executing a program which kills the Python process (hard crash or a simple call to sys.exit), Spyder seems to be unresponsive and unable to re-run it as the current interpreter has been terminated... So, that's how I've discovered this new behavior, a quite unpleasant experience.

I really think that such changes should have been introduced at an early stage of development, not just before releasing the final 2.2.

Cheers,

Pierre

2013/4/27 Carlos Córdoba <ccord...@gmail.com>

I made the change so that after pressing F5 on new files, they always be evaluated in the current interpreter (Python or IPython). I just checked that it's working as I designed it (on Windows and Linux), i.e. If you press F5 again, then the file will be ran again in the selected console with the "runfile" function.

I did it because I saw (in my courses and workshops) that people gets easily confused with the "Run dialog" and don't know what option to select. Besides, now that we have a very good IPython integration, I expect most people will take advantage of it and won't need the "Execute in a new dedicated python interpreter" option.

However, if you want to get back the old behavior, you can mark the checkbox at the end of the dialog that reads:

"Always open this dialog on a first file run".

Cheers,
Carlos

El 26/04/13 17:04, Steve escribió:

I saw some commits in the change log recently related to the Run Settings.  One of the changes leads to unexpected behavior.

It appears the default interpreter option changed.  I just rolled back to an old commit to confirm.  The radio button for "Execute in a new dedicated python interpreter" used to be selected by default.  The new default is "Execute in current Python or IPython interpreter" is checked.  Because of this new default setting after the initial run (F5) additional presses of F5 do nothing.  I finally figured this out by realizing it was new files and it must have to do with the run config for new files versus files I had previously debugged.  I think don't think new behavior is optimal.

-Steve
--
You received this message because you are subscribed to the Google Groups "spyder" group.

To unsubscribe from this group and stop receiving emails from it, send an email to spyderlib+...@googlegroups.com.

To post to this group, send email to spyd...@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "spyder" group.

To unsubscribe from this group and stop receiving emails from it, send an email to spyderlib+...@googlegroups.com.

To post to this group, send email to spyd...@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "spyder" group.

To unsubscribe from this group and stop receiving emails from it, send an email to spyderlib+...@googlegroups.com.

[Pierre Raybaut]

Ok, I understand your point of view and I think that it's probably best to keep it that way for beginners.

This odd behavior I found out ("Re-run" a script in current interpreter fails silently if there is no running interpreter) is actually a bug which is not produced by your recent change: this recent change of behavior is only making it happen more easily. So, no worry, really.

I see two actions that would need to be taken care of to close this issue:

1. Warn the user (with a warning pop-up dialog box) if the current "Run settings" is set to "Run in current interpreter" *and* if there is no interpreter currently running. This will avoid the "Run" command to fail silently.

2. Show the "Run settings" the first time a script is ever run, so that every one will be fully conscious of the new default behavior (run in current interpreter) and the new "show Run Settings at each run" check box. Beginners will directly click on the "Run" button without changing anything and the dialog won't show again so that they won't be troubled by this mysterious choice again.

I've implemented point 1 here:

https://code.google.com/p/spyderlib/source/detail?r=c1e17dc89477f27cd251fb59340a067eaa45b9f8

and point 2 there:

https://code.google.com/p/spyderlib/source/detail?r=00e148391c5b454b8c144fd1553b0a2155be8e12

With those minor changes above, I'm ok with this new behavior!

-Pierre

2013/4/28 Carlos Córdoba <ccord...@gmail.com>

[Uwe Fechner]

Hello,

I tested your change and it is going into the correct direction.

But one problem remains:
I have enabled "open an ipython console at startup" in the preferences.

If I now run a script with F5, close spyder, start it again and immediately
press F5 again I get the message:
"

No Python shell is currently available to run Hello2.py.

Please open a new Python interpreter and try again.

"
This message appears, because it takes a second or a few seconds, until
the ipython console appears.

If I wait until the console appears and press F5 again, than this message
appears again. And this is wrong: I have already an open ipython console,
why should I open a new instance?

I have to click into the ipython console and than I can run the script with
F5.

So either the message should be changed to:
"Please click into an existing console or open a new one."

Or, preferably the execution of the F5 command should be delayed until
there is an open console (under the condition, that ipython is just launching).

Best regards:

Uwe Fechner

[Sylvain Corlay]

Hi Pierre, 

I think that the current error message is a bit misleading in the case where there is a shell opened but it does not have the focus. For example, if there is an ipython console opened but the standard console widget is selected. 

Something in this spirit of 

"No Python shell is currently selected to run stuff.py, please select or open a new python interpreter." 

woud maybe be more clear. 

Best, 

Sylvain

[Steve]

Does it make sense for spyder to just complain about no open interpreter (and not just go ahead and launch a new one)?  Does the ipython interpreter never close?  I'm not seeing how this change makes anything easier for new users beyond the initial run unless you're assuming all new users use ipython and those interpreter sessions never close.  Otherwise they're going to be met with the dialog complaining that no interpreter is open and they're going to have to learn about these concepts anyways.

I understand the desire to help new users, but sneaking a software behavior change into an RC just before release is a good way to introduce breakage and confusion for current users.

[Sylvain Corlay]

I completely agree with the changes of Carlos and the additions of Pierre regarding this behavior. I am trying to convince people to switch from environment like matlab and I think that this change is both minor, harmless and helps beginners. 

However, the problem I mentioned earlier  is a bug to me. It is a problem of focus:

If you have both the console widget and the ipython console widget opened, with the cursor/focus in the python widget and you click on ipython console tab, the pure python console keeps the focus and further hits on the run button will be executed in the console. When the one does the reverse (put the cursor in the ipython console and click on a normal python console tab), the focus moves as expected to the python console. 

I hope I was clear. I think that this is probably a one line fix. I can try to look at it. 

Cheers, 

Sylvain

[Carlos Córdoba]

Thanks Sylvain for the detailed explanation. I'll fix the problem you report ASAP.

Cheers,
Carlos

El 29/04/13 10:32, Sylvain Corlay escribió:

[Steve]

Can you confirm the ipython behavior?  Does the interpreter normally stay open forever thus allowing additional runs to happen in the same interpreter?

[Sylvain Corlay]

Hi Steve, 

ipython should not close unless

 - there is a hard crash involving the underlying python interpreter

 - one runs a code that calls sys.exit or something like this. 

Best, 

Sylvain

[Pierre Raybaut]

@Sylvain: I've just changed the warning message

@Uwe: the best behavior would be to wait until the IPython client is ready but it would require some coding (let's continue this in v2.3)

@Steve: I agree that it's a bit late to introduce this kind of behavior change.

@All:

I've just had an idea of how we could settle this matter for both beginners and advanced users.

We could:

1. reintroduce the old "Run in current (Python/IPython )console" action (Alt+F5, for example) as an additional action in "Run" menu/toolbar.

2. the current "Run" action (F5) will remain unchanged (with the old default behavior, i.e. "run in a dedicated interpreter" enabled but with "always show on a first rerun" disabled)

So, Carlos, Uwe, you may suggest to your students to use Alt+F5 instead of F5:

a. Use F5 to run a script in a clean/dedicated Python interpreter: this is recommended for developing applications

b. Use Alt+F5 to run a script in current Python interpreter: this is recommended for interactive computing

=> No unpleasant/unexpected change for current (or advanced) users.

=> Easier for beginners who would probably use Alt+F5 more often than F5

What do you think about this suggestion?

2013/4/29 Steve <steve.f....@gmail.com>

[Sylvain Corlay]

Regarding your proposition, I am not sure that it is good to have more run buttons

We already have 

 -Run

 -Run selection

 -Run again last script in external console with the same options (I am not sure why this one is really useful by the way)

 -Debug 

 -Continue (which looks like a run button and could maybe be merged with debug in the future)

The current 'edit run configurations' is probably a good way to factorize it. 

Best, 

Sylvain

[Carlos Córdoba]

Pierre, I think the change you suggest will introduce a bit more complexity and confusion, because it will add another button/action that this almost as "Run" but not exactly it.

I know it's very annoying and troublesome for old time users to change a behavior that has been there since at least version 2.0, but at any time they could click the checkbox I added to the dialog and have it back. We could even select "External interpreter" as the default radio when the user clicks that checkbox.

This is kind of what happens when Firefox changes an old behavior for a new one: people complain but then adapt. It's really hard to please everyone, but it's also not good to maintain old habits when they are not easy to grasp or intuitive.

I think this is a good chance to improve on a decision that was taken a long time ago.

Cheers,
Carlos

El 29/04/13 11:41, Pierre Raybaut escribió:

[Sylvain Corlay]

Just wondering, how close are you guys from the final release of 2.2? 

Best 

[Carlos Córdoba]

There is one more bug to be fixed before the final release. I hope everything is ready by the end of the week.

One more thing Sylvain: The bug you described before happens when the IPython console doesn't have any open console and there is at least one in the Python one?

El 29/04/13 14:34, Sylvain Corlay escribió:

[Sylvain Corlay]

It happens even if there is an ipython console openned.

I have the impression that the last push of Pierre solved this issue. I will only be able to check later tonight.

Best,

You received this message because you are subscribed to a topic in the Google Groups "spyder" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/spyderlib/BZvXgRlPVjQ/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to spyderlib+...@googlegroups.com.

[Jed Ludlow]

On Mon, Apr 29, 2013 at 3:12 PM, Carlos Córdoba <ccord...@gmail.com> wrote:

There is one more bug to be fixed before the final release. I hope everything is ready by the end of the week.

One more thing Sylvain: The bug you described before happens when the IPython console doesn't have any open console and there is at least one in the Python one?

El 29/04/13 14:34, Sylvain Corlay escribió:

Just wondering, how close are you guys from the final release of 2.2? 

Best 

Might I suggest that we use this list rigorously to decide which of the remaining issues marked as MS-v2.2 are really going to be treated  before final release?

https://code.google.com/p/spyderlib/issues/list?can=2&q=MS%3Dv2.2+&colspec=ID+MS+Stars+Priority+Modified+Cat+Type+Status+Owner+Summary&cells=tiles

I started moving a few off the list that seemed obvious to me, but there are others that are not so obvious.

Jed

[Carlos Córdoba]

Jed, the bug I was referring to is issue 1368, which is tied to issue 1365. All the others can wait for 2.2.1, .2, etc.

Cheers,
Carlos

El 29/04/13 16:35, Jed Ludlow escribió:

[Carlos Córdoba]

Jed, I think it would be better to just raise to "Critical" the priority level of Issues that really need to be solved on the next release instead of creating new labels because in a very short time we'd have too much of them.

Cheers,
Carlos

El 29/04/13 16:55, Carlos Córdoba escribió:

[Jed Ludlow]

On Mon, Apr 29, 2013 at 4:20 PM, Carlos Córdoba <ccord...@gmail.com> wrote:

Jed, I think it would be better to just raise to "Critical" the priority level of Issues that really need to be solved on the next release instead of creating new labels because in a very short time we'd have too much of them.

Cheers,
Carlos

You are free to change them back. I would argue that it becomes very difficult to decide which issues are really going to be addressed by which release unless you go to the level of including bug fixing releases in the list of milestones. Furthermore, it makes it very easy to create release notes when every issue is assigned to a specific release milestone. Just filter by that release. We should not go back and relabel things for old releases, but I don't see the harm in making it more explicit starting from today.

And it's just one more integer in the label field. No need to conserve integers. There is an infinite supply of them :).

Jed

 

[Sylvain Corlay]

@Carlos,

My mistake, I just tested and the bug happens either when the focus is on an ipython kernel or a dead interpreter (killed with sys.exit() for example).

Cheers,

Sylvain

either there is no python console selected or when 

To unsubscribe from this group and stop receiving emails from it, send an email to spyderlib+unsubscribe@googlegroups.com.

To post to this group, send email to spyd...@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to a topic in the Google Groups "spyder" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/spyderlib/BZvXgRlPVjQ/unsubscribe?hl=en.

To unsubscribe from this group and all its topics, send an email to spyderlib+unsubscribe@googlegroups.com.

[Carlos Córdoba]

Sylvain, I'm sorry but I'm not following you. Could you please give me a list of steps that reproduce the bug you are reporting?

Cheers,
Carlos

El 29/04/13 22:08, Sylvain Corlay escribió:

[Sylvain Corlay]

Alright, Here are the steps to reproduce:

1) Open both the console widdet and the ipython console widget. (I usually dock them together and it is easier to reproduce it when it is docked together for a reason explained later)

2) Open an ipython console in the ipython console widget

3) Either kill the console with sys.exit() or put the focus on the ipython kernel. 

4) Click on the tab of the ipython widget. (Do not click in the middle of the console, but only on the tab)

5) Try to run some code with the "Run selected script in current console" button. 

6) Pierre's Warning message is displayed while you clearly have a valid ipython console displayed.

7) Then if you click on the console itself, you will see your cursor and the same run button will work as expected. 

This problem does not occur when you go from ipython to python. 

I hope this helps.

Sylvain

Sylvain

You received this message because you are subscribed to a topic in the Google Groups "spyder" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/spyderlib/BZvXgRlPVjQ/unsubscribe?hl=en.

To unsubscribe from this group and all its topics, send an email to spyderlib+...@googlegroups.com.

To post to this group, send email to spyd...@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Carlos Córdoba]

Gotcha now! (and thanks for your patience :-). I was tracking this bug since this morning because the warning messages introduced by Pierre are not showing correctly when you move from Python to IPython and back, which is a similar situation to yours but with no consoles in both.

I think I found where is the problem and the solution. I'll push it tomorrow.

Cheers,
Carlos

El 29/04/13 22:29, Sylvain Corlay escribió:

[Pierre Raybaut]

At least we have here a good illustration of how important it is to avoid silent failures. By adding this warning message box, I haven't introduced bugs: they were already there, hiding silently. Explicit is better than implicit, definitely :-)

[Pierre Raybaut]

@Jed: I think that's a very good idea to add issue labels for each Spyder release (e.g. "MS-v2.2.1", "MS-v2.2.2", etc.). This will clearly help us sort/prioritize tasks for future releases.

2013/4/30 Jed Ludlow <jed.l...@gmail.com>

--

[Carlos Córdoba]

Yep, totally true, but it also shows the importance of teamwork to polish these subtle and delicate changes: I contributed the initial implementation, you added the QMessage's and finally I solved the hidden bug that they revealed :-)

El 30/04/13 04:19, Pierre Raybaut escribió:

[Jed Ludlow]

On Tue, Apr 30, 2013 at 4:23 AM, Pierre Raybaut <pierre....@gmail.com> wrote:

@Jed: I think that's a very good idea to add issue labels for each Spyder release (e.g. "MS-v2.2.1", "MS-v2.2.2", etc.). This will clearly help us sort/prioritize tasks for future releases.

@Pierre: I would normally not advocate creating a v2.2.1 milestone and assigning issues to it before v2.2.0 is even released, but it seems in this case since v2.2.0 is such a big release there is bound to be a need for some micro bug fixing release before releasing v2.3.0. Would you mind adding v2.2.1 to the list of "standard" milestones through the project admin pages? Otherwise the issues list doesn't sort right if you try and sort on the MS column.

[Sylvain Corlay]

Great!

By the way, the tooltips of the "run" button and the "run again last script" specify "in the current console" which is not correct if it is executed in a new dedicated python interpreter. 

Best,

Sylvain

[Pierre Raybaut]

@Carlos: just to be clear, I was not criticizing your work!

Actually the fact that running a script in current console would fail silently is because of me initially: I did implement the first feature of this kind (running in current Python interpreter) and I didn't handle the case where a console was not ready to receive the execute command (because it was not the most used feature at that time...).

2013/4/30 Carlos Córdoba <ccord...@gmail.com>

[Sylvain Corlay]

Same thing for the debug button. 

By the way, there are really many ways to run a script in spyder. What do you think of suppressing

   - run again last script/ re-run last script

   - Debug with winpdb

altogether? 

Best, 

Sylvain

[Jed Ludlow]

On Tue, Apr 30, 2013 at 7:18 AM, Sylvain Corlay <sylvain...@gmail.com> wrote:

Same thing for the debug button. 

By the way, there are really many ways to run a script in spyder. What do you think of suppressing

   - run again last script/ re-run last script

   - Debug with winpdb

altogether? 

Best, 

Sylvain

I use "Debug with winpdb" quite often, so I'd like to keep it on the list. 

[Uwe Fechner]

Hello,

I think that re-run last script is really useful when you are editing
a sub-module but need to run the main program for testing your
changes.

Alternatively there could be the option "set main program" in the
menu, as it exists in TeXStudio for example. But not for the 2.2 release.

Best regards:

Uwe

[Carlos Córdoba]

@Pierre: Don't worry, I didn't feel you were criticizing it :-) I just wanted to point out the importance of teamwork in cases like this.

El 30/04/13 07:55, Pierre Raybaut escribió:

[Pierre Raybaut]

To sum up the situation:

1. Before the recent changes made by Carlos ("run in current console" is the default option + "always show run settings dialog box" check box), pressing F5 was systematically opening the Run Settings dialog box and the default option for the Python interpreter was "Run in a new dedicated Python interpreter". Beginners were confused by this recurrent dialog box and by the fact that running in a new interpreter each time was not compatible with interactive scientific computing (traditionnally done in the same interpreter, like in MATLAB or IDL). Advanced users were satisfied because running a script in a new/dedicated interpreter is the cleanest way of executing Python scripts and especially GUI-based applications.

2. After the recent changes made by Carlos, as beginners were supposingly satisfied, advanced users were confused because they now had to open the Run Settings dialog, click on the "Always open this dialog on a first file run" check box, and each time they would want to run a script in a new/dedicated Python interpreter (like before), they would have to click on the radio button "Execute in a new dedicated Python interpreter". So, basically, beginners would only have to press one button (instead of two) whereas regular users would have to press three buttons (instead of two).

How can we settle this matter once and for all?

By implementing a new configuration page which may be used to set default run settings:

(see here: https://code.google.com/p/spyderlib/source/detail?r=2d8a59fb0548a02c7647cb514fdd60301ddc82fc)

-Pierre

2013/4/30 Carlos Córdoba <ccord...@gmail.com>

[Sylvain Corlay]

I like this idea, but will only be able to test it tonight (NY time). 

[Carlos Córdoba]

@Pierre: Fair enough, I think it is the best compromise.

@Sylvain: I pushed the change I mentioned last night. Please test it to see if the bug you reported is finally fixed.

El 30/04/13 12:48, Sylvain Corlay escribió:

[Sylvain Corlay]

Hi Pierre, I like your changes very much, especially the possibility to use a common default directory other than the script directory. 

Rather than being a separate directory, could it be the "Global working directory", the one that is set up in the "Global working directory" toolbar.

The menu would be the following: 

Default working directory is: 

o the script directory

o the global working directory: ["/home/sylvain/..."] (Button "set global working directory" as in the toolbar and scroll down menu as in the toolbar) .

Cheers, 

Sylvain

[Sylvain Corlay]

Hi Carlos, 

I confirm that it solves the problem for me. 

Thanks

Sylvain

2013/4/30 Carlos Córdoba <ccord...@gmail.com>

2013/4/30 Carlos Córdoba <ccord...@gmail.com>

Sylvain

For more options, visit <a moz-do-n

...

[Pierre Raybaut]

@Sylvain: this is a good suggestion to add the Global Working Directory as the execution working directory but adding this option to the "Run" configuration page (Preferences) is not the right place. I think that the best would be to change the "Run Settings" dialog because the "Run" configuration page is only used to set default parameters, and setting the Global Working Directory as default execution working directory would only works once: the first time the script is executed. Every other time a script would be executed, the working directory wouldn't be updated to the current value of Global Working Directory as I would expect it to be. Instead, if this option is set in "Run Settings" dialog, the execution working directory would be set each time the script is executed to the current value of Global Working Directory.

Let's continue this discussion here, if necessary:

https://code.google.com/p/spyderlib/issues/detail?id=1375

2013/5/1 Sylvain Corlay <sylvain...@gmail.com>

[Steve]

I just updated and I can't get the preferences dialog to come up.

...

[Carlos Córdoba]

This is most probably do to Issue 1365. I'll fix it by the end of the day.

El 01/05/13 09:31, Steve escribió:

[Pierre Raybaut]

AFAIK, the Preferences dialog box is broken on Windows for a few days at least (?):

https://code.google.com/p/spyderlib/issues/detail?id=1368

2013/5/1 Steve <steve.f....@gmail.com>

[Jed Ludlow]

On Wed, May 1, 2013 at 8:33 AM, Carlos Córdoba <ccord...@gmail.com> wrote:

This is most probably do to Issue 1365. I'll fix it by the end of the day.

El 01/05/13 09:31, Steve escribió:

I just updated and I can't get the preferences dialog to come up.

Yes, I can confirm that the series of commits referenced in the original post of issue 1365 [1] is the source of the Preferences dialog problem Steve mentioned. Rolling back the series of commits restores the the proper preferences dialog behavior. Carlos should have a solution soon.

[1] https://code.google.com/p/spyderlib/issues/detail?id=1365 

[Sylvain Corlay]

I just installed and tested for a few minutes the last dev version (revision d77419e120c7 ) with the correction of Carlos on a Win 7 computer, and it seems to work so far. 

Best,

Sylvain