similar to: PSA: Parallel STL algorithms available in LLVM

It's hard to say. By definition it appears undefined (in the sense that the TS literally does not define it), but on the other hand it is a TS and this issue would (hopefully) come up and be specified before it made it to standardization. Supporting recursive parallel calls certainly seems like desirable behavior, so from my point of view it would be nice to make sure it works. Not sure if

On May 10, 2017 9:14 PM, "Hal Finkel" <hfinkel at anl.gov> wrote: On 05/10/2017 10:36 PM, Zachary Turner via llvm-dev wrote: It's hard to say. By definition it appears undefined (in the sense that the TS literally does not define it), but on the other hand it is a TS and this issue would (hopefully) come up and be specified before it made it to standardization. You mean

On Fri, May 12, 2017 at 12:52 AM, Bryce Lelbach <balelbach at lbl.gov> wrote: > * I am concerned that nested parallel algorithms will prove to be a > big implementation burden for GPU and accelerator architectures. > Can't they fall back on serial execution? I thought the executor is a hint, not a requirement (certainly the standard doesn't say it has to execute on

Even without a concrete use case, I agree that it's absolutely imperative for the standard to require this of a conforming implementation. It's going to be the source of so many problems otherwise On Fri, May 12, 2017 at 9:14 AM Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/12/2017 11:00 AM, Scott Smith wrote: > > On Fri, May 12, 2017 at 12:52 AM, Bryce Lelbach

Yes, I would hate for some library implementer to either interpret the standard differently or simply not consider the issue of recursive parallelism at all and end up with an implementation that doesn't support it (not that unlikely considering it went 1.5 years through committee as you said and the topic never came up). On Wed, May 17, 2017 at 7:25 AM Bryce Lelbach <balelbach at

Hi all, There are currently a number of ways to extend RSpec that are documented inconsistently and work in sometimes conflicting and/or confusing ways. I''d like to resolve that. The recent addition of Spec::Runner.configure is part of that resolution. The thing I want to tackle now is the stuff that happens before and after each example. Currently (in trunk), things are executed in the

Hello The page https://networkupstools.org/ddl/Liebert/PSA_1500.html don't contain all information about UPS series PSA. First, the variable "*device.serial*" is dummy, it is always empty , and "*ups.serial*" also always empty. Second, configuration file for the all UPS "PSA" contain these lines: [PSA] ??? driver = "usbhid-ups" ?? ?port =

Likely because 2.6.3 is not a current release. 2.7.2 (or 3?) is rhe current version, and it makes little sense to backport changes. Nut is a trivial compile . . . 'Use the source, Luke . . .' - Tim On October 17, 2014 6:05:35 PM CDT, Derek Harding <derek at lagham.org.uk> wrote: >Hi, > >Back in 2011, it was reported that Liebert PSA devices persist in >reporting OB

[FAQ on USB-connected UPSes] > Remember: this is brand new *experimental* software and is probably > very broken. Do us a favor and report successes or failures to > the mailing lists. No problem ... : UPS: Liebert PowerSure PSA 500 NUT: Version 2.0.2 Kernel: 2.6.11.5, with CONFIG_USB_HID, CONFIG_USB_HIDINPUT, and CONFIG_USB_HIDDEV compiled in (statically)

Hi, Back in 2011, it was reported that Liebert PSA devices persist in reporting OB (On Battery) when using usbhid-ups regardless of the actual state. Pier Paolo did some work (2011) which reportedly solved the issue. However, that doesn't seem to have reached mainstream and I now face the same problem. I'm using NUT 2.6.3 with a new Liebert PSA 1500Va that only ever reports OB and

Anyone have any advice what I need to do next? Regards, Paul. -----Original Message----- From: Nut-upsuser [mailto:nut-upsuser-bounces+paul=smithp.co.uk at lists.alioth.debian.org] On Behalf Of Charles Lepple Sent: 02 August 2013 11:36 To: nut-upsuser list Subject: [Nut-upsuser] Fwd: Liebert PSA UPS problem. Begin forwarded message: > From: "Paul Smith" > Subject: Liebert PSA

This patch adds support for the following ups to liebert-hid.c: $ lsusb | grep Liebert Bus 007 Device 005: ID 10af:0001 Liebert Corp. PowerSure PSA UPS Using this patch, I'm able to obtain information about the ups via upsc: $ upsc upsname battery.charge: 100 battery.runtime: 1012 battery.type: PbAc battery.voltage: 1172 battery.voltage.nominal: 12 driver.name: usbhid-ups

I guess it's kind of a natural response on my part, working professionally in software. T-Shooting step one: Get current and see if the problem persists. If it does,then step rwo: debug. 2+ years is forever in software, noting that 2.6.3 was mid 2012 . . . - Tim On October 17, 2014 9:38:15 PM CDT, Charles Lepple <clepple at gmail.com> wrote: >On Oct 17, 2014, at 8:31 PM, Tim Dawson

Begin forwarded message: > From: "Paul Smith" > Subject: Liebert PSA UPS problem. > Date: July 31, 2013 4:42:33 PM EDT > To: <nut-upsuser at lists.alioth.debian.org> > > Hi all, > A brief summary: > > I have a new Liebert PSA UPS which I wanted to help support my FreeNAS box (a FreeBSD 8 variant). Unfortunately the nut-ups implementation here for

Hi all, several bots are currently experiencing an svn tree conflict when updating Updating '.': Skipped 'utils/lit/lit/llvm' -- Node remains in conflict Skipped 'utils/lit/lit/llvm' -- Node remains in conflict U utils/lit/lit/TestRunner.py U utils/lit/lit/util.py U test/lit.cfg U test/lit.site.cfg.in U cmake/modules/AddLLVM.cmake Updated to revision 313467. Summary of

Jochen Bern wrote: > > Peter Selinger wrote: > > have you been able to get your Liebert UPS to work? If I am correct, > > it should work with the newhidups Belkin subdriver. Could you please > > post your results? I am curious to know if this works or doesn't - and > > if yes, we should add permanent support for Liebert into NUT. > > I'm sorry, but

This is the last post in the old thread: http://lists.alioth.debian.org/pipermail/nut-upsuser/2011-February/006651.html I'm marginally reluctant to install a non-standard release on a customer server because I may not be the next person to have to work on it, however, I do agree the most recent is usually the first port-of-call. Since it seems the fix didn't get followed through,

http://netsystemsresearch.com/ dovecot.log.1.bz2:Jan 05 17:28:15 pop3-login: Info: Disconnected (no auth attempts in 3 secs): user=<>, rip=169.54.233.124, lip=MYIP, TLS handshaking: Disconnected, session=<z/L0OVxFetOpNul8> Their "research" pokes your email ports. Block if you want or participate in the (cough cough) research. IP addresses and opt-out email address on

I downloaded latest source and it compiles ok but the original usbhid-ups.c is unchanged. Pier changed other files, too, and I don't know the changes needed. Simply substituting the modified (as per 2011) usbhid-ups gives a failed connection to the ups. So I have tried a little. I'll uninstall 2.6.3 and try to install 2.7.2 from a fresh compile. Thanks for the responses so far :-) --

Hi all, There's a good chance that the people who most need to see this won't see it, but here goes anyway. Google is currently dropping a _lot_ of the mail we attempt to deliver to lists.fd.o subscribers. The immediate cause is sending on mail from domains with SPF/DKIM/DMARC policies which explicitly specify that lists.fd.o cannot relay mail on their behalf. Every time we do that, not