search for: hardwired

For some awful reason (can someone explain why?), the RHEL/CentOS build of firefox is hardwired to use evolution as its mailto client. With FF 2.<mumble> this was fixable with an about:config setting. With 3.0.<mumble>, it seems not. What is the proper way of fixing this? *I* ended up doing a 'sudo rpm -e evolution' and then doing a 'sudo ln -s <myfirefoxmailto...

...efix=/usr/share/jon --with-xauth=/usr/openwin/bin/xauth --with-ipv4-default --with-tcp-wrappers --with-pid-dir=/etc --sysconfdir=/etc i use a prefix of /usr/share/jon , then build the system V package from there. most things work great, but somehow scp does not. it seems have the location of ssh hardwired into it. root at barf:~# which scp /usr/local/bin/scp root at barf:~# strings `which scp` | grep ssh /usr/share/jon/bin/ssh usage: scp [-pqrvC46] [-S ssh] [-P port] [-c cipher] [-i identity] f1 f2; or: root at barf:~# root at barf:~# scp jon at example.com:~/file . /usr/share/jon/bin/ssh: No suc...

On 4/4/2019 2:21 AM, Peter Mogensen via dovecot wrote: > What's the recommended way to handling timeouts on large mailboxes given > the hardwired request timeout of 60s in solr-connection.c: > > http_set.request_timeout_msecs = 60*1000; I'm a denizen of the solr-user at lucene.apache.org mailing list. For a typical Solr index, 60 seconds is an eternity. Most people aim for query times of 100 milliseconds or less, and they...

Hi, What's the recommended way to handling timeouts on large mailboxes given the hardwired request timeout of 60s in solr-connection.c: http_set.request_timeout_msecs = 60*1000; /Peter

Hi All, Greg has been a huge help getting me going with this tellabs echo can, but I'm still having some problems getting it to work... I suspect I wired it up incorrectly, so I thought I'd see if anyone can point me in the right direction. Digium tech support pointed me to this doc for a standard T1 cable: http://www.arcelect.com/RJ48C_and_RJ48S_8_position_jack_.htm which looks like it

On 4/4/19 6:57 PM, Peter Mogensen wrote: > > > On 4/4/19 6:47 PM, dovecot-request at dovecot.org wrote: >> For a typical Solr index, 60 seconds is an eternity. Most people aim >> for query times of 100 milliseconds or less, and they often achieve >> that goal. > > I'm pretty sure I get these while indexing, not querying. > > Apr 04 16:44:50 host

On 12/04/2019 12:09, Peter Mogensen via dovecot wrote: > Looking further at tcpdumps of the Dovecot->Solr traffic and Solr > metrics it doesn't seem like there's anything suspicious apart from the > TCP windows running full and Dovecot backing of ... until it times out > and close the connection. > > From my understanding of how Dovecot operates towards Solr it will

On 14/04/2019 17:16, Peter Mogensen via dovecot wrote: > sorry... I got distracted half way and forgot to put a meaningfull > subject so the archive could figure out the thread. - resending. > > On 4/14/19 4:04 PM, dovecot-request at dovecot.org wrote: > >>> Solr ships with autoCommit set to 15 seconds and openSearcher set to >>> false on the autoCommit.? The

...{ > let GIZeroRegister = WZR; > } > With that definition, the tablegen-erated ISel code will try to replace will try to replace 'G_CONSTANT s32 0' with WZR whenever the operand is specified as GPR32z. > > > Is this method extensible to the case of other hardwired register values? Tracing through the code, I noticed that it seems to boil down to a GIR_CopyOrAddZeroReg opcode, which seems like a pretty deep embedding of the specialness of zero. At the moment, zero is hardwired since losing an AArch64 optimization was the motivating case behind adding it and...

...{ > let GIZeroRegister = WZR; > } > With that definition, the tablegen-erated ISel code will try to replace > will try to replace 'G_CONSTANT s32 0' with WZR whenever the operand is > specified as GPR32z. > Is this method extensible to the case of other hardwired register values? Tracing through the code, I noticed that it seems to boil down to a GIR_CopyOrAddZeroReg opcode, which seems like a pretty deep embedding of the specialness of zero. Also, IIUC, GPR32z is defining a special reg class that enables the zero-register transformation. Defining a new re...

