Re: units issues

On 2017-05-24 20:07, Doug Henderson wrote: > , On 24 May 2017 at 18:16, Brian Inglis wrote: >> I would appreciate it if anyone has any experience with, or can point me >> to, any python3 code in any Cygwin package which works Windows proxy >> authentication? > I had a glance at the source. I

Re: units issues

, On 24 May 2017 at 18:16, Brian Inglis wrote: > I would appreciate it if anyone has any experience with, or can point me > to, any python3 code in any Cygwin package which works Windows proxy > authentication? I had a glance at the source. I recall adapting it to load SQL tables with units

Re: bug in lrint [was: FW: Printing long int in C program under cygwin64]

On Wed, 24 May 2017 16:36:03, Steven Penny wrote: Aren’t both wrong? By definition %i is a signed integer, and size_t is unsigned. So %zu or %llu would be more correct: http://wikipedia.org/wiki/C_data_types They all seem to do the job though: Correcting myself. Here is why you cannot use

Re: units issues

On 2017-05-24 12:13, Achim Gratz wrote: > Brian Inglis writes: >> Updating the currencies only when setup is run seems to me to be >> insufficient if users want to use current currency conversions. > > Well yes. But that means that each user should be able to update, not > just the

Re: bug in lrint [was: FW: Printing long int in C program under cygwin64]

On Wed, 24 May 2017 07:33:27, Eric Blake wrote: Buggy. size_t should be printed with %zi, not %i (since size_t and int are not necessarily the same type). Aren’t both wrong? By definition %i is a signed integer, and size_t is unsigned. So %zu or %llu would be more correct:

Re: too many environment variables on self-compiled xar archiver

Am 24.05.2017 um 12:01 schrieb Andrey Repin: Did you notice this entry and does anyone know where this comes from? !C:=C:\cygwin\bin This is coming from CMD, and denotes current working directory on an indicated drive. And for (most of) all the hairy details, see

RE: bug in lrint [was: FW: Printing long int in C program under cygwin64]

Further to my first question, I also tried llrint() as below. It gives the same output as lrint(). This may not be a big surprise as long long int and long int have the same length. #include /* printf */ #include/* lrint, llrint, rint */ int main () { char text[64]; printf (

Re: High cpu usage by at-spi-bus-launcher and xwin-xdg-menu

On 22/05/2017 14:39, miserable variable wrote: I regularly see these two processes taking more that 25% CPU Time each, as reported by ProcessExplorer. This shouldn't be happening. I have often terminated both not been able to notice any functionality lost, but I am sure I am missing

Re: units issues

Brian Inglis writes: > Updating the currencies only when setup is run seems to me to be > insufficient if users want to use current currency conversions. Well yes. But that means that each user should be able to update, not just the administrator. > Would the best approach be to punt on running

Re: units issues

Buchbinder, Barry (NIH/NIAID) [E] writes: > I would prefer that by default updates happen automatically and those > who do not want automatic updates do something to stop them from > happening. That there should be updates was never debated, only the machanism of doing so is discussed here. >

Re: Bug: bash -e misbehaves with several nested

On 24/05/2017 14:54, Pavel Fedin wrote: Hello! I'd like to report a strange bug in 64-bit bash. The following script: cut --- #/bin/bash -e DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" echo Works: $DIR cut --- Simply exits and produces no output (never reaches echo). The

Re: units issues

On 2017-05-24 10:26, Buchbinder, Barry (NIH/NIAID) [E] wrote: > Brian Inglis sent the following at Tuesday, May 23, 2017 10:37 PM >> On 2017-05-23 17:55, Doug Henderson wrote: >>> On 23 May 2017 at 15:49, Brian Inglis wrote: Updating the currencies only when setup is run seems to me to be

Re: bug in lrint [was: FW: Printing long int in C program under cygwin64]

