Re: compile error building building Python-3.8.5 on Debian 8.11 (yes, old!)
On 04Sep2020 15:54, Chris Angelico wrote: >On Fri, Sep 4, 2020 at 3:01 PM Cameron Simpson wrote: >> I've built 3.8.5 on a few other machines happily recently. >Those are warnings; if there are errors that block compilation, they >aren't in what you quoted above. Yes, that's what I thought. And yet it failed :-( And I just retried and now it's good. That is just.. weird. And I can't find the shell it failed in :-( Sorry to have bugged people. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Replacement for pygtk?
Grant Edwards wrote: > On 2020-09-03, Grant Edwards wrote: > > [...] > > > > Is pygobject the replacement for pygtk? > > It seems to be. I've started porting my pygtk app, and it's going > pretty smoothly. I've already got my two custom widgets working. > Oddly, the main module provided by the gobject package is called "gi". > I think the 'i' is for instrospection - GTK Introspection. FWIW I ported some Python 2 GTK code to Python 3 and it wasn't *too* painful. Run 2to3 on the code and then fix the odd syntax errors that remain. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Re: Regex to change multiple lines
Il 03/09/20 22:16, Chris Angelico ha scritto: Hmm. Have you considered using CSS to do this? Markdown is generally fairly easy to style with CSS. Yes, infact these are files where I'll insert a tag (in the example , to show the errors find at a second revision due they are of another kind, but then something like ", with inline css declaration at the beginning of the file to not confuse the guy, a teacher friend of mine, that will use this application). -- https://mail.python.org/mailman/listinfo/python-list
Re: compile error building building Python-3.8.5 on Debian 8.11 (yes, old!)
On Thursday, September 3, 2020 8:59:09 PM AKDT Cameron Simpson wrote: > I've built 3.8.5 on a few other machines happily recently. > > Building Python 3.8.5, running make and gcc (Debian 4.9.2-10+deb8u2) > 4.9.2 I get this: I am going to assume the version of C required is past what is in that old of a version of Debian. I don't see anything that calls out the C version required in the Python docs, but I doubt they have Debian 8 in their build farm any more. j -- Joshua J. Kugler - Fairbanks, Alaska - jos...@azariah.com Azariah Enterprises - Programming and Website Design PGP Key: http://pgp.mit.edu/ ID 0x68108cbb73b13b6a -- https://mail.python.org/mailman/listinfo/python-list
Re: compile error building building Python-3.8.5 on Debian 8.11 (yes, old!)
On Sat, Sep 5, 2020 at 2:06 AM Joshua J. Kugler wrote: > > On Thursday, September 3, 2020 8:59:09 PM AKDT Cameron Simpson wrote: > > I've built 3.8.5 on a few other machines happily recently. > > > > Building Python 3.8.5, running make and gcc (Debian 4.9.2-10+deb8u2) > > 4.9.2 I get this: > > I am going to assume the version of C required is past what is in that old of > a version of Debian. I don't see anything that calls out the C version > required in the Python docs, but I doubt they have Debian 8 in their build > farm any more. > You'd be surprised :) There is, in fact, a Debian 8.9 system in the build farm. I know, because I maintain it. (It's a VM underneath my live system which is Debian 9.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: compile error building building Python-3.8.5 on Debian 8.11 (yes, old!)
On Fri, Sep 04, 2020 at 08:04:33AM -0800, Joshua J. Kugler wrote:
> On Thursday, September 3, 2020 8:59:09 PM AKDT Cameron Simpson wrote:
> > I've built 3.8.5 on a few other machines happily recently.
> >
> > Building Python 3.8.5, running make and gcc (Debian 4.9.2-10+deb8u2)
> > 4.9.2 I get this:
>
> I am going to assume the version of C required is past what is in that old of
> a version of Debian.
No... even the latest versions of GCC will let you use the oldest C
standards ("version") by using the -cstd flag, and that flag is set
(to c99) on the command line. So unless that's just the wrong
version, that's definitely not the problem. There's also nothing
to suggest that there's a syntax problem in the output Cameron pasted
(it only describes a *usage* problem). An obsolete library would be
more likely, but there's nothing in the provided output to suggest
that either.
It appears to me thatthe output that Cameron pasted is missing the
context that would tell you what the problem is. Usually GCC gives an
additional error right before compilation stops that gives a sort of
summarized description of the reason compilation failed. There's none
present in what Cameron provided.
But I will also note the -Werror= flag on the compile line, which
turns warnings into errors... but I'm too lazy to look up whether the
specified option affects the mentioned bounds checking (seems like it
wouldn't, but there's no guarantee the bounds checking behavior isn't
also implied by that option, without specific knowledge of that
compiler behavior, which I lack). If that were the case, FWIW, GCC
would usually emit an additional error to the effect of "warnings
being treated as errors."
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: compile error building building Python-3.8.5 on Debian 8.11 (yes, old!)
On Fri, Sep 04, 2020 at 03:43:14PM -0500, Python wrote:
> On Fri, Sep 04, 2020 at 08:04:33AM -0800, Joshua J. Kugler wrote:
> > On Thursday, September 3, 2020 8:59:09 PM AKDT Cameron Simpson wrote:
> > > Building Python 3.8.5, running make and gcc (Debian 4.9.2-10+deb8u2)
> > > 4.9.2 I get this:
> >
> > I am going to assume the version of C required is past what is in that old
> > of
> > a version of Debian.
>
> No... even the latest versions of GCC will let you use the oldest C
> standards ("version") by using the -cstd flag, and that flag is set
Typo: it's just -std.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Replacement for pygtk?
On 2020-09-04, Chris Green wrote: > Grant Edwards wrote: >> On 2020-09-03, Grant Edwards wrote: >> > [...] >> > >> > Is pygobject the replacement for pygtk? >> >> It seems to be. I've started porting my pygtk app, and it's going >> pretty smoothly. I've already got my two custom widgets working. >> Oddly, the main module provided by the gobject package is called "gi". >> > I think the 'i' is for instrospection - GTK Introspection. > > FWIW I ported some Python 2 GTK code to Python 3 and it wasn't *too* > painful. Run 2to3 on the code and then fix the odd syntax errors that > remain. The 2 -> 3 part is usually trivial except for bytes. I work a lot with raw data from serial ports and network sockets, and trying to write programs that worked in both py2 and py3 was painful. I've started to abandon py2 support, and that makes it a lot easier. The only part of the gtk code that didn't translate directly (or almost so) was some pixbuf stuff. I'm still trying to figure out to "freeze" the size of a button so that when I change its contained label text on-the-fly it doesn't resize and shift everying else slightly. I don't remember that happening with gtk2 (which I can no longer run), but I've no idea why... -- Grant -- https://mail.python.org/mailman/listinfo/python-list
How can I use Haar cascade for face detection and kalman filter for tracking?
I am new to computer vision and I am trying to use haar cascade for face
detection and kalman filtering for tracking I intend to run the code on
raspberry pi 3B. Hence cannot use any deep learning methods for tracking. How
can I use cv2.kalmanfilter()
(https://docs.opencv.org/trunk/dd/d6a/classcv_1_1KalmanFilter.html) in my code
to do the tracking and draw a line for the traversal path? It would be great
help if any one can guide me for it
My code is :
from __future__ import print_function
import numpy as np
import cv2
from imutils.video import WebcamVideoStream
from imutils.video import FPS
import argparse
import imutils
import cv2
faceCascade = cv2.CascadeClassifier('haarcascade_frontalface_default.xml')
#faceCascade = cv2.CascadeClassifier('haarcascade_profileface.xml')
fps = FPS().start()
cap = cv2.VideoCapture(0)
cap.set(3,640) # set Width
cap.set(4,480) # set Height
while True:
ret, img = cap.read()
#img = cv2.flip(img, -1)
gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)
faces = faceCascade.detectMultiScale(
gray,
scaleFactor=1.2,
minNeighbors=5,
minSize=(20, 20)
)
for (x,y,w,h) in faces:
cv2.rectangle(img,(x,y),(x+w,y+h),(255,0,0),2)
roi_gray = gray[y:y+h, x:x+w]
roi_color = img[y:y+h, x:x+w]
cv2.imshow('video',img)
fps.update()
k = cv2.waitKey(30) & 0xff
if k == 27: # press 'ESC' to quit
break
fps.stop()
print("[INFO] approx. FPS: {:.2f}".format(fps.fps()))
cap.release()
cv2.destroyAllWindows()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Replacement for pygtk?
On 2020-09-03, Michael Torrie wrote: > On 9/3/20 1:17 PM, Grant Edwards wrote: >> On 2020-09-03, Grant Edwards wrote: >>> [...] >>> >>> Is pygobject the replacement for pygtk? >> >> It seems to be. I've started porting my pygtk app, and it's going >> pretty smoothly. I've already got my two custom widgets working. >> Oddly, the main module provided by the gobject package is called "gi". > > It stands for "gobject introspection." That's what I (later) suspected. > The nice thing about the gi module is it can wrap any gobject-based > library, not just GTK+ proper. So if someone made a custom widget > in Vala, for example, you could access it via gi. It's a neat > idea. My only problem with it is the resulting Python API is not > always as pythonic as pygtk code was. I noticed that right away. In pygtk, most methods (e.g. .pack_start) had named arguments with well chosen defaults. The vast majority of the time, I only supplied one argument for the pack_start() call. With gi's implementation of pack_start, there are no named parameters: they're all positional. You have to specify all four of them every time, even if the last three are False,False,0 95% of the time. And the lack of names makes it impossible to figure out from reading the application source code what those last three actually mean. [The first argument is obvious in context.] I assume that difference is because pygtk was hand-written and gi is built auto-magically using SWIG or something like that? > I can't think of any specific examples at the moment, however. It's > pretty much good enough to not care too much. For native Linux apps I definitely prefer Gtk. The other choices are * WxPython - It's bigger and far more complex than pygtk/gi and the extra complexity doesn't ever seem to buy me anything except MS-Windows compatibility [which did matter for a few of the apps I used to maintain]. The last time I looked into Gtk on Windows, it didn't sound usable, but that was many years ago. * PyQt -- I run Gtk-centric Linux systems, and the second you try to use one Qt widget, it always seems to pull in hundreds of packages that take a week to build. * Tkinter -- It's ugly on Linux (yea, I know there are supposed to be ways to fix that, but they never seem to work for me). All of the tkinter apps I maintain all seem to have one or two widgets with behavior that's counter-intuitive. When you bundle a trivial tkinter app (e.g. with cx-freeze), it ends up huge unless you put in a great deal of work manually excluding stuff you don't need. Back when there was a gtk version of Wireshark, I usually didn't have any Qt stuff installed at all. I'm still trying to get _that_ knife pulled out of my back. How dare somebody give me (for free) something tremendously valuable and useful in a slightly different flavor than I would prefer. ;) > Similar arguments can be made against PyQt as well. Especially with > PyQt the end result feels a bit like writing C++ with a python > syntax. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