> I'm a denizen of the solr-user at lucene.apache.org mailing list. > [...] > Here's a wiki page that I wrote about that topic. This wiki is going > away next month, but for now you can still access it: > > https://wiki.apache.org/solr/SolrPerformanceProblems That's a great resource, Shawn. I am about to put together a test case to provide a comprehensive FTS

On 4/4/19 6:47 PM, dovecot-request at dovecot.org wrote: > For a typical Solr index, 60 seconds is an eternity. Most people aim > for query times of 100 milliseconds or less, and they often achieve > that goal. I'm pretty sure I get these while indexing, not querying. Apr 04 16:44:50 host dovecot[114690]: indexer-worker(me at example.com): Error: fts_solr: Indexing failed: Request

There seems to be a slight issue with the instructions at the following wiki page: https://wiki.samba.org/index.php/Configure_DHCP_to_update_DNS_records_with_BIND9 The /usr/local/bin/dhcp-dyndns.sh script seems to use a hardwired value for the lease expiry time of 3600 - independent of whatever is configured in dhcpd.conf. With the examples provided, it should work, as the example dhcpd.conf uses 1800 for lease expiry time - so dhcpd will try to renew the lease before it actually expires. However, when I implemented th...

...before I issue the first "make" command, and then I have to edit (just) src/unix/Makefile again -- seems it gets remade at some point. (before configure) setenv AR_FLAGS '-X64 -v -q' did nothing adding Makeconf:AR_FLAGS = -X64 -q -v did nothing '$(AR) cr' hardwired in src/appl/Makefile '$(AR) cr' hardwired in src/nmath/Makefile '$(AR) cr' hardwired in src/unix/Makefile '$(AR) cr' hardwired in src/extra/bzip2/Makefile '$(AR) cr' hardwired in src/extra/pcre/Makefile '$(AR) cr' hardwired in src/extra/zlib/Makefile #------...

Looking further at tcpdumps of the Dovecot->Solr traffic and Solr metrics it doesn't seem like there's anything suspicious apart from the TCP windows running full and Dovecot backing of ... until it times out and close the connection. >From my understanding of how Dovecot operates towards Solr it will flush ~1000 documents towards Solr in /update request until it has traversed the

...ctionDAG at all? I would just materialize zero like any other constant, and treat replacing that with the zero register as an immediate folding optimization (e.g. FoldImmediate or another peephole pass) I thought about doing that, but I wasn't sure I could make it work. The issue is that the hardwired registers are actually the only way to write immediates of this register class (the registers are very small, obviously). I've been phrasing this as integer 0 (and -1) to keep the discussion closer to other architectures, but the fact that these hardwired registers are the only way to reference...

I've been googling, but haven't come up with a satisfactory answer to the question of how I permanently turn off wifi on a workstation or server (which are *all* hardwired). I see I can turn wifi off... but I don't know that it's permanent. mark

Run /usr/src/zaptel/ztmonitor 32 -v And adjust your gains in /etc/asterisk/zapata.conf accordingly. Gregory P. Scasny Golden Technologies Inc. http://www.golden-tech.com 219-462-7200 -----Original Message----- From: asterisk-users-admin@lists.digium.com [mailto:asterisk-users-admin@lists.digium.com] On Behalf Of bam Sent: Friday, May 07, 2004 3:35 AM To: asterisk-users@lists.digium.com

sorry... I got distracted half way and forgot to put a meaningfull subject so the archive could figure out the thread. - resending. On 4/14/19 4:04 PM, dovecot-request at dovecot.org wrote: >> Solr ships with autoCommit set to 15 seconds and openSearcher set to >> false on the autoCommit.? The autoSoftCommit setting is not enabled by >> default, but depending on how the index

On 13/04/2019 17:16, Shawn Heisey via dovecot wrote: > On 4/13/2019 4:29 AM, John Fawcett via dovecot wrote: >> If this value was made configurable people could set it to what they >> want. However the underlying problem is likely on solr configuration. > > The Jetty that is included in Solr has its idle timeout set to 50 > seconds.? But in practice, I have not seen this