On 05/24/2017 11:53 AM, Erik Bray wrote: >>> dropping down to assembly; it could very well be that the assembly code >>> is incorrectly truncating things at 32 bits (where it is just fine for >>> 32-bit Cygwin, but wrong for 64-bit): >>> >>> long lrint (double x) >>> { >>> long retval = 0L; >>>

Re: bug in lrint [was: FW: Printing long int in C program under cygwin64]

On Wed, May 24, 2017 at 5:55 PM, Erik Bray wrote: > On Wed, May 24, 2017 at 2:33 PM, Eric Blake wrote: >> On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote: >>> I am experiencing problems printing long int values under cygwin64 >>> installed on a Windows 10 machine. >>>

RE: units issues

Brian Inglis sent the following at Tuesday, May 23, 2017 10:37 PM > >On 2017-05-23 17:55, Doug Henderson wrote: > >> On 23 May 2017 at 15:49, Brian Inglis wrote: >> >>> Updating the currencies only when setup is run seems to me to be >>> insufficient if users want to use current currency

Re: bug in lrint [was: FW: Printing long int in C program under cygwin64]

On Wed, May 24, 2017 at 2:33 PM, Eric Blake wrote: > On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote: >> I am experiencing problems printing long int values under cygwin64 installed >> on a Windows 10 machine. >> >> Below is a test program followed by its output to demonstrate the problem.

Bug: bash -e misbehaves with several nested

Hello! I'd like to report a strange bug in 64-bit bash. The following script: cut --- #/bin/bash -e DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" echo Works: $DIR cut --- Simply exits and produces no output (never reaches echo). The same script works perfectly on 32 bits.

Re: Mintty does not close after "exit" command

> Anything suspicious in logout script? I don't think so. Until now, I didn't even know about such a script (I guess it's "/etc/bash.bash_logout"). Thanks anyway. -- Dani Moncayo -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/

bug in lrint [was: FW: Printing long int in C program under cygwin64]

On 05/24/2017 07:00 AM, Carl Fredrik Forsberg wrote: > I am experiencing problems printing long int values under cygwin64 installed > on a Windows 10 machine. > > Below is a test program followed by its output to demonstrate the problem. > The program was initially written to demonstrate the

Re: Bug: grep behaves incorrectly under the locale C.UTF-8, if a file contains Umlaut characters

On 05/24/2017 02:52 AM, Ronald Fischer wrote: > I have a file X which contains ASCII text, but also in some lines German > umlaut characters. The file is classified as: > > $ file X > X: ISO-8859 text, with CRLF line terminators In ISO-8859, a German umlaut occupies one byte with the

FW: Printing long int in C program under cygwin64

I am experiencing problems printing long int values under cygwin64 installed on a Windows 10 machine. Below is a test program followed by its output to demonstrate the problem. The program was initially written to demonstrate the output from lrint(), and developed further to demonstrate to

Re: Python2 "narrow" build, Unicode issue in regex package

On Wed, May 24, 2017 at 10:30 AM, Václav Haisman wrote: > Hi. > > I have recently hit an issue ([1]) with Python 2.7 and regex package > for it on Cygwin. It appears that Cygwin's Python 2.7 is so called > narrow build. This causes issues when working with Unicode code point > outside BMP, like

Re: Bug: grep behaves incorrectly under the locale C.UTF-8, if a file contains Umlaut characters

On Wed, May 24, 2017 at 9:52 AM, Ronald Fischer wrote: > I have a file X which contains ASCII text, but also in some lines German > umlaut characters. The file is classified as: > > $ file X > X: ISO-8859 text, with CRLF line terminators > > If I grep the file using, say, > > $ grep

[ANNOUNCEMENT] tmux·2.4-1

The following packages have been uploaded to the Cygwin distribution: * tmux-2.4-1 tmux enables a number of terminals (or windows) to be accessed and controlled from a single terminal like screen. tmux runs as a server-client system. A server is created automatically when necessary and holds a

tmux·2.4-1

The following packages have been uploaded to the Cygwin distribution: * tmux-2.4-1 tmux enables a number of terminals (or windows) to be accessed and controlled from a single terminal like screen. tmux runs as a server-client system. A server is created automatically when necessary and holds a

Re: Mintty does not close after "exit" command

Greetings, Dani Moncayo! > Hi, > subject line says it all. > I've been experiencing this problem for some months, on windows 10. > But the problem does not appear in another windows 8.1 system I use. > To reproduce the problem, just open the standard cygwin terminal (e.g. > by double-clicking

Re: Bug: grep behaves incorrectly under the locale C.UTF-8, if a file contains Umlaut characters

> > If I grep the file using, say, > > > $ grep . X >Y > > > (i.e. select every non-empty line and write the result to Y), this works > > fine, if LANG is set to one of: UTF-8, C, C.de_DE, C.en_EN, en_EN, > > de_DE. > > > However, if LANG is set to C.UTF-8, two things happen: > > > -

Re: too many environment variables on self-compiled xar archiver

Greetings, Brian Inglis! > On 2017-05-23 16:30, Michael Stellar wrote: >> I am getting the following when running my self-compiled xar 1.6.1 archiver >> gdb xar >> Starting program: /usr/local/bin/xar >> [New Thread 12044.0x1f54] >> [New Thread 12044.0xfc8] >> [New Thread 12044.0x2dcc] >> [New

Re: Apache rebase trouble

Greetings, Michael Lemke! >> Michael Lemke writes: >>> Now, how about an answer to my actual question? How do I get the Apache/php >>> dlls properly rebased? For reference, here's the error again and so is the >>> attached >>> cygcheck.out. >> >> How large is your UserVM? You don't stand a

Re: Bug: grep behaves incorrectly under the locale C.UTF-8, if a file contains Umlaut characters

Greetings, Ronald Fischer! > I have a file X which contains ASCII text, but also in some lines German > umlaut characters. The file is classified as: > $ file X > X: ISO-8859 text, with CRLF line terminators > If I grep the file using, say, > $ grep . X >Y > (i.e. select

Re: too many environment variables on self-compiled xar archiver

Tried, on 1 different machine without vs 2015 and vs 2017 installed on it, pretty much minimum env variables, getting the same result, probably it's a bug in the cygwin runtime?, does anyone or cygwin developer have other clue?. On Wed, May 24, 2017 at 2:42 PM, Michael Stellar

Mintty does not close after "exit" command

Hi, subject line says it all. I've been experiencing this problem for some months, on windows 10. But the problem does not appear in another windows 8.1 system I use. To reproduce the problem, just open the standard cygwin terminal (e.g. by double-clicking the desktop icon), an then type the

Python2 "narrow" build, Unicode issue in regex package

Hi. I have recently hit an issue ([1]) with Python 2.7 and regex package for it on Cygwin. It appears that Cygwin's Python 2.7 is so called narrow build. This causes issues when working with Unicode code point outside BMP, like the emoji code points in my issue. Is there a chance Cygwin's Python

Bug: grep behaves incorrectly under the locale C.UTF-8, if a file contains Umlaut characters

I have a file X which contains ASCII text, but also in some lines German umlaut characters. The file is classified as: $ file X X: ISO-8859 text, with CRLF line terminators If I grep the file using, say, $ grep . X >Y (i.e. select every non-empty line and write the result to

Re: too many environment variables on self-compiled xar archiver

Hello Brian, Appreciated the reply, tried to search "!C:" on registry or searching for "!C:" in all files (*.*) content on c:\cygwin or using tools like rapidee (to edit env variables), and the result is i could not found it!. Looks like it's being added by either the bash shell? itself