similar to: Nut Server error

Good Evening, I recently purchased an EPYC quantum UPS. I installed NUT on the home assistant by connecting the UPS via USB and tried all the various drivers in the list, the only one that seems to work is: usbhid-ups with this log: s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service base-addon-banner: starting

Hi Charles, Thanks for the prompt reply! Errors occur when execute make: /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../include -MT nutclient.lo -MD -MP -MF $depbase.Tpo -c -o nutclient.lo nutclient.cpp &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../include -MT nutclient.lo -MD -MP -MF .deps/nutclient.Tpo -c

Hi Charles, Yes, it looks like my g++ does contain STL library which might be just my specific case... However, as a temporary solution I disabled nutclient in Makefile (please find the file attached). And nut-2.7.3 can be compiled now. Thanks, Sergey On Wed, Jul 8, 2015 at 4:13 AM, Charles Lepple <clepple at gmail.com> wrote: > On Jul 6, 2015, at 10:32 AM, Sergey Talchuk

On Jul 6, 2015, at 10:32 AM, Sergey Talchuk <tals1975 at gmail.com> wrote: > /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../include -MT nutclient.lo -MD -MP -MF $depbase.Tpo -c -o nutclient.lo nutclient.cpp &&\ > mv -f $depbase.Tpo $depbase.Plo > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../include -MT nutclient.lo -MD -MP -MF

On Sep 1, 2015, at 4:26 AM, Paul Vermeer <paul at elspaulnz.com> wrote: > > Hi nut users, (this is a re-send from the correct account) > > With pleasure, I have been using the code provided. Managed to get all working properly, except for the nutclient lib in C. As you have noticed, nutclient has a few rough edges. The original upsclient library has had a lot more testing,

Hi Linfeng, On 06/02/17 02:51 PM, Linfeng Zhang wrote: > However, the critical thing is that all the states in each stage when > processing input[i] are reused by the next input[i+1]. That is > input[i+1] must wait input[i] for 1 stage, and input[i+2] must wait > input[i+1] for 1 stage, etc. That is indeed the tricky part... and the one I think you could do slightly differently. If

Hi Linfeng, On 06/02/17 07:18 PM, Linfeng Zhang wrote: > This is a great idea. But the order (psEncC->shapingLPCOrder) can be > configured to 12, 14, 16, 20 and 24 according to complexity parameter. > > It's hard to get a universal function to handle all these orders > efficiently. Any suggestions? I can think of two ways of handling larger orders. The obvious one is

Hi Jean-Marc, Attached is the silk_warped_autocorrelation_FIX_neon() which implements your idea. Speed improvement vs the previous optimization: Complexity 0-4: Doesn't call this function. Complexity 5: 2.1% (order = 16) Complexity 6: 1.0% (order = 20) Complexity 8: 0.1% (order = 24) Complexity 10: 0.1% (order = 24) Code size of silk_warped_autocorrelation_FIX_neon() changes from 2,644

Hi Linfeng, Thanks for the updated patch. I'll have a look and get back to you. When you report speedup percentages, is that relative to the entire encoder or relative to just that function in C? Also, what's the speedup compared to master? Cheers, Jean-Marc On 05/04/17 12:14 PM, Linfeng Zhang wrote: > I attached a new patch with small cleanup (disassembly is identical as > the

This is a great idea. But the order (psEncC->shapingLPCOrder) can be configured to 12, 14, 16, 20 and 24 according to complexity parameter. It's hard to get a universal function to handle all these orders efficiently. Any suggestions? Thanks, Linfeng On Mon, Feb 6, 2017 at 12:40 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Linfeng, > > On 06/02/17 02:51 PM,

Hi Linfeng, I had a closer look at your patch and the code looks good -- and slightly simpler than I had anticipated, so that's good. I did some profiling on a Cortex A57 and I've been seeing slightly less improvement than you're reporting, more like 3.5% at complexity 8. It appears that the warped autocorrelation function itself is only faster by a factor of about 1.35. That's a

Hi Jean-Marc, Thanks a lot for reviewing this huge assembly function! silk_warped_autocorrelation_FIX_c()'s kernel part is for( n = 0; n < length; n++ ) { tmp1_QS = silk_LSHIFT32( (opus_int32)input[ n ], QS ); /* Loop over allpass sections */ for( i = 0; i < order; i++ ) { /* Output of allpass section */ tmp2_QS = silk_SMLAWB(

https://bugzilla.mindrot.org/show_bug.cgi?id=2231 Bug ID: 2231 Summary: Use EVP_Digest for oneshot digest calculation Product: Portable OpenSSH Version: 6.6p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: Miscellaneous Assignee:

Hi nut users, (this is a re-send from the correct account) With pleasure, I have been using the code provided. Managed to get all working properly, except for the nutclient lib in C. Both functions stringset_to_strarr and stringvector_to_strarr have a similar bug in play. Although trivial in code, the coded function does not operate as intended. The pointer increment is missing (see added

The use of C++ has cropped up from time to time in the Github comments, and it really deserves its own thread. Background: https://github.com/networkupstools/nut/issues/102 From Arnaud: > @clepple : also a separate discussion, but quickly: c++ is more for devs than users. Though, by side effect, this will obviously benefit to the user, the point is to have better code (and coding) for some

I attached a new patch with small cleanup (disassembly is identical as the last patch). We have done the same internal testing as usual. Also, attached 2 failed temporary versions which try to reduce code size (just for code review reference purpose). The new patch of silk_warped_autocorrelation_FIX_neon() has a code size of 3,228 bytes (with gcc). smaller_slower.c has a code size of 2,304

Hi Jean-Marc, Thanks for your suggestions. Will get back to you once we have some updates. Linfeng On Mon, Feb 6, 2017 at 5:47 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Linfeng, > > On 06/02/17 07:18 PM, Linfeng Zhang wrote: > > This is a great idea. But the order (psEncC->shapingLPCOrder) can be > > configured to 12, 14, 16, 20 and 24 according to

Dear R users: I have some difficulties analizing data with mixed effects NLME and the last version of R. More concretely, I have a repeated measures design with a single group and 2 experimental factors (say A and B) and my interest is to compare additive and nonadditive models. suj rv A B 1 s1 4 a1 b1 2 s1 5 a1 b2 3 s1 7 a1 b3 4 s1 1 a2

Thank Jean-Marc! The speedup percentages are all relative to the entire encoder. Comparing to master, this optimization patch speeds up fixed-point SILK encoder on NEON as following: Complexity 5: 6.1% Complexity 6: 5.8% Complexity 8: 5.5% Complexity 10: 4.0% when testing on an Acer Chromebook, ARMv7 Processor rev 3 (v7l), CPU max MHz: 2116.5 Thanks, Linfeng On Wed, Apr 5, 2017 at 11:02 AM,

Dear all, I did post this more or less identical mail in a follow up to another question I posted, but under another heading. I try again, but now under the correct header. upon running this code (from the Hmisc library-latex function) I believe the call to summary.formula is allright and produces wonderful tables, but the latex command results in a correct formatted table but where all the