Hi Thomas,
Yep, dockering or AWSing a bunch of test cases was kind of what I was
thinking - I just didn't want to waste the time if the approach wasn't on
the right path :)
Regarding platform.system() - according to the documentation, yes, they are
standardized. Looking at their source code, plat
The pastebin version looks reasonable. I don't have a problem with the
dictionary mapping to an appropriate function, provided that the OS names
have been standardized. Have they?
Definitely needs to be tested. The easiest is to set up a bunch of VMs (or
Docker boxes) on your development machine a
Hi,
So firstly, I know it's been mentioned before and there's a reluctance to
add dependencies on external modules for this, but there do appear to be
some that would be very useful and give broad support for OS uptime
reporting, eg:
https://pypi.org/project/uptime/
That said, if we want a de
I agree: stacks and stacks of try / except statements can lead to indent
hell.
One way to cut that down is to use functions. Each function would try /
except a set of related operating systems, and if none of them work, raise
NotImplementedError. The main function would then just have to catch
Not
That is a good point, and it doesn’t look from that code as though windows is
currently supported. I might take a look at writing something that does switch
on OS with differing strategies. I kind of don’t like that approach in general
(because it feels like the ‘ol “version check” in windows wh
On Thursday, April 11, 2019 at 5:23:58 PM UTC-4, Jon Marnock wrote:
>
> Would it be better to just use something more generic like uptime(1) and
> parse the output?
>
>
pure python would be preferable to calling out to a system utility.
remember that weewx runs on windows too.
I recall when I was running FreeBSD 11, the patch I provided worked.
It does work fine under FreeBSD12 and weewx-3.9.1
Server uptime 21 days, 17 hours, 26 minutes
WeeWX uptime
0 days, 15 hours, 0 minutes
On Thursday, April 11, 2019 at 2:23:58 PM UTC-7, Jon Marnock wrote:
>
> Would it b
>
> Would it be better to just use something more generic like uptime(1) and
> parse the output?
>
A PR is welcome. 😀
Would it be better to just use something more generic like uptime(1) and
parse the output?
Jon
On Fri, 12 Apr 2019 at 12:16 am, Greg Troxel wrote:
> I meant to get the os name and switch on that, and only try methods
> appropriate for that os.
>
--
___
Jon Marnock
jon.klo...@gm
I meant to get the os name and switch on that, and only try methods appropriate
for that os.
>
> Overall, I would want to replace the try/except/try notion with a switch
> on os type and helper functions for groups of systems that have common
> behavior. That's perhaps a bias on my part not to use exceptions for
> things that could avoid them, and partly because this seems to be
> gettin
Jon Marnock writes:
> I know this is an ancient thread, but I just got weewx up and running on
> OpenBSD and found the FreeBSD kern.boottime thing didn't work for system
> uptime because the sysctlbyname doesn't exist there.
The try block that has a comment about FreeBSD works on NetBSD also,
Hi,
I know this is an ancient thread, but I just got weewx up and running on
OpenBSD and found the FreeBSD kern.boottime thing didn't work for system
uptime because the sysctlbyname doesn't exist there.
I've never programmed in python before, so I'm sure this is horrible, but
following the exa
Learning about pull requests.
The second one is the simpler version using sysctl kern.bootime. I think
this is easier than pulling uptime, using a regex to convert to a float.
As well as reordering to make the order Linux, FreeBSD, MacOS.
I'd still like to see setup.py pick from one of th
That indentation is what makes my brain hurt. I now use vim with the
python plugin. Not clear why the diff isn't working, hence the attachment
which is the running code on my FreeBSD 11 box.
I assumed, it would fail to import ctype on a non-FreeBSD box and the next
test, assuming Linux would
The port is where packages from FreeBSD come from. I saw this too, someone
is working on a package/port but it's not been released yet.
# grep "*weewx*" INDEX-11
#
Didn't see weewx in /usr/ports/astro either.
I also pondered reading kern.boottime: { sec = 1481505110, usec = 141127 }
Sun Dec 1
bill,
i'm not sure what you mean by 'port', but i'm pretty sure there is a weewx
port (i.e., package) for freebsd:
https://reviews.freebsd.org/D6324
the cmon extension has to deal with many platform-specific operations. at
first i wrote it using /sys and /proc, but then i discovered the pytho
Hello, Bill
Unfortunately, I could not get your code to work.
It has an indentation error, line 131.
Your code tries importing ctypes. Because ctypes is part of the Python
standard library, this always succeeds. Unfortunately, for non-BSD systems,
this logic branch leaves dylib undefined.
I'm
I looked at the documentation again and providing patches was a topic I
didn't have success locating. Google had the send a diff to the mailing
list for review but that was vintage 2012. If could expand a bit on how to
make a pull request? My SVN repo isn't public. But I can attach the file
19 matches
Mail list logo
