Could you try out the following steps?
- Open the coder. (On Windows, just enter
Psychopy3 Coderin the search bar)
- From the coder view, open your builder file.
- Run the experiment.
Does this give you output?
Could you try out the following steps?
Psychopy3 Coderin the search bar)
Does this give you output?
I think I’ve had the same issue. Observations:
Hope this helps.
On my Mac (Version 10.14.6) I get the same thing with PsychoPy 2020.2.4. Nothing except the “Running: …” message is sent to the live logging/the supposed Stdout. I tried putting some
print() statements inside of a functioning experiment, but the printed messages don’t show up in Stdout either. It’s the same thing on my other PC, regardless of whether I run PsychoPy in Ubuntu (20.04) or Windows (10). Even if I try opening up an experiment’s “.py” file using the Coder View, or if I run the experiment only once with Builder, I still don’t get any output sent to “Stdout”. In Windows, I did get the “Welcome to PsychoPy3!” message when I ran an experiment with Builder the first time, but then I didn’t get any error messages (even though I ran a malfunctioning experiment that preemptively quit without any description of why). In the Ubuntu case, I hadn’t previously installed PsychoPy, so I don’t think this has anything to do with old preferences lying around or something similar.
Because debugging becomes a lot harder when we can’t see output errors or even inserted print statements’ messages, I actually tried opening up my experiments with an older, pre 2020.2, version of PsychoPy. But that doesn’t work either, because all .psyexp files that have been opened with 2020.2.x have the “before experiment” tab/data for code snippets, and even if it’s empty that breaks backwards compatibility. So for whatever .psyexp file that 2020.2.x has touched, and that I don’t have a backup of, I’m stuck with having no Stdout, unless I actually manually copy routines/components/preferences over to an older version’s project. I do have version control for experiments, but I’d done a number of edits to a couple of them after upgrading to 2020.2.4, so these edits are lost if I backtrack through git commits.
Side issues: I’ve seen some other oddities with the latest version of PsychoPy. If I launch PsychoPy on my Mac, it does start, but I’m not actually shown the Builder window et c until I click the PsychoPy icon in the Dock, I have no idea why (this is different from Ubuntu/Windows). Also on Mac, when I force quit (Esc+Esc) out of experiments, they sometimes leave “ghost windows” behind, meaning that when I go to Mission Control, there are “invisible” empty windows/frames, only noticeable by the space they take up and the border that becomes visible when hovering with the mouse over them. I have to manually close them for them to go away. Just now I got an “unhandled internal error” in Windows related to “PavloviaMenu.appData(‘pavloviaUser’)”: “TypeError: ‘NoneType’ object is not subscriptable”. I’ve had various other error messages pop up recently, but I’ve become a bit numb to them as reporting everything takes time.
The lesson I’ve learned is that I can’t depend on PsychoPy’s latest version to be stable, and I should probably wait before upgrading to any new major release until a number of minor versions have been released. But again, I can’t easily go back in this case.
Edit: I reread @LukasPsy’s post and tried again. I am indeed able to see the output if I open up coder view, open the .psyexp file from the coder view’s file browser, and then click the “run directly” button in the Builder view that pops up.
I’m experiencing the same problem. No error message on stdout. @LukasPsy solutions works, but it would be good if this bug could be fixed.
Yes, that does work (thankfully!).
(Although the “Run experiment” button in Builder doesn’t run the experiment, I always have to send it to the Runner and run from there (but that is a different bug))
We’re trying to work this one out but haven’t been able to recreate the issue ourselves. It seems like there’s some preference, or combination of preferences, that cause this to happen. We’ve certainly heard from one user that moving/deleting the preferences folder has fixed the issue. We haven’t been able to work out what key preference(s) are the issue
Any news on this? It also seems to be an issue with some windows machines with coder and here the fix by @LukasPsy doesn’t apply.
We’ve found a way we can reproduce the the issue reliably (and I now suspect that the preferences suggestion was red-herring). It turns out that when you close the Runner then on subsequent runs it doesn’t print. So my guess is that the people being affected are habitual closers of the Runner view. I suspect they’re also the people complaining that they don’t like the runner because the output isn’t so easily visible.
@TParsons will surely have that fixed very soon and we’ll push out a 2020.2.5
In the meantime (and what Todd and I obviously do anyway which is why we couldn’t replicate the problem), leave the runner view open, and just sit it next to the Coder. Then you get to see the outputs all the time when you run your scripts. No need to keep closing it
So my guess is that the people being affected are habitual closers of the Runner view. I suspect they’re also the people complaining that they don’t like the runner because the output isn’t so easily visible.
Actually, in our defense, I don’t think that what brings everyone together is necessarily that we’re “Runner-closers” I get the same behavior if I double-click a .psyexp file so that PsychoPy opens it up straight away (rather than opening up PsychoPy, then using the “Open file…” option et c). I’m guessing that in the process, PsychoPy first opens up a “general” Runner window, but then closes that and opens up a new one that specifically adds the experiment whose .psyexp file was double-clicked, triggering PsychoPy to launch. (it took me some time to understand this, hence a previous confusing post here which I deleted)
Just double-clicking the .psyexp file, rather than first opening up PsychoPy and then navigating to the file, always seemed more convenient to me.
OK, that does give us another avenue to explore as well
Confirming… I have the same problems on a MacOS Catalina 10.15.6:
I have exactly the same issue.
I’m a windows user, new to psychopy3 but have not been closing the runner view habitually.
It seems that if I convert my builder view to a coder view and open the script from psychopy rather than double-clicking, it does send the print statements/errors etc to stdout. However I can’t do this at all from the builder view no matter which way I open it and regardless of the runner opening/closing. It makes it really hard to debug small snippets of code for simple experiments that can be done in the builder view.
Do you know roughly when you’ll have a fix? Thank you!!
We’ve identified the fix and it will be released very soon in 2020.2.5
If you want to fix in your own installation without upgrading then the necessray tweak can be seen here:
Hi, at least 10% of our students have this problem (mostly on Windows).
No errors are shown in the runner (although errors are present in the experiment and it doesn’t run) - the same happens on
2020.2.5 version, unfortunatelly. We tested the issue also on
2020.2.3. The errors show up in
2020.1.3 - so we will switch to this version for the rest of the course. We have some simple psyexp files to reproduce the issue and were able to reproduce it on multiple Windows machines.
If you have the minimally working psyexp file examples please could you load them to a pavlovia project and log it as an issue on the github with your supporting files - this will help the dev team work out any bugs!
We’ve certainly improved this in the last release. It turned out then that the issue depended on the way in which the application was being opened. I wonder if you have any clues here from the people that are still failing to get prints to stdout. Maybe some open by double-clicking a file? Others might open the app but then immediately close the Runner? etc
If you’re able to provide any further insight into what differs form users that have a problem and users that have no problem it might help us (I haven’t been able to replicate on my own tests but maybe there’s some sequence that I’m not doing)
Sorry for the delays in responding @jon. We should be able to post the problematic psyexp file today.
The files were usually opened by double-clicking the file. At least my wife, who teaches this course, opened files this way.
For one of the files last time the errors re-emerged after using “send to runner” instead of “run procedure”. We didn’t know if there is a difference - we still have habits from older Psychopy version (the new interface is wonderful BTW!). And after “send to runner”, running the procedure again with the normal “run” gave error window even though before it was not present.
I will write more today/tomorrow (along with the problematic file)!
I don’t know about closing the Runner - we never closed the Runner or never instructed our students to do so. But students sometimes are still able to surprise me However, it is possible to reproduce the problem without closing the Runner.
We asked some students experiencing the problem to go back to version
2020.1.3 - it is the most recent version that does not have the issue.
This is the file we had problems with. The problem is with a typo in the text object when referencing excel column (“kolor” instead of “kolory”), but the error does not appear when running the experiment: the psychopy experiment screen is shown but then closes without errors shown. For this file the error is still hidden if we use “send to runner”.
We’ve just confirmed that opening PsychoPy (
2020.2.3) first and then opening the file via file → open leads to errors being shown in the runner. We are now testing this with
2020.2.8 (you release versions fast!).
These are the files:
list.xlsx (4.7 KB) exercise2.psyexp (6.9 KB)
Good news: the problematic file works well on
2020.2.8, meaning the error is shown in the Runner! We tested that file earlier on
2020.2.5 at some point and still had the problem so maybe something was fixed after
2020.2.5?). We will test some other files that produced this error and ask some students to see if
2020.2.8 works for them and will let you all know!
Cool, thanks @mmagnuski
Basically, there are several routes by which the Runner window could be activated and it turned out we hadn’t included the check for stdout in all of them. I think we’re there now!