Re: Friday finking: IDE 'macro expansions'
On Fri, Mar 17, 2023 at 11:55:38AM +1300, dn via Python-list wrote: Do you make use of your IDE's expansionist tendencies, and if-so, which ones? Unix (well, GNU/Linux) is my IDE ;) Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday finking: IDE 'macro expansions'
Op 17/03/2023 om 0:54 schreef Thomas Passin: What I find more useful is matching brackets/parens/braces. Not inserting them but highlighting or (better) jumping to the matching one when asked. That is very helpful indeed. Even better than simply highlighting is (IMO) a thing called "Rainbow Braces" or "Bracket Pair Colorization" I recently learned about: both braces of a matching pair get the same color, while other pairs get other colors. I have to say I like it quite a lot. It's in VS Code these days; possible there are implementations or extensions for other editors and IDEs as well. -- "Most of us, when all is said and done, like what we like and make up reasons for it afterwards." -- Soren F. Petersen -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday finking: IDE 'macro expansions'
On Fri, Mar 17, 2023 at 02:05:50PM +0100, Roel Schroeven wrote: Even better than simply highlighting is (IMO) a thing called "Rainbow Braces" or "Bracket Pair Colorization" I recently learned about: both braces of a matching pair get the same color, while other pairs get other colors. I have to say I like it quite a lot. It's in VS Code these days; possible there are implementations or extensions for other editors and IDEs as well. VS Code also supports ‘semantic highlighting’: Instead of simply highlighting syntax, highlight the same identifiers in the same colours, with the aim of helping you see them through the flow of the code. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday finking: IDE 'macro expansions'
On 3/17/2023 9:38 AM, Simon Ward wrote: On Fri, Mar 17, 2023 at 02:05:50PM +0100, Roel Schroeven wrote: Even better than simply highlighting is (IMO) a thing called "Rainbow Braces" or "Bracket Pair Colorization" I recently learned about: both braces of a matching pair get the same color, while other pairs get other colors. I have to say I like it quite a lot. It's in VS Code these days; possible there are implementations or extensions for other editors and IDEs as well. VS Code also supports ‘semantic highlighting’: Instead of simply highlighting syntax, highlight the same identifiers in the same colours, with the aim of helping you see them through the flow of the code. Even with a simple "Find" command I don't like that behavior, let alone for programming. I find that all those other marked instances make it harder for me to read the surrounding material. They are good for moving from one instance to another, but otherwise they get in the way for me. -- https://mail.python.org/mailman/listinfo/python-list
Numpy, Matplotlib crash Python 3.8 Windows 7, 32-bit - can you help ?
Crash report: Problem Caption: Problem Event Name: APPCRASH Application name: python.exe Application version: 3.8.7150.1013 Application time signature: 5fe0df5a Error module name:_multiarray_umath.cp38-win32.pyd Version of the module with the error: 0.0.0.0 Time signature of the module with the error: 63dfe4cf Exception code: c01d Exception offset: 000269c9 Operating system version: 6.1.7601.2.1.0.256.48 Regional Settings ID: 1045 Additional information 1: 0a9e Additional information 2: 0a9e372d3b4ad19135b953a78882e789 Additional information 3: 0a9e Additional information 4: 0a9e372d3b4ad19135b953a78882e789 -- https://mail.python.org/mailman/listinfo/python-list
Re: Numpy, Matplotlib crash Python 3.8 Windows 7, 32-bit - can you help ?
On 3/16/2023 8:07 PM, a a wrote: Crash report: Problem Caption: Problem Event Name: APPCRASH Application name: python.exe Application version: 3.8.7150.1013 Application time signature: 5fe0df5a Error module name: _multiarray_umath.cp38-win32.pyd Version of the module with the error:0.0.0.0 Time signature of the module with the error: 63dfe4cf Exception code: c01d Exception offset:000269c9 Operating system version:6.1.7601.2.1.0.256.48 Regional Settings ID:1045 Additional information 1: 0a9e Additional information 2: 0a9e372d3b4ad19135b953a78882e789 Additional information 3: 0a9e Additional information 4: 0a9e372d3b4ad19135b953a78882e789 This exception has been reported to have many causes, but one possibility seems to be that your computer may not support an advanced instruction set that the .pyd was compiled for. I found this one specifically mentioned on the Internet: Advanced Vector Extensions. If that were the case, you would either need to find a different version of the module, or upgrade the computer/OS. It would be worth trying to downgrade the multiarray version to an earlier one and see if that fixes the problem. -- https://mail.python.org/mailman/listinfo/python-list
Fwd: Friday finking: IDE 'macro expansions'
Oops! I meant to send this to the group not just Dave. Forwarded Message On 16/03/2023 22:55, dn via Python-list wrote: > Do you make use of your IDE's expansionist tendencies, and if-so, which > ones? When I'm writing Java/C++/C# yes, I need all the IDE help I can get. Netbeans or Eclipse being my tools of choice. And in my Windows days I used Delphi and Smalltalk/V which both pretty much only exist within their own IDEs and I used their features extensively. When writing Python I use IDLE, or vim for bigger jobs. IDLE does have some suggestions and auto tricks but I don't always use them. In vim I use auto-indent and that's about it. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Friday finking: IDE 'macro expansions'
On 3/17/2023 1:13 PM, Alan Gauld wrote: Oops! I meant to send this to the group not just Dave. Forwarded Message On 16/03/2023 22:55, dn via Python-list wrote: Do you make use of your IDE's expansionist tendencies, and if-so, which ones? When I'm writing Java/C++/C# yes, I need all the IDE help I can get. Netbeans or Eclipse being my tools of choice. And in my Windows days I used Delphi and Smalltalk/V which both pretty much only exist within their own IDEs and I used their features extensively. Back when Delphi first came out, when I first used it, I don't remember any IDE; one just used a text editor. When writing Python I use IDLE, or vim for bigger jobs. IDLE does have some suggestions and auto tricks but I don't always use them. In vim I use auto-indent and that's about it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Friday finking: IDE 'macro expansions'
On 2023-03-17 17:55, Thomas Passin wrote: On 3/17/2023 1:13 PM, Alan Gauld wrote: Oops! I meant to send this to the group not just Dave. Forwarded Message On 16/03/2023 22:55, dn via Python-list wrote: Do you make use of your IDE's expansionist tendencies, and if-so, which ones? When I'm writing Java/C++/C# yes, I need all the IDE help I can get. Netbeans or Eclipse being my tools of choice. And in my Windows days I used Delphi and Smalltalk/V which both pretty much only exist within their own IDEs and I used their features extensively. Back when Delphi first came out, when I first used it, I don't remember any IDE; one just used a text editor. I used Turbo Pascal and then Delphi 3 or 4, back when it was still Borland. When writing Python I use IDLE, or vim for bigger jobs. IDLE does have some suggestions and auto tricks but I don't always use them. In vim I use auto-indent and that's about it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday finking: IDE 'macro expansions'
On 18/03/2023 02.44, Thomas Passin wrote: On 3/17/2023 9:38 AM, Simon Ward wrote: On Fri, Mar 17, 2023 at 02:05:50PM +0100, Roel Schroeven wrote: Even better than simply highlighting is (IMO) a thing called "Rainbow Braces" or "Bracket Pair Colorization" I recently learned about: both braces of a matching pair get the same color, while other pairs get other colors. I have to say I like it quite a lot. It's in VS Code these days; possible there are implementations or extensions for other editors and IDEs as well. VS Code also supports ‘semantic highlighting’: Instead of simply highlighting syntax, highlight the same identifiers in the same colours, with the aim of helping you see them through the flow of the code. Even with a simple "Find" command I don't like that behavior, let alone for programming. I find that all those other marked instances make it harder for me to read the surrounding material. They are good for moving from one instance to another, but otherwise they get in the way for me. Haven't seen the coloring feature as-described. As the number of identifiers increased, suspect it would become gaudy or the color shading too subtle for my eyes. +1 'Busy pictures' can be distracting. That said, the syntax-highlighting can provide the occasional cue that something has gone-wrong. However, will I recognise it from the mis-coloring, or from other evidence first? The semantic point might be easily under-estimated. A 'simple find' may not be helpful - a web-search for Python turns-up irrelevant information about snakes! Regarding the tracing of an identifier: PyCharm has two features: - with cursor/caret on/at a single use of an identifier, it will highlight other usage, elsewhere in that module's code - (context menu) FindUsages will bring-up a two-pane window. The left-pane shows a tree-structure of the project, modules, etc, down to a listing of each code-line where the identifier is used. Highlighting one of those (at a time), will show the context around that particular line/usage. The right-pane is editable! The great thing about these features is that they are semantically-aware (is that a real term?). For example, if I were (foolish enough) to name an identifier "the", such searches will not 'hit' the same word inside a comment or docstring. Better still, the above motivation continues into a (context menu) Refactor facility. This, one might consider to be a semantic Find-Replace. Often employ when helping others to clarify their code/Code Review - or when I'm 'just coding' and have quickly defined an identifier without a lot of thought, but later (ie when come to make use of it) realise a better alternative and more descriptive name. -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Tkinter and cv2: "not responding" popup when imshow launched from tk app
On Thu, 2023-03-16 at 04:21 -0400, aapost wrote:
> On 3/15/23 07:37, John O'Hagan wrote:
> > On Tue, 2023-03-14 at 16:22 -0400, aapost wrote:
> > > On 3/14/23 06:54, John O'Hagan wrote:
> >
> > [...]
> > > >
>
>
> Read an alternative description of the waitKey behavior
>
> >For example, waitKey(0) will display the window infinitely until
> any
> keypress (it is suitable for image display). waitKey(25) will display
> a
> frame and wait approximately 25 ms for a key press (suitable for
> displaying a video frame-by-frame). To remove the window, use
> cv::destroyWindow.
>
> I went back to double check and I stand corrected on the "any
> keypress"
> part. Any keypress on the 'keyboard' does break the wait (as I
> incorrectly concluded and assumed only ESC did).
>
> It is still slightly ambiguous in explaining that when using 25ms,
> keypress or not, the wait breaks at 25ms (or before that if you press
> a
> keyboard key). For my setup the window is stale at that point, no
> controls, just a stale frame behind the tkinter window that needs to
> be
> destroyed or reused.
>
> Whether that is the exact behavior on all set-ups isn't clear, the
> note
> further uses the ambiguous phrasing "might".
>
> >Note: This function should be followed by a call to cv::waitKey or
> cv::pollKey to perform GUI housekeeping tasks that are necessary to
> actually show the given image and make the window respond to mouse
> and
> keyboard events. Otherwise, it won’t display the image and the window
> might lock up.
>
> It seems with the several variations, behavior varies between them,
> like
> one comment saying startWindowThread when using c++ and gtk allows
> you
> to not use waitKey (not the case here.. it seems -- changing my
> language
> to not misspeak, lol).
>
> I haven't come across any examples beyond imshow running stand-alone
> as
> in my solution suggestion 2. But waitKey does return a keyvalue for
> the
> keypess to allow extending the functionality, so you can grab it, do
> something, and go right back to waiting, I haven't seen any use of
> this
> though.
>
> You can also leave out reference to tkinter all together when using
> startWindowThread:
>
> import sys
> import cv2
>
> cv2.startWindowThread()
> cv2.namedWindow("W", cv2.WND_PROP_FULLSCREEN)
> cv2.setWindowProperty("W", cv2.WND_PROP_FULLSCREEN,
> cv2.WINDOW_FULLSCREEN)
> cv2.imshow("W", cv2.imread(sys.argv[1]))
> while(1):
> a = cv2.waitKey(0)
> if a == 27:#ESC
> break
> #elif a == something else, do something
> cv2.destroyAllWindows()
> exit()
>
> But it still blocks if integrated in to the main tkinter thread, and
> appears to use tkinter under the hood. And as tkinter is considered
> thread-unsafe, the startWindowThread would only be ok when spawned as
> a
> separate process like the subprocess example.
>
Thanks for this and your other detailed replies, which I won't go into
because your comment above led me to a simple workaround using
threading, with a caveat.
This may be controversial, but AIUI it's fine to use threads in tkinter
as long as you don't touch the same widget from different threads. I do
it all the time! So I tried opening and waiting for the window in a
thread like this:
def window_thread():
cv2.namedWindow('W', cv2.WND_PROP_FULLSCREEN)
cv2.setWindowProperty('W', cv2.WND_PROP_FULLSCREEN,
cv2.WINDOW_FULLSCREEN)
cv2.waitKey(0)
threading.Thread(target=window_thread, daemon=True).start()
This works - the images can be displayed by calling imshow() via
tkinter buttons in the main thread, and all the cv2 panning and zooming
works too.
But the fly in the ointment is that any keypress while the focus is on
the cv2 window exits the thread. I think this would apply to your
subprocess example too.
I tried:
- putting the waitKey call in a while loop as in your example above,
hoping it would just keep waiting, but the second call to waitKey
doesn't respond to keypresses
- putting the whole window_thread code in a while loop with a call to
destroyAllWindows, hoping that this would re-create the window, but it
doesn't
- restarting the window thread after waitKey, which has the same
results as above and
- using a new name for the namedWindow each time
In all cases, any subsequent calls to imshow block. I have no idea
why.
For now it looks like I'll have to tell my users not to touch the
keyboard while the image is in focus! Not ideal.
If there is another nice fast pythonic way to display an image from a
very large array _programatically_, I'd love to know about it.
--
John
--
https://mail.python.org/mailman/listinfo/python-list
