Windows XP home edition
GNU bash, version 2.05b.0(9)-release (i686-pc-cygwin)
cygwin dll version 1.3.22
cygcheck -s -v -r attached
So I have observed a strange phenomenon, where if I execute "man bash" in
(using bash) and then suspend with ^Z, maybe one time in 4 there
is a situation where the fir
This is what I had to do to enable the beep under:
Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 1
Cygwin.dll 1.3.22
It seems that cygwin from 1.3.21 uses the windows "default beep" sound. I
wasn't able to set the default beep with the control panel "sounds
and audio devices" applet un
SO I have been poking around some more and I can report some more details.
I can say that it doesn't seem to be a problem with man, bash or less, and
rather seems to be a problem concerning the way cygwin sends signals to a
pipeline. The reason it showed up with "man bash" rather than others is
sim
See:
http://www.cygwin.com/ml/cygwin/2003-05/msg01615.html
Lev
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
On 3/20/06, D.Pageau wrote:
> <>
>
> no permission denied but output is still stdout
This is expected, because <> operator says to open for read/write on
descriptor 0. It doesn't say anything about stdout.
> &0
>
> no permission denied but output is not redirected to /dev/ttyS0, not
> stdout eith
Can't tell you why this isn't working for you (I wasn't able to make
it work either). But looking at the cygrunsrv sources I noticed
something else that doesn't look quite right:
In cygrunsrv.cc:print_service():
if (interact)
strcat (tmp, "--nohide ");
I assume what is intended is:
FAQ candidate? Either of Eric's explanations seem spot on, to me. And
this question does come up fairly regularly.
Lev
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
On 3/25/06, Christopher Faylor wrote:
> It is not 100% complete but I guess something like that should be in
> the FAQ under a heading of:
>
> Q) I see the way you're doing things and I don't agree. Certainly I
> know more about this then you do. Please prove me wrong, although I
> doubt that
urn error (OnlyOneIO);
in_stderr = optarg;
break;
On 3/25/06, Lev Bishop wrote:
> Can't tell you why this isn't working for you (I wasn't able to make
> it work either). But looking at the cygrunsrv sources I noticed
> something else that doesn't lo
On 3/26/06, Corinna Vinschen wrote:
> Thanks Lev, I've integrated this into the new 1.13-1 version of
> cygrunsrv which I just uploaded to cygwin.com.
Thanks, Corinna. I can almost get it working now. Maybe you can
explain why this works:
$ cygrunsrv -I cygtest -jid 'cygrunsrv test' -p '/cygdrive
On 6/1/06, Robert McKay wrote:
Does anyone know what can go wrong with the windows NUL device? :-)
Do you need any kind of special permissions to use NUL?
You could download winobj from sysinternals.com.
Check that \GLOBAL??\NUL is a symbolic link to \Device\Null
Check that \Device\Null exist
On 6/19/06, mwoehlke wrote:
Larry Hall (Cygwin) wrote:
> mwoehlke wrote:
>> Eric Blake wrote:
>>> That said, cygwin does try to emulate linux, and if someone were to
>>> contribute a patch that would allow cygwin to emulate directory deletion
>>> if it knows that all open handles have also been
On 6/25/06, Benjamin D wrote:
Works fine, so I try seeing what happens with strace:
$ ls -il foo bar; touch foo && strace link foo bar > strace.out 2>&1 && ls -il
foo bar
ls: foo: No such file or directory
ls: bar: No such file or directory
ls: bar: No such file or directory
2814749767163
On 6/28/06, Darryl Miles wrote:
How do I pull down ssh/rsync/cygwin.dll and build in a way that I can
see the problem ?
For ssh and rsync sources, use cygwin setup.exe. For cygwin.dll see
http://cygwin.com/contrib.html
Especially note the requirement to sign a copyright release, if you
want yo
On 6/29/06, Darryl Miles wrote:
I also think from reading through the WIN32 API that I either get
blocking IO or overlapped IO, where overlapped is non-blocking with
async I/O completion signaling. This mode isn't directly compatible
with non-blocking of Unix the way I see it as the data is sti
On 6/29/06, Christopher Faylor wrote:
For the record, I'm not wild about scrapping the existing (but currently
turned off) code in cygwin that is supposed to fix this. Using the NT
api was supposed to allow us to do what we wanted with no half-measures.
I'd rather see someone finish that, or at
I failed to reproduce your problem. However, maybe you can test out a
couple of things:
You are doing the move accross volumes (from /tmp which you have
mounted from d:\programme\cygwin\ to /cygdrive/x/test , which is
x:\test\ ). Do you still see the problem if you do the move within the
same vo
On 7/3/06, Larry Hall (Cygwin) wrote:
Use POSIX paths (i.e. /cygdrive/s). Here I think you've found an application
for 'find'. How about something like:
find /cygdrive/s -maxdepth 1 -print0 | xargs -0 du
How is that better than:
du /cygdrive/s
?
L
--
Unsubscribe info: http://cygwin.co
On 7/4/06, Will Beldman wrote:
I will try to run the script against /cygdrive/s/* instead of S:/* and
let you all know if it fails.
You still haven't posted the actual command line you are using, but
why not use /cygdrive/s instead of /cygdrive/s/* , which should avoid
the need for quoting?
--
On 7/7/06, Darryl Miles wrote:
Dave Korn wrote:
> On 07 July 2006 01:31, Darryl Miles wrote:
>> Maybe you are in a better position to share more insight into the
>> situation (specifically about the use of NtQueryInformationFile in
>> addressing the writability semantics of the POSIX select/poll/
On 7/7/06, Dave Korn wrote:
I *still* don't understand how it is possible for your users to
create files with names that are longer than the maximum filename length that
windows permits - this is a limitation of the windows OS and filing system,
not one that cygwin imposes.
Dave:
Probably the
On 7/7/06, Linda Walsh wrote:
It is quite trivial. He's prepending either "S:/" or
"/cygdrive/s" to an existing pathname. The existing pathname can be at the
limit (~256 bytes). Adding either prefix, above, the pathlen becomes 259
...which is why MAX_PATH on windows is 260, to allow
On 7/11/06, Larry Hall (Cygwin) wrote:
Windows places a limit on the number of ASCII characters in a file/path name.
It's approximately 260 characters. Cygwin path conversion may cut that down
a bit.
More precisely, both the windows version of the path, and the posix
version of the path, mu
On 7/11/06, Jörg Schaible wrote:
Is there any pointer at MS, where this is described exaclty? I was only able to
find some entries in the knowledge base that describe applications that are
affected by this limit, but nowhere an explanation under what circumstances a
process/application is hit
On 8/1/06, Darryl Miles wrote:
I am still interested in tackling the whole situation but I do need to
be furnished with a testcase to work with. I believe the original
comeback by the group of users running "unison" should have insisted a
testcase was produced by them to demonstrate the new bre
On 8/2/06, Darryl Mile:
Okay you seem to have some understanding as to how and why it failed for
the "unison" group of users. Do you think the commented out code is
fixable in any so that all cases work correctly ?
Iff you can come up with a way to distinguish the two situations: 1)
blocking r
On 11/05/05, Peter Ekberg <[EMAIL PROTECTED]> wrote:
> What is going on here?
My guess: "tail frame.log" closes its stdout as soon as it has read
the requested lines from the file, "tail -f frame.log" keeps its
stdout open, since it is waiting for new lines to be added to the
logfile. Cat is using
On 12/05/05, Lev Bishop <[EMAIL PROTECTED]> wrote:
> On 11/05/05, Peter Ekberg <[EMAIL PROTECTED]> wrote:
Sorry, sorry, sorry.
'kin gmail.
Lev
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-si
Try "grep --line-buffered" to get grep to flush output after every
line. There is a performance penalty for doing this. I don't know why
you don't see the buffering when grep's stdout isn't redirected.
Perhaps grep (or the std library) removes/reduces buffering in the
case the output is a terminal.
On 19/05/05, Igor Pechtchanski wrote:
> On Thu, 19 May 2005, Dave Korn wrote:
> > Amusingly enough, those were still both legitimate email addresses even
> > after he X'd them out!
oops.
> That's why one ought to X out the top-level suffix too. I don't believe
> .XXX is a valid suffix. Or
I don't have much clue what I'm doing with binutils, but I've managed
to cause a SEGV in objdump. Here's how:
$ cat > a.c
int main (void)
{
int i=1;
i++;
return i;
}
$ gcc a.c
$ objcopy -O elf32-i386 a.exe
$ objcopy -O pei-i386 a.exe
$ objdump -x a.exe
a.exe: file format
On 25/05/05, Dave Korn wrote:
> Original Message
> >From: Lev Bishop
> >Sent: 25 May 2005 11:54
> Yow. So you copy it from a PE to an ELF, and then back to PE? You very
> much need to read the section on canonicalisation in the bfd section of the
> ld manual. &
On 25/05/05, Dave Korn wrote:
> Original Message
> >From: dirty(DOT)harry(ATSIGN)juno(DOT)com
^^^
Ahem.
> This came up just recently and I'm quoting from memory and without doing
> my background research, so it may not be 100% accu
On 26/05/05, Coetzee, Evert wrote:
> But I'm running it from the cmd.exe command prompt. I'm not in a shell.
>
> cp: cannot stat `/cygdrive/c/*.*': No such file or directory
>
> That is the error I get now.
Do you have "noglob" in your CYGWIN environment variable?
http://cygwin.com/problems.html
On 08/06/05, zzapper wrote:
> Slightly improved to ignore directories (and assuming that Windows files
> always have an extension)
> cygstart "$(/bin/ls -t *.* | head -1)"
why not
cygstart "$(/bin/ls -t . | head -1)"
?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem r
On 05/07/05, FischRon wrote:
> Actually I wasn't able to use "-d" with mkpasswd, because this command
> hung, so I did a "mkpasswd -l >/etc/passwd" instead. Maybe I should
> rerun mkgroup -l (without -d option)?
Really hung, or just taking a very very long time (it will, if it is a
large domain)?
I don't think there is any bug here. This is what I've seen from a
little digging:
1) cygwin strtod rounds to even, with about DECIMAL_DIG (==21) digits
precision, as recommended by 7.20.1.3 of WG14/N843. (It acts strange
when the rounding mode is not round to nearest, but since newlib
doesn't pro
On 06/07/05, Lev Bishop wrote:
> 4) I have no idea what mingw is doing, but it's different to the
> above. Gcc constructs the same double precision constants as on cygwin
> but strtod() is different and seems to have less precision, and
> printf() seems to work with about 16 digit
On 07/07/05, Eric Blake wrote:
> zsh$ bash
> bash$ echo `echo '${'`
> >
> # Hmm - I was just incorrectly presented PS2, asking to try to continue
> what bash thought was an incomplete ${ variable substitution
Actually, this is a bad example, because even if bash did parse
correctly, there would b
On 08/07/05, Eric Blake wrote:
> Meanwhile, you will have to wait patiently until the upstream
> maintainer releases a patch (because I haven't the faintest clue
> where in the lexer to look for fixing his parse error). Repeated
> pinging on the cygwin list will not help speed up the situation.
On 9/28/06, OverlordQ wrote:
Yes, still same problem. And the other copies were from programs that
had been compiled under cygwin like Winboard, jtr, and a few Chess engines.
bash.exe and id.exe both use other cygwin dlls, including
cygintl-3.dll and cygiconv.dll (also for bash cygreadline6.
On 10/23/06, Jim Seymour <[EMAIL PROTECTED]> wrote:
However, if things don't work fine, the background process sticks around
to plague me later.
I'd like to end my main script by killing the background process (if
it's still around), but I'm having a helluva time figuring out HOW.
How about:
One additional thing I'd like to say, if people are considering
possibly making a decision based off the line ending of the first line
of the file: it's worth bearing in mind that it's quite possible for a
file to end up with mixed line endings. Most editors are at least
smart enough to convert th
On 10/28/06, Gary Johnson wrote:
On 2006-10-28, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> From: Gary Johnson; Sent: Friday, October 27, 2006 11:44 PM
> > I am trying to pass Windows path names from a Windows batch file
> > to a Cygwin bash script. I have found a solution using Windows
> > envir
On 11/30/06, Eric Lilja wrote:
If compiled with:
$ g++ -Wall -Wextra -std=c++98 -pedantic -g isnantest.cpp -o run
(those are the flags we have been using in this course).
But it doesn't stackdump if compiled simply with:
$ make isnantest
g++ isnantest.cpp -o isnantest
I was able to reprod
On 11/30/06, Lev Bishop wrote:
On 11/30/06, Eric Lilja wrote:
> If compiled with:
> $ g++ -Wall -Wextra -std=c++98 -pedantic -g isnantest.cpp -o run
> (those are the flags we have been using in this course).
> But it doesn't stackdump if compiled simply with:
>
On 11/30/06, Lev Bishop wrote:
On 11/30/06, Lev Bishop wrote:
> On 11/30/06, Eric Lilja wrote:
> > If compiled with:
> > $ g++ -Wall -Wextra -std=c++98 -pedantic -g isnantest.cpp -o run
> > (those are the flags we have been using in this course).
> > But it doesn
On 11/30/06, Lev Bishop wrote:
Something for the newlib folks to deal with, I suppose.
And they took my suggestion:
http://sources.redhat.com/ml/newlib/2006/msg00938.html
Lev
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com
On 1/12/07, Corinna Vinschen wrote:
To overcome this problem the file is moved to the recycle bin in
unlink(2), so that it disappears from it's original directory,
regardless whether it's still in use or not. I tried to do this as
quick as possible but there's obviously some room for optimizati
On 1/30/07, Glenn Serre wrote:
I have no working patch, I was going to use this problem as an opportunity for
my first attempt to build and debug the cygwin DLL (while maybe even charging a
client for it) but it looked to me as if it may already be being addressed.
Looking again, I see that this
On 2/1/07, Corinna Vinschen wrote:
On Feb 1 07:15, Christopher Faylor wrote:
> We were going to replace text mounts with automatic file conversion using
> "d2u":
>
> cygwin: CRLF line endings detected. Converting.
I think this is too complicated. What about
cygwin: CRLF line endings dete
On 2/5/07, Gary Johnson wrote:
On 2007-02-05, Gary Johnson wrote:
> I recently got Cygwin's sshd running on my Windows XP machine. It
> seems to basically work fine, allowing me to login from any of
> several machines running various flavors of Unix. Cygwin's less
> command, however, doesn't se
On 2/7/07, DePriest, Jason R. wrote:
My department manages some Netscreen NS208 firewalls.
If I ssh into them with the cygwin ssh client (either with rxvt or
with cygwin from a cmd.exe prompt), pasting into the session runs like
a 2400 baud modem.
If I ssh into them with something else such as
On 2/8/07, Lev Bishop wrote:
When I get some time I'll redo those patches against the latest cygwin
version. In the meantime, if netscreen provides a sysctl
net.inet.tcp.ackonpush or some way to disable delayed acks, then that
might help you.
Or you could try changing on your cygwin bo
On 2/11/07, Christopher Faylor wrote:
On Sun, Feb 11, 2007 at 07:20:14PM +0300, Andrew Makhorin wrote:
>Hi,
>
>I detected a strange bug in the standard function gettimeofday.
>It *sometimes* reports the time which being expressed as the integer
>number of milliseconds is *less* than the time obta
On 2/16/07, Andrew Makhorin wrote:
Nevertheless, you agree that if t0 > t1 then t0 - t1 cannot be exact
zero in *any* floating-point model, don't you? Even if optimization is
used, the compiler must not arbitrarily change the precision of the
same floating-point variable.
The -ffloat-store com
On 2/21/07, Larry Hall (Cygwin) wrote:
Roald Hendriks wrote:
> Is it possible that I'm suffering from this known issue?
>
> Is there a patch available?
>
> I'm using OpenSSH 4.5p1-1 and rsync 2.6.6. I have even compiled rsync
> 2.6.9, but this has not resolved the issue.
>
> In order to rule
On 2/22/07, Sven Severus wrote:
But in a textmode mounted directory, 'echo peng >p.txt' creates
a 6 byte long file containing 'p' 'e' 'n' 'g' '\r' '\n'.
OK, exactly as expected. Now I thought, 'cat p.txt' would open
this file for reading in textmode, according to the default rule.
This is, what
On 2/22/07, Norton Allen wrote:
Lev Bishop wrote:
> On 2/22/07, Sven Severus wrote:
>> But in a textmode mounted directory, 'echo peng >p.txt' creates
>> a 6 byte long file containing 'p' 'e' 'n' 'g' '\r' '\n&#
On 2/26/07, Carlo Florendo wrote:
I'm writing an application that requires time precisions up to the
microsecond level. However, I put a hard-coded adjustment of
9000 microseconds since usleep() seems to sleep on the average of
9000 microseconds more than it's supposed to, at least on my
system
On 3/2/07, Gary R. Van Sickle wrote:
The only downside to the switch that I've experienced is
that my interactive shells take quite a bit longer to come up, but I think
that may have something to do with my setup rather than something intrinsic
to the rxvt-unicode+Xserver setup. My usage pattern
On 3/3/07, Gary R. Van Sickle wrote:
> Does running fc-cache speed up your startup?
>
> Lev
It hasn't bothered me enough to even look in to it frankly. My Cygwin
interactive shell startup times have been a bit slower than normal for years
because I have a bit of Perl/Cygpath magic in my bash_pr
On 3/23/07, Zak Johnson wrote:
I first blamed XFT, as it manifested itself most obviously when starting
XFT applications;
fc-cache helps?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cyg
On 3/23/07, Zak Johnson wrote:
Lev Bishop wrote:
> On 3/23/07, Zak Johnson wrote:
> >I first blamed XFT, as it manifested itself most obviously when starting
> >XFT applications;
>
> fc-cache helps?
fc-cache fails:
$ fc-cache
/usr/X11R6/lib/X11/fonts: failed to
On 3/24/07, Zak Johnson wrote:
Lev Bishop wrote:
> With the default fontconfig install, fc-cache tries to put the caches
> in /var/cache/fontconfig and ~/.fontconfig. Check you can write and
> create files in those directories.
Thanks for the suggestions. ~/.fontconfig did not ex
On 3/24/07, Zak Johnson wrote:
Lev Bishop wrote:
> With the default fontconfig install, fc-cache tries to put the caches
> in /var/cache/fontconfig and ~/.fontconfig. Check you can write and
> create files in those directories.
Thanks for the suggestions. ~/.fontconfig did not ex
On 4/23/07, Cary R. wrote:
I had some more time to look into this and when the
simple C program I mentioned earlier uses variables
like the other program, incorrect results are
produced. I have attached this C/C++ program. I
certainly don't understand what is going on. I would
have expected pow t
On 4/23/07, Dave Korn wrote:
On 24 April 2007 00:53, Cary R. wrote:
> I had some more time to look into this and when the
> simple C program I mentioned earlier uses variables
> like the other program, incorrect results are
> produced. I have attached this C/C++ program. I
> certainly don't und
On 5/1/07, Christopher Faylor wrote:
On Tue, May 01, 2007 at 08:06:23AM -0400, Jason Tishler wrote:
>OK. Should I copy or make a hard link?
Before you do this, I have a question. Why is this important now when you've
apparently been doing this for many years? This isn't the only package whic
On 5/1/07, Cary R. wrote:
Patch generated and applied to newlib CVS. As an added bonus I fixed a
few other inconsistencies in acos(), asin(), log() and log10().
Just for the benefit of anyone else investigating this kind of thing
in the future, because I got confused by it and had to do some
s
On 5/2/07, Cary R. wrote:
> Other potentially controversial special cases (may or may not be
> handled correctly by newlib -- I didn't check) are:
> atan2(+-0,-0)=+-pi
> atan2(+-0,+0)=+-0
newlib and my version of glibc return +0 for all these cases.
Hmm *my* version of glibc gets all 4 c
On 5/20/07, Karl M wrote:
Hi All...
>From: Christopher Faylor Subject: Re: How to uniformly point to the root of
>a drive?
>Date: Sun, 20 May 2007 13:36:16 -0400
>
>On Sun, May 20, 2007 at 01:27:05PM -0400, Christopher Faylor wrote:
> >So it sounds like Brian's method would work then wouldn't i
On 5/21/07, Corinna Vinschen <[EMAIL PROTECTED]> wrote:
On May 21 15:46, Dave Korn wrote:
> On 21 May 2007 15:30, Corinna Vinschen wrote:
> > so we can change cygcheck to handle this unambiguously.
>
> cygpath.
Right. Unfortunately I just found that -m is sometimes used as a modifier
(-dm mak
On 5/23/07, Corinna Vinschen <[EMAIL PROTECTED]> wrote:
On May 21 18:45, Corinna Vinschen wrote:
> On May 21 11:55, Lev Bishop wrote:
> > On 5/21/07, Corinna Vinschen <[EMAIL PROTECTED]> wrote:
> > >Actually it seems to be better to disallow only combinations whi
On 5/23/07, Lev Bishop <[EMAIL PROTECTED]> wrote:
On 5/23/07, Corinna Vinschen <[EMAIL PROTECTED]> wrote:
> Done. The rules have changed slightly, but should be consistent now.
> The option handling when reading from files (-o -f ...) is now identical
> to the option
On 5/23/07, Matthew Woehlke <[EMAIL PROTECTED]> wrote:
Lev Bishop wrote:
> Also, why do you have it so that -s is not just a synonym for -d, and
> why doesn't -l force -w? There seems to be no advantage to forcing the
> user to specify an additional flag.
...as I previous
On 6/1/07, Nicolas Joyard <[EMAIL PROTECTED]> wrote:
Hello
I'm having a really weird issue with the last versions of Cygwin, I
started seeing it with 1.5.21 (I didn't use every previous version,
though, but it was not happening with 1.5.10) and it is still there
with 1.5.24.
...
I don't know w
On 6/7/07, Christopher Faylor wrote:
On Thu, Jun 07, 2007 at 07:49:50PM +0800, Samuel Thibault wrote:
>But when talking about communicating with other applications, we need to
>use windows interfaces when the linux API doesn't permit it, shouldn't
>we?
Only if you can clearly communicate why
On 6/7/07, Samuel Thibault wrote:
Christopher Faylor, le Thu 07 Jun 2007 12:37:44 -0400, a écrit :
> On Fri, Jun 08, 2007 at 12:08:59AM +0800, Samuel Thibault wrote:
> >To the best of my knowledge, there is no "unixish" way in cygwin
> >to access these pipes, so we just used CreateNamedPipe().
>
On 6/7/07, Samuel Thibault wrote:
Lev Bishop, le Thu 07 Jun 2007 13:41:44 -0400, a écrit :
> ...around 80MByte/sec, which maybe isn't as fast as it could be using
> native functionality, but surely brltty doesn't need *that* much
> bandwidth for transferring text?
It doesn&#
On 6/7/07, Samuel Thibault wrote:
Lev Bishop, le Thu 07 Jun 2007 14:39:17 -0400, a écrit :
> ...about 2ms round-trip. How is this a problem?
This adds up to the screen reader latency, etc.
Really, we tried both, and while tcp/ip was a bit painful, local sockets
were smooth.
Sorry, bu
On 6/21/07, Brian Dessent wrote:
Jim Powers wrote:
> I am redirecting the stdout of a child process to a socket via the standard
> fork/dup2/exec paradigm and then reading and displaying the output.
>
> This works fine if the exec'd child process is compiled using gcc under
> cygwin. However, it
On 6/22/07, Corinna Vinschen wrote:
However, the next version of Cygwin will use standard DuplicateHandle
calls as for normal file handles. Consequentially your
your test application appears to work with a Cygwin built from CVS:
But MSDN says:
You should not use DuplicateHandle to duplicate h
On 7/3/07, Samuel Thibault wrote:
Corinna Vinschen, le Tue 03 Jul 2007 09:54:24 +0200, a écrit :
> For using local named pipes you don't need winsock anyway, and for
> remote connections you should use Cygwin sockets.
And mixing both is quite difficult. Anyhow, I'll only enable cygwin
sockets a
On 8/29/07, Dmitry Karasik wrote:
> I'd like to submit a bug in cygwin implementation of sin().
> the difference is in 7th digit, and is significant for double precision.
This is not a bug in newlib.
The problem is in glibc and msvc and newlib is (more) correct in this case.
Or, to put it anothe
On 10/10/07, Angelo Graziosi wrote to the cygwin mailing list:
>
> For the sake of completeness I want to flag this.
>
> A recent failure of GFortran tests, regarding the usage of GAMMA
> functions, results in the following problem with 'tgamma' on Cygwin
> (gcc-3.4.4-3):
Even simpler testcase:
On 10/11/07, Angelo Graziosi wrote:
> > That is a bug report against glibc. You cannot draw any inferences
> > between that and newlib/Cygwin because they are totally separate and
> > unrelated code bases.
Technically, when it comes to maths, both lean very heavily on fdlibm,
so they really aren'
On 10/12/07, Angelo Graziosi wrote:
>
> Lev Bishop wrote:
>
> > I'm sure glibc and newlib would both appreciate a good algorithm for
> > tgamma(), if you felt like submitting one...
>
> It seems that a good algorithm has yet been coded in the GAMMA
>
On 10/31/07, michael.vogt wrote:
>
> 1 [main] mpd 1736 C:\cygwin\home\mpx\mpd-test\mpd.exe:
> *** fatal error - MapViewOfFileEx (0x1903),
> Win3 2 error 6. Terminating.
> 68 [main] mpd 676 fork: child 1736 - died
> waiting for dll loading, errno 11 pro
On 11/1/07, Corinna Vinschen wrote:
...
> Thanks for the testcase. I'm surprised that nobody experienced this
> problem before. Sorta holiday here, so I'll look into it next week.
Well, there was:
http://sourceware.org/ml/cygwin/2006-02/msg00824.html
which I am pretty sure was this same issue :
On 11/5/07, Corinna Vinschen wrote:
> On Nov 1 10:58, Corinna Vinschen wrote:
> > On Oct 31 14:26, Lev Bishop wrote:
> > > $ cat lev.c && gcc -o lev lev.c -Wall -Wextra && CYGWIN=server ./lev
> > > #include
> > > #include
> > > #
On 11/5/07, Lev Bishop wrote:
> On 11/5/07, Corinna Vinschen wrote:
> > On Nov 1 10:58, Corinna Vinschen wrote:
> > > On Oct 31 14:26, Lev Bishop wrote:
> > > > $ cat lev.c && gcc -o lev lev.c -Wall -Wextra && CYGWIN=server ./lev
> &
On Dec 11, 2007 8:06 AM, Corinna Vinschen wrote:
> Thanks for the patches. I applied them to the 1.5.x branch. Barring
> any further catastrophies in 1.5.25, I will release a new 1.5.25 within
> a couple of days.
While you're at it...
http://sourceware.org/ml/newlib/2007/msg00912.html
http://cy
On Dec 11, 2007 10:18 AM, TAJTHY Tamás wrote:
> Dear List,
>
> sometimes I have to pause the execution of the mencoder process on my cygwin
> hosted by an XP SP2. If I press Ctrl+S the mencoder is stopped nicely. I
> wanted
> to pause it from a script. I tried the normal UNIX way sending a SIGSTOP
On Dec 14, 2007 8:52 AM, Corinna Vinschen wrote:
> On Dec 14 14:41, Corinna Vinschen wrote:
> > On the other hand, as soon as I call send (or WSASendTo) multiple
> > times with smaller sizes (I tried with 10k), select starts to
> > block at one point. But even then strange things happen. After
>
On Dec 16, 2007 9:07 AM, Corinna Vinschen wrote:
> On Dec 16 14:42, Corinna Vinschen wrote:
> > I'm contemplating the idea to workaround this problem in Cygwin (not
> > for 1.5.25, but in the main trunk) by caping the number of bytes in a
> > single send call, according to the patch Lev sent
On Mon, Aug 4, 2008 at 04:18, Luke Kendall wrote:
>$ explorer /e,c:\\temp\\space\ dir
>$ # NBG^
>$ explorer /e,c:\\temp
>$ # GOOD^
>$ explorer c:\\temp\\space\ dir
>$ # GOOD^ (but no side pane)
>$ explorer /e,"c:\temp\space dir"
>$ # NBG^
>$ explorer /e,"\"c:\te
/e,... to a windows path first, producing
> \e,...
Well, yes obviously. This is the difference between:
On Mon, Aug 4, 2008 at 07:04, Lev Bishop wrote:
> On Mon, Aug 4, 2008 at 04:18, Luke Kendall wrote:
>
>>$ explorer /e,"\"c:\temp\space dir\""
>>
On Fri, Aug 8, 2008 at 12:28, Christopher Faylor wrote:
>> Is there any documentation on who rewrites arguments, under what
>> conditions, and how they're altered?
>
> I missed this when it was first mentioned. Cygwin doesn't munge command
> line arguments. Why would it assume that /e,something
On Fri, Aug 8, 2008 at 15:47, Tim McDaniel wrote:
> On Fri, 8 Aug 2008, Christopher Faylor
> <[EMAIL PROTECTED]> wrote:
>>
>> On Fri, Aug 08, 2008 at 01:58:12PM -0500, Tim McDaniel wrote:
>>>
>>> That's most unpleasant. I don't suppose there's any way to control
>>> Cygwin's bash in re where to p
1 - 100 of 102 matches
Mail list logo
