Re: [ITP] util-linux
On Fri, Mar 03, 2006 at 08:02:26PM -0500, Charles Wilson wrote: Peter Ekberg wrote: can be zapped for Cygwin. I haven't really digged into the problem though, so surprises might crop up... That's an understatement. It is interesting that you highlight my caveat emptor, but then go on and on about the dismerits of the idea while screaming select words for emphasis. Slightly unfair if you ask me. When I then read on some /other/ mailing list that you are going to use the referred message as a pointer to all complaints regarding this or that, I feel that I need to answer, just for the record. Cheers, Peter
Re: [ITP] util-linux
On Mar 5 15:36, Yaakov S (Cygwin Ports) wrote: Yaakov S (Cygwin Ports) wrote: /sbin: agetty fsck.cramfs fsck.minix mkfs.bfs mkfs.cramfs mkfs mkfs.minix mkswap sln /bin and /usr/bin: arch cal chkdupexe col colcrt colrm column ddate getopt hexdump isosize line look mcookie more namei pg rename renice rev script scriptreplay setsid setterm tailf ul whereis Getting back to the point of this thread... are there any further objections to this list? Well, call it objections... I can't quite see the benfit of mkswap and the fsck resp. mkfs backends in the Cygwin distro. You know what will happen, don't you? We have already people once in a while asking if Cygwin can access, say, ext2 filesystems, but these tools add a new type of confusion, along the lines of I created a swap (bfs, minix) partition but I can't mount it in Cygwin. Cygwin is bOrked. Do we really want that? agetty is up for grabs, and the more and cygutils maintainers have agreed. Corinna, IIRC setsid is yours; I have included your Cygwin patches in this setsid. I have never a problem if somebody takes over maintainership for one of my packages ;-) However, would you mind to test if setsid still *needs* the patches I made? They were necessarey way back when, but the changed console handling in Cygwin might make them unnecessary. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
cygwin setup.exe reverse-video bug
settings - control panel - display - appearance - Scheme - High Contrast Black (Extra Large) Now run setup and you cannot read from the main program selection widow. Try to select? Still nothing but white.
Re: cygwin setup.exe reverse-video bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Robert J. Cristel on 3/6/2006 6:55 AM: settings - control panel - display - appearance - Scheme - High Contrast Black (Extra Large) Now run setup and you cannot read from the main program selection widow. Try to select? Still nothing but white. Known problem, and already patched in CVS (for several months, now). Can the setup.exe maintainer please make another release soon? - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEDEEM84KuGfSFAYARAjjcAJ95dmQKa458wWrqWrelZLRBZCdRngCgot7O P1h4sBjqynZLSoDj5t6cqww= =dGnh -END PGP SIGNATURE-
Re: [Patch] Setup: Warn about dropped mirrors.
On Mon, Mar 06, 2006 at 05:00:45AM +0100, Bas van Gompel wrote: Op Wed, 16 Nov 2005 23:29:50 +0100 (MET) schreef Bas van Gompel in n2m-g.dlgdit.3vsvtmt.1atbuzzy-box.bavag: [Warn about dropped mirrors] One more iteration. This is what I've been testing/using for months now. Before I start changing/optimizing this, I'd like to get it in. [Oh and a big PING on those other setup-patches from me (and Igor[*]).] Now using std::string, not String. Also, break write_cache_list out of save_cache_file. Thanks for this patch. I would really like to get this into setup.exe. Are there any impediments to including it? If not, I can apply it if no one else has the time to do so. cgf
Re: GTK+ 2.8
Yaakov schrieb: Yaakov S (Cygwin Ports) wrote: Gerrit, Regarding the update to GTK+ 2.8: 1) atk-1.10.3 has no new requirements and can be bumped immediately. 2) pango-1.10.3 needs cairo (now in the distro) for the new libpangocairo-1.0, which is required for gtk+-2.8; with that, it can be bumped immediately. 3) glib-2.8.6 passes all tests. The mainloop-test doesn't actually hang; it does take a few minutes, but eventually passes. 4) gtk-2.8.x requires cairo and pango-1.10 with cairo. I haven't tried building it yet. Is there any way in which I can help? Gerrit, Are you still with us? Yes I'm alive, but busy :-( I'm at the CeBIT the next ten days, I'll try to use the sparetime in the evening in the hotel to do some Cygwin related work. Gerrit -- =^..^=
Re: [Patch] Setup: Warn about dropped mirrors.
Christopher Faylor wrote: Thanks for this patch. I would really like to get this into setup.exe. Are there any impediments to including it? If not, I can apply it if no one else has the time to do so. Please go ahead. Sad to say I haven't had time recently to test setup.exe patches. Brian
Re: [ITP] util-linux
Corinna Vinschen wrote: Well, call it objections... I can't quite see the benfit of mkswap and the fsck resp. mkfs backends in the Cygwin distro. You know what will happen, don't you? We have already people once in a while asking if Cygwin can access, say, ext2 filesystems, but these tools add a new type of confusion, along the lines of I created a swap (bfs, minix) partition but I can't mount it in Cygwin. Cygwin is bOrked. Do we really want that? I hear your point, but how much must we oversimplify things for those end-users that don't know what their doing? We already have e2fsprogs; did that contribute to this problem, or is it just that people always think Cygwin can do everything that Linux can (don't we wish!)? I have never a problem if somebody takes over maintainership for one of my packages ;-) However, would you mind to test if setsid still *needs* the patches I made? They were necessarey way back when, but the changed console handling in Cygwin might make them unnecessary. AFAICS, the patch is still necessary. Yaakov
Re: [Patch] Setup: Warn about dropped mirrors.
Op Mon, 6 Mar 2006 05:00:45 +0100 (MET) schreef Bas van Gompel in n2m-g.dugeel.3tags6n.1atbuzzy-box.bavag: [Warn about dropped mirrors] So, this patch got CRLF-contaminated. Please use d2u on it. Sorry for the inconvenience. L8r, Buzz. -- ) | | ---/ ---/ Yes, this | This message consists of true | I do not -- | | // really is | and false bits entirely.| mail for ) | | //a 72 by 4 +---+ any1 but -- \--| /--- /--- .sigfile. | |perl -pe s.u(z)\1.as.| me. 4^re
Re: Problem Starting X-Windows -- Problem solved?
I have also seen the same Cygwin/startx problem that Dean C. Tsai reported on 15 Feb 2006, and I have found the same workaround, killing the sh.exe process that's hogging the CPU. I don't know what's causing it, either. I tried the latest suggestion, renaming sh.exe before running startx, but I got an immediate error message bad interpreter: No such file or directory and the $ prompt, with no X window and no Winit or x* processes running. I, like wonder_6908, have McAfee Privacy Service running -- but when I disabled it, the problem remained. I also disabled the rest of the McAfee Security Center -- VirusScan, Personal Firewall Plus, and SpamKiller. The problem remained. Unlike Dean, I have a Gateway NX500X, not a Dell. I've had this problem since the computer was brand-new (the first of the year), and I have not modified the keyboard configuration. I'll keep watching for resolution. (I tried posting a similar message last week, following up on a more general posting I'd sent a month earlier, prior to this stream. I don't see either message in the archive, so I'm trying again.) Bill Page -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Problem Starting X-Windows -- Problem solved?
On 03/06/2006, Bill Page wrote: I have also seen the same Cygwin/startx problem that Dean C. Tsai reported on 15 Feb 2006, and I have found the same workaround, killing the sh.exe process that's hogging the CPU. I don't know what's causing it, either. I tried the latest suggestion, renaming sh.exe before running startx, but I got an immediate error message bad interpreter: No such file or directory and the $ prompt, with no X window and no Winit or x* processes running. I, like wonder_6908, have McAfee Privacy Service running -- but when I disabled it, the problem remained. I also disabled the rest of the McAfee Security Center -- VirusScan, Personal Firewall Plus, and SpamKiller. The problem remained. Typically, when McAffee and Norton cause problems, it is not sufficient to just disable them. You have to uninstall them to make a real test. So McAfee still may be getting in your way and the root cause of this problem for you. If you have the option, you may want to consider uninstalling it it and repeating the test. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Opengl and Viz Roll
Dear Harold, Sorry to trouble you. I am a student from Auburn University and now I am grouping a cluster which the frontend can use Opengl. However, I really don't know how to start the Opengl by command in Xterm window. And I have no idea how to run an Opengl program in this environment. I would be really appreaciate if you can give me some suggestions about that. Thank you very much! Regards Jenny Zhenni Li Graduate Student Computer Science Software Engineering 334-442-4039 (home) 334-844-6321 (office) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/w32api ChangeLog
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-03-06 14:29:04 Modified files: winsup/w32api : ChangeLog Log message: * include/wingdi.h [WINVER = 0x0500] (INTERNET_STATE_*,*_EMBEDED): Included in Windows 2000 and later. Thanks to: David A. Capello dacap at users dot sf dot net Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.732r2=1.733
src/winsup/w32api ChangeLog
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-03-06 14:30:30 Modified files: winsup/w32api : ChangeLog Log message: * include/wingdi.h [WINVER = 0x0500] (GRADIENT_FILL_*,*_EMBEDED): Included in Windows 2000 and later. Thanks to: David A. Capello dacap at users dot sf dot net Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.733r2=1.734
src/winsup/w32api ChangeLog include/shlobj.h
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-03-06 21:02:55 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: shlobj.h Log message: * include/shlobj.h (SFGAO_ISSLOW): Define. (SFGAO_DISPLAYATTRMASK): Define in terms of preceding display attribute constants. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.734r2=1.735 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/shlobj.h.diff?cvsroot=srcr1=1.43r2=1.44
src/winsup/w32api ChangeLog include/wingdi.h
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-03-06 21:13:43 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: wingdi.h Log message: * include/wingdi.h (CS_*): Correct WINVER guard on Image Color Matching colour definitions. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.735r2=1.736 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/wingdi.h.diff?cvsroot=srcr1=1.46r2=1.47
Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4
--- Christopher Faylor [EMAIL PROTECTED] wrote: You have missed how efault.faulted() is supposed to be operating and, AFAICT, *does* operate throughout the Cygwin DLL. It really is supposed to be catching NULL dereferences. It's possible of course, that there is something wrong with efault.faulted() but that doesn't mean we need to extra code around efault.faulted. It means that efault.faulted needs to be fixed. i.e., we need to fix the problem not the symptom. cgf I did some more research over the weekend and my problem seems to only come when loading a dll via dlopen() and run_ctors() is called from dll:init() and pthread_key_create() is called during the time that run_ctors() is active. I still have not found who is calling pthread_key_create(), but will be working on this as time permits this week. It's been several years since I did any assembly language coding, so I have to study what's going on when efault.faulted() returns non-zero - and figure out how to get gdb to step through the assembly code. Thanks, Gary __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4
Gary Zablackis wrote: I did some more research over the weekend and my problem seems to only come when loading a dll via dlopen() and run_ctors() is called from dll:init() and pthread_key_create() is called during the time that run_ctors() is active. I still have not found who is calling pthread_key_create(), but will be working on this as time permits this week. If you are trying to track down why you get a SIGSEGV in pthread_key_create while running your app in gdb you are wasting your time. This is not a fault, it is expected and normal. Search the archives. Brian
[Patch] cygwinenv.sgml: Missing /para.
Hi, Doc won't build... ChangeLog-entry (You know, please fix the at.): 2006-03-07 Bas van Gompel cygwin-patch.buzzatbavag.tmfweb.nl * cygwinenv.sgml: Add missing /para at transparent_exe. L8r, Buzz. -- ) | | ---/ ---/ Yes, this | This message consists of true | I do not -- | | // really is | and false bits entirely.| mail for ) | | //a 72 by 4 +---+ any1 but -- \--| /--- /--- .sigfile. | |perl -pe s.u(z)\1.as.| me. 4^re --- src/winsup/doc/cygwinenv.sgml 2006-02-05 20:23:44.0 +0100 +++ src/winsup/doc/cygwinenv.sgml 2006-02-27 23:13:52.0 +0100 @@ -177,7 +177,7 @@ suffix transparently. These functions a treated as too dangerous to act on files with .exe suffix if the .exe suffix wasn't given explicitely in the file name argument, and this is still the case if the transparent_exe option is not set. Default is not -set. +set./para /listitem listitem paraenvar(no)traverse/envar - This option only affects NT systems.
Re: Precision of doubles and stdio
Dear Mr. Bagnara, Roberto Bagnara wrote: ... does this on Linux/i686 $ a.out 70.9 70.905684341886080801486968994140625 and does the following under Cygwin on the same machine: ... $ ./a.exe 70.9 70.90568434188608080148696899414 Why? Is there a way to reconcile the two behaviors? Notice that I know about the x87 and its vaguaries: nonetheless I wonder why such a scanf immediately followed by a printf shows a difference between Cygwin and Linux. With all due respect, why would you want to? With double you are guaranteed only 16 or so digits - the rest is noise. Frankly I am amazed that it agrees as far as it does. Jim -- 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/
[ANNOUNCEMENT] Updated: libgii1-1.0.1-1, libgii1-devel-1.0.1-1 and libgii1-input-x-1.0.1-1
A new version of 'libgii' is available for download. It is an upstreams bugfix release, but also includes a packaging fix to enable debugging. - Look at GII_DEBUGSYNC instead of GGI_DEBUGSYNC - Update doc/README.directx to help MinGW users configure properly - input-mouse: ignore undefined bit in IMPS/2 protocol. Now buttons recognized properly. - input-quartz: make mouse moving and mouse wheel work properly - buildsystem: include/ggi/system.h is no longer (unintentionally) distributed. It disturbed out of tree builds. - buildsystem: libtool update / fixes - Prevent (broken) loading of dynamic modules if linking with static libgg. - Fix internal bugs in configuration parsing, which prevented the .include directive to work properly. - gg-tree(3): RedBlack tree fixes - Fixed signal based scheduler so that it finds the ggtick executable even if configuring with the default prefix. Bug reported by Rodney Lamb. New packages: libgii1-1.0.1-1 libgii1-devel-1.0.1-1 libgii1-display-x-1.0.1-1 For a brief description of these packages, see http://cygwin.com/packages/ . To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Run setup.exe to install or update the libgii1 packages. If you have questions or comments, please send them to the Cygwin mailing list. I would appreciate it if you would use the mailing list rather than emailing me directly. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL. Cheers, Peter -- 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/
[ANNOUNCEMENT] Updated: libggi2-2.2.1-1, libggi2-devel-2.2.1-1, libggi2-display-aa-2.2.1-1, libggi2-display-file-2.2.1-1, libggi2-display-terminfo-2.2.1-1, libggi2-display-x-2.2.1-1 and libggi2-sample
A new version of 'libggi' is available for download. It is an upstreams bugfix release, but also includes a packaging fix to enable debugging. - Update doc/README.directx to help MinGW users configure properly - display-fbdev(7): correct path in config-file. The mach64 fbdev accelerator-sublib loads again - display-kgi(7): Make it compile with gcc 4. - display-file(7): fix crash on exit - display-aa(7): Documentation fix: aalib reads settings from AAOPTS env. variable - buildsystem: libtool update / fixes New packages: libggi2-2.2.1-1 libggi2-devel-2.2.1-1 libggi2-display-aa-2.2.1-1 libggi2-display-file-2.2.1-1 libggi2-display-terminfo-2.2.1-1 libggi2-display-x-2.2.1-1 libggi2-samples-2.2.1-1 For a brief description of these packages, see http://cygwin.com/packages/ . To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Run setup.exe to install or update the libggi2 packages. If you have questions or comments, please send them to the Cygwin mailing list. I would appreciate it if you would use the mailing list rather than emailing me directly. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL. Cheers, Peter -- 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/
[ANNOUNCEMENT] Updated: libggimisc2-2.2.1-1, libggimisc2-devel-2.2.1-1 and libggimisc2-samples-2.2.1-1
A new version of 'libggimisc' is available for download. It is an upstreams bugfix release, but also includes a packaging fix to enable debugging. - Cleanup properly on failure in ggiMiscInit - pseudo-stubs: kill leftover (debugging) printf - buildsystem: libtool update / fixes New packages: libggimisc2-2.2.1-1 libggimisc2-devel-2.2.1-1 libggimisc2-samples-2.2.1-1 For a brief description of these packages, see http://cygwin.com/packages/ . To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Run setup.exe to install or update the libggimisc2 packages. If you have questions or comments, please send them to the Cygwin mailing list. I would appreciate it if you would use the mailing list rather than emailing me directly. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL. Cheers, Peter -- 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/
[ANNOUNCEMENT] Updated: libggiwmh2-0.3.1-1, libggiwmh2-devel-0.3.1-1, libggiwmh2-display-x-0.3.1-1 and libggiwmh2-samples-0.3.1-1
A new version of 'libggiwmh' is available for download. It is an upstreams bugfix release, but also includes a packaging fix to enable debugging. - Cleanup properly on failure in ggiWmhInit - buildsystem: libtool update / fixes New packages: libggiwmh2-0.3.1-1 libggiwmh2-devel-0.3.1-1 libggiwmh2-display-x-0.3.1-1 libggiwmh2-samples-0.3.1-1 For a brief description of these packages, see http://cygwin.com/packages/ . To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Run setup.exe to install or update the libggiwmh0 packages. If you have questions or comments, please send them to the Cygwin mailing list. I would appreciate it if you would use the mailing list rather than emailing me directly. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL. Cheers, Peter -- 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/
Re: Precision of doubles and stdio
Jim Easton wrote: Dear Mr. Bagnara, Roberto Bagnara wrote: ... does this on Linux/i686 $ a.out 70.9 70.905684341886080801486968994140625 and does the following under Cygwin on the same machine: ... $ ./a.exe 70.9 70.90568434188608080148696899414 Why? Is there a way to reconcile the two behaviors? Notice that I know about the x87 and its vaguaries: nonetheless I wonder why such a scanf immediately followed by a printf shows a difference between Cygwin and Linux. With all due respect, why would you want to? With double you are guaranteed only 16 or so digits - the rest is noise. Frankly I am amazed that it agrees as far as it does. Dear Jim, what is and what is not noise depends on the application. In our applications we systematically use controlled rounding on IEEE 754 floating point numbers. In the end, what we obtain (in memory) are definite (i.e., provably correct) lower or upper bounds of some quantities. Call `x' such a quantity, and suppose we have that our computed upper bound for `x' is the IEEE 754 Double Precision number 0x4051b99a, that is (exactly!), 70.905684341886080801486968994140625. If that number is (wrongly!) printed as 70.90568434188608080148696899414 then we lose correctness, since x = 70.905684341886080801486968994140625 does not imply x = 70.90568434188608080148696899414. So, the final 0625 is not noise in our applications: it is what may make the difference between a correct statement and an incorrect one. Notice also that any IEEE 754 number can be (exactly!) printed with a finite number of decimal digits. Finally, notice that writing an algorithm to print them correctly is not rocket science. Hence my astonishment when Tim showed me that the C standard decided, instead, to allow blatant violations of the principle of least astonishment :-) All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED] -- 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/
RE: Precision of doubles and stdio
x = 70.905684341886080801486968994140625 DOES imply x = 70.90568434188608080148696899414 AND vice-versa! Even in 64 bits IEEE 754 the representations of the 2 numbers are identical. Anything beyond the 34th decimal digit is made up by the printf implementation, i.e. it' snoise.
Re: TTYfier
Barry B wrote: Does anyone still have the source code to a Cygwin program called ttyfier? TTYfier is supposed to allow the running of Windows console applications that don't know how to converse with a tty. This would allow one to run such programs via the sshd that comes with Cygwin. There used to be a web site in Russia run by Egor Deo that contained the project files, but the site no longer exists and I am unable to locate the files anywhere else on the Internet. Also, is TTYfier still necessary for my intended purpose? Or has someone else come up with a better way to accomplish this over years? Thanks! Hi, Barry! You can download ttyfier sources from here: http://www.corpit.ru/deo/ttyfier-src.tar.bz2 There was certainly some bit-rot in it since 2001. Moreover, i've added some new functionality, such as ability to access 'ttyfied' program from xterm window, but it's somewhat experimental at the moment, and relies on unicode version of ncurses library -- libncursesw, which, AFAICT, was never officialy released for cygwin. I'm going to revisit ttyfier this week to see if anything needs fixing for recent cygwin. Feel free to build it yourself and ask any questions about it. egor. -- 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/
RE: ls.exe hangs on inaccessible directory if ntsec is turned off
On 03 March 2006 20:28, Corinna Vinschen wrote: I've applied a fix. Please test. WJFFM. cheers, DaveK -- Can't think of a witty .sigline today -- 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/
RE: Precision of doubles and stdio
[ X-Posted and Followups set to newlib list; this is almost certainly not a
cygwin specific issue. To recap:- ]
On 03 March 2006 21:44, Roberto Bagnara wrote:
Hi there,
the following little program
#include stdio.h
int main() {
double d;
scanf(%lf, d);
printf(%.1000g\n, d);
return 0;
}
does this on Linux/i686
$ gcc -W -Wall in.c
$ a.out
70.9
70.905684341886080801486968994140625
and does the following under Cygwin on the same machine:
[EMAIL PROTECTED] /tmp
$ gcc -W -Wall in.c
[EMAIL PROTECTED] /tmp
$ ./a.exe
70.9
70.90568434188608080148696899414
On 03 March 2006 22:21, Tim Prince wrote:
If you haven't gone out of your way to install similar printf() support
libraries on cygwin and linux, they will definitely not be the same. My
past reading of various relevant documents convinced me that digits
beyond the 17th in formatting of doubles are not required by any
standard to be consistent between implementations. They have no useful
function, as 17 digits are sufficient to determine uniquely the
corresponding binary value in IEEE 754 format.
Jim Easton wrote:
With all due respect, why would you want to? With double you are
guaranteed only 16 or so digits - the rest is noise. Frankly I am
amazed that it agrees as far as it does.
On 06 March 2006 09:30, Roberto Bagnara wrote:
In our applications we systematically use controlled rounding
on IEEE 754 floating point numbers. In the end, what we obtain
(in memory) are definite (i.e., provably correct) lower or upper
bounds of some quantities.
Call `x' such a quantity, and suppose we have that our computed
upper bound for `x' is the IEEE 754 Double Precision number
0x4051b99a,
that is (exactly!),
70.905684341886080801486968994140625.
If that number is (wrongly!) printed as
70.90568434188608080148696899414
then we lose correctness, since
x = 70.905684341886080801486968994140625
does not imply
x = 70.90568434188608080148696899414.
So, the final 0625 is not noise in our applications:
it is what may make the difference between a correct statement
and an incorrect one.
Notice also that any IEEE 754 number can be (exactly!) printed
with a finite number of decimal digits. Finally, notice that
writing an algorithm to print them correctly is not rocket science.
Hence my astonishment when Tim showed me that the C standard
decided, instead, to allow blatant violations of the principle
of least astonishment :-)
I agree with you that the number is of course precisely representable. Even
if Tim isn't onto a red herring (which I think he probably is) and the
standard really does give us leeway in this case, we could still do better
anyway. Newlib has had a few glitches and corner cases in its fp support
before and probably will do again; we can look into this. I notice, for
instance, that newlib doesn't define DECIMAL_DIG or the related symbols
AFAICT.
Are the newlib-based cygwin system and the glibc-based linux system using
the same mode bits in the fpu control register? That '0625' looks awfully
like a 1-lsb error, maybe they are using different rounding or guard bits or
something like that?
cheers,
DaveK
--
Can't think of a witty .sigline today
--
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/
gcc-g++ can not find included files
Hello,
I am trying to compile the C++ program included. Unfortunately, when I
type :
g++ -o avcodec_sample avcodec_sample.cpp -lavformat -lavcodec -lz, gcc
outputs many errors telling that it can not find many functions and
variables, after telling :
avcodec_sample.cpp:20:21: avcodec.h : No such file or directory
avcodec_sample.cpp:21:22: avformat.h : No such file or directory
Can anybody explain me why it can not find these files, although the
path in the #include part is right?
Thank you very much in advance
Agnes
PS : I have downgraded gcc to the 3.3.3-3 release, since I had problems
with Octave when I used the 3.4 release
// avcodec_sample.cpp
// A small sample program that shows how to use libavformat and libavcodec to
// read video from a file.
//
// Use
//
// g++ -o avcodec_sample avcodec_sample.cpp -lavformat -lavcodec -lz
//
// to build (assuming libavformat and libavcodec are correctly installed on
// your system).
//
// Run using
//
// avcodec_sample myvideofile.mpg
//
// to write the first five frames from myvideofile.mpg to disk in PPM
// format.
#include avcodec.h
#include avformat.h
#include stdio.h
bool GetNextFrame(AVFormatContext *pFormatCtx, AVCodecContext *pCodecCtx,
int videoStream, AVFrame *pFrame)
{
static AVPacket packet;
static int bytesRemaining=0;
static uint8_t *rawData;
static bool fFirstTime=true;
int bytesDecoded;
int frameFinished;
// First time we're called, set packet.data to NULL to indicate it
// doesn't have to be freed
if(fFirstTime)
{
fFirstTime=false;
packet.data=NULL;
}
// Decode packets until we have decoded a complete frame
while(true)
{
// Work on the current packet until we have decoded all of it
while(bytesRemaining 0)
{
// Decode the next chunk of data
bytesDecoded=avcodec_decode_video(pCodecCtx, pFrame,
frameFinished, rawData, bytesRemaining);
// Was there an error?
if(bytesDecoded 0)
{
fprintf(stderr, Error while decoding frame\n);
return false;
}
bytesRemaining-=bytesDecoded;
rawData+=bytesDecoded;
// Did we finish the current frame? Then we can return
if(frameFinished)
return true;
}
// Read the next packet, skipping all packets that aren't for this
// stream
do
{
// Free old packet
if(packet.data!=NULL)
av_free_packet(packet);
// Read new packet
if(av_read_packet(pFormatCtx, packet)0)
goto loop_exit;
} while(packet.stream_index!=videoStream);
bytesRemaining=packet.size;
rawData=packet.data;
}
loop_exit:
// Decode the rest of the last frame
bytesDecoded=avcodec_decode_video(pCodecCtx, pFrame, frameFinished,
rawData, bytesRemaining);
// Free last packet
if(packet.data!=NULL)
av_free_packet(packet);
return frameFinished!=0;
}
void SaveFrame(AVFrame *pFrame, int width, int height, int iFrame)
{
FILE *pFile;
char szFilename[32];
int y;
// Open file
sprintf(szFilename, frame%d.ppm, iFrame);
pFile=fopen(szFilename, wb);
if(pFile==NULL)
return;
// Write header
fprintf(pFile, P6\n%d %d\n255\n, width, height);
// Write pixel data
for(y=0; yheight; y++)
fwrite(pFrame-data[0]+y*pFrame-linesize[0], 1, width*3, pFile);
// Close file
fclose(pFile);
}
int main(int argc, char *argv[])
{
AVFormatContext *pFormatCtx;
int i, videoStream;
AVCodecContext *pCodecCtx;
AVCodec *pCodec;
AVFrame *pFrame;
AVFrame *pFrameRGB;
int numBytes;
uint8_t *buffer;
// Register all formats and codecs
av_register_all();
// Open video file
if(av_open_input_file(pFormatCtx, argv[1], NULL, 0, NULL)!=0)
return -1; // Couldn't open file
// Retrieve stream information
if(av_find_stream_info(pFormatCtx)0)
return -1; // Couldn't find stream information
// Dump information about file onto standard error
dump_format(pFormatCtx, 0, argv[1], false);
// Find the first video stream
videoStream=-1;
for(i=0; ipFormatCtx-nb_streams; i++)
if(pFormatCtx-streams[i]-codec.codec_type==CODEC_TYPE_VIDEO)
{
videoStream=i;
break;
}
if(videoStream==-1)
return -1; // Didn't find a video stream
// Get a pointer to the codec context for the video stream
pCodecCtx=pFormatCtx-streams[videoStream]-codec;
// Find the decoder for the video stream
pCodec=avcodec_find_decoder(pCodecCtx-codec_id);
if(pCodec==NULL)
return -1; // Codec not found
// Inform the codec that we can handle
setup.exe: feature request with patch
Hi All,
I deploy cygwin using unattended (http://unattended.sf.net/) and wpkg
(http://www.wpkg.org/). It's useful for me to be able to specify
additional packages to be installed on the command line. The attached
file is a patch to provide this: call setup -p
package1,package2,package3,...,packageN to have packages1-N
artificially included in the 'Base' part of the distribution and hence
automatically included.
No doubt there are many better ways of doing this (I'm not a C++
programmer and had to go with 'what I could do' rather than 'the best
way') but perhaps this will be useful.
Yours,
Frank
--
Frank Lee
Semiconductor Physics, Cavendish Laboratory http://www.sp.phy.cam.ac.uk/
diff -u --strip-trailing-cr setup/package_db.cc setup-new/package_db.cc
--- setup/package_db.cc 2005-10-14 05:10:26.0 +0100
+++ setup-new/package_db.cc 2006-03-06 13:35:31.279477400 +
@@ -399,9 +399,16 @@
#endif
}
+void
+packagedb::addFromCmdLine ()
+{
+ for_each(packages.begin(), packages.end(),
mem_fun(packagemeta::addToCategoryBase));
+}
+
void
packagedb::fillMissingCategory ()
{
+ for_each(packages.begin(), packages.end(),
visit_if(mem_fun(packagemeta::addToCategoryBase),
mem_fun(packagemeta::isManuallyWanted)));
for_each(packages.begin(), packages.end(),
visit_if(mem_fun(packagemeta::setDefaultCategories),
mem_fun(packagemeta::hasNoCategories)));
for_each(packages.begin(), packages.end(),
mem_fun(packagemeta::addToCategoryAll));
}
diff -u --strip-trailing-cr setup/package_db.h setup-new/package_db.h
--- setup/package_db.h 2003-07-29 11:07:22.0 +0100
+++ setup-new/package_db.h 2006-03-06 13:38:21.148123000 +
@@ -47,6 +47,7 @@
PackageDBConnectedIterator connectedEnd();
void fillMissingCategory();
void markUnVisited();
+ void addFromCmdLine();
void setExistence();
/* all seen binary packages */
static std::vector packagemeta * packages;
diff -u --strip-trailing-cr setup/package_meta.cc setup-new/package_meta.cc
--- setup/package_meta.cc 2005-09-11 15:45:54.0 +0100
+++ setup-new/package_meta.cc 2006-03-06 15:02:16.480086200 +
@@ -43,6 +43,7 @@
#include script.h
#include package_version.h
+#include getopt++/StringOption.h
#include cygpackage.h
#include package_db.h
@@ -53,6 +54,8 @@
/*/
+static StringOption PackageOption (, 'p', package, Packages to include);
+
const
packagemeta::_actions
packagemeta::Default_action (0);
@@ -654,6 +657,25 @@
return categories.size() == 0;
}
+bool
+packagemeta::isManuallyWanted() const
+{
+ string packages_option = PackageOption;
+ string tname;
+ /* Split the packages listed in the option up */
+ string::size_type loc = packages_option.find( ,, 0 );
+ bool breturn=false;
+ while ( loc != string::npos ) {
+tname=packages_option.substr(0,loc);
+packages_option=packages_option.substr(loc+1);
+breturn = breturn || (name.compare(tname)==0);
+loc = packages_option.find( ,, 0 );
+ }
+ /* At this point, no , exists */
+ breturn=breturn || (name.compare(packages_option)==0);
+ return breturn;
+}
+
void
packagemeta::setDefaultCategories()
{
@@ -665,3 +687,9 @@
{
add_category (All);
}
+
+void
+packagemeta::addToCategoryBase()
+{
+ add_category (Base);
+}
diff -u --strip-trailing-cr setup/package_meta.h setup-new/package_meta.h
--- setup/package_meta.h2005-05-03 22:55:08.0 +0100
+++ setup-new/package_meta.h2006-03-06 13:37:39.642747800 +
@@ -54,8 +54,10 @@
void visited(bool const );
bool visited() const;
bool hasNoCategories() const;
+ bool isManuallyWanted() const;
void setDefaultCategories();
void addToCategoryAll();
+ void addToCategoryBase();
class _actions
{
diff -u --strip-trailing-cr setup/setup_version.c setup-new/setup_version.c
--- setup/setup_version.c 2006-03-06 12:24:59.154337800 +
+++ setup-new/setup_version.c 2006-03-06 13:05:52.788225000 +
@@ -1,3 +1,3 @@
#define VERSION_PREFIX %%% setup-version
-static const char version_store[] = VERSION_PREFIX 2.524;
+static const char version_store[] = VERSION_PREFIX 2.524RFL;
const char *setup_version = version_store + sizeof (VERSION_PREFIX);
diff -u --strip-trailing-cr setup/state.cc setup-new/state.cc
--- setup/state.cc 2005-05-04 15:52:34.0 +0100
+++ setup-new/state.cc 2006-03-06 14:27:05.103281400 +
@@ -23,6 +23,7 @@
#include state.h
bool unattended_mode;
+String packages_option;
int source;
diff -u --strip-trailing-cr setup/state.h setup-new/state.h
--- setup/state.h 2005-05-04 15:52:34.0 +0100
+++ setup-new/state.h 2006-03-06 14:26:55.125727000 +
@@ -33,6 +33,8 @@
extern bool unattended_mode;
+extern String packages_option;
+
extern int source;
extern String local_dir;
--
Unsubscribe info:
RE: gcc-g++ can not find included files
On 06 March 2006 15:09, Agnes Bousquier wrote: Hello, I am trying to compile the C++ program included. Unfortunately, when I type : g++ -o avcodec_sample avcodec_sample.cpp -lavformat -lavcodec -lz, gcc outputs many errors telling that it can not find many functions and variables, after telling : avcodec_sample.cpp:20:21: avcodec.h : No such file or directory avcodec_sample.cpp:21:22: avformat.h : No such file or directory Can anybody explain me why it can not find these files, although the path in the #include part is right? What 'path in the #include part'? Your example just says #include avcodec.h #include avformat.h I don't see any path in that. You had better use a -I option to tell the compiler where the include files are. cheers, DaveK -- Can't think of a witty .sigline today -- 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/
Re: gcc-g++ can not find included files
Dave Korn a écrit : On 06 March 2006 15:09, Agnes Bousquier wrote: Hello, I am trying to compile the C++ program included. Unfortunately, when I type : g++ -o avcodec_sample avcodec_sample.cpp -lavformat -lavcodec -lz, gcc outputs many errors telling that it can not find many functions and variables, after telling : avcodec_sample.cpp:20:21: avcodec.h : No such file or directory avcodec_sample.cpp:21:22: avformat.h : No such file or directory Can anybody explain me why it can not find these files, although the path in the #include part is right? What 'path in the #include part'? Your example just says #include avcodec.h #include avformat.h I don't see any path in that. You had better use a -I option to tell the compiler where the include files are. cheers, DaveK Thank you for your reply. You showed me where I did wrong : I was modifying a file, and compiling another... Please excuse me for my stupidity. Best regards, Agnès -- 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/
Re: setup.exe: feature request with patch
On Mon, 6 Mar 2006, Dr. F. Lee wrote: Hi All, I deploy cygwin using unattended (http://unattended.sf.net/) and wpkg (http://www.wpkg.org/). It's useful for me to be able to specify additional packages to be installed on the command line. The attached file is a patch to provide this: call setup -p package1,package2,package3,...,packageN to have packages1-N artificially included in the 'Base' part of the distribution and hence automatically included. No doubt there are many better ways of doing this (I'm not a C++ programmer and had to go with 'what I could do' rather than 'the best way') but perhaps this will be useful. Frank, First off, thanks for the patch -- it's always nice seeing someone actually try to solve the problem himself, whatever the eventual outcome. However, patches to setup should generally be sent to cygwin-apps (you'd have to subscribe). FWIW, I've looked at the patch, and it seems to be doing what it promises to do (with two minor nits: the global packages_option seems superfluous, since you don't need to use it outside of package_meta.cc, and there is probably no reason to make a distinction on whether something was added via the command line or the user's selection)... Further discussion of this should happen on cygwin-apps. But, more importantly, you don't have to do *any* C++ programming at all to achieve what you want. Simply set up a local package server with one empty package, which is in Base and requires: all the packages you need installed. But I agree that a command-line approach might be more comfortable in some cases. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-'old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- 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/
Can we get a new release of binutils?
Can we get a new release of binutils? Thanks. See: http://www.cygwin.com/ml/cygwin/2006-02/msg00758.html -- 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/
bash Couldn't Allocate Heap error - info.
Hello, This afternoon, for the first time, I began experiencing the C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap ... child_copy: stack write copy failed,... errors that have been reported on this list before. I am getting these errors on every '#! /bin/bash' script, though I can initially open a bash shell. I tried changing the heap sizes, and tried rebaseall - neither made a difference. Earlier today I had installed the drivers for my new Logitech webcam. Suspecting that these might be the problem, I killed all the Logitech processes, restarted all my Cygwin services, restarted Cygwin/X, and lo behold, all the errors disappeared and everything worked fine. It'd be great to get these to work together, but not the end of the world if its not possible. Any thoughts? Thanks, Ant. ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com -- 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/
seg fault in cygwin1.dll during gdb session
HI, I am using a SlickEdit IDE to compile and debug my projects. When debugging a new operator gdb reports a segmentation fault. I found this problem in the archives and the proposed solution is to ignore the fault and continue debugging. Unfortunately this is possible with gdb or ddd but not with slic (No CLI there). My question: Is there a patch for this and how can I install it (does it involves building Cygwin from source or is there another simpler way)? Thanks Shmuel -- 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/
RE: Precision of doubles and stdio
Roberto Bagnara wrote on Monday, March 06, 2006 9:30 AM:: what is and what is not noise depends on the application. In our applications we systematically use controlled rounding on IEEE 754 floating point numbers. In the end, what we obtain (in memory) are definite (i.e., provably correct) lower or upper bounds of some quantities. Call `x' such a quantity, and suppose we have that our computed upper bound for `x' is the IEEE 754 Double Precision number 0x4051b99a, that is (exactly!), 70.905684341886080801486968994140625. If that number is (wrongly!) printed as 70.90568434188608080148696899414 then we lose correctness, since x = 70.905684341886080801486968994140625 does not imply x = 70.90568434188608080148696899414. So, the final 0625 is not noise in our applications: it is what may make the difference between a correct statement and an incorrect one. I'm absolutely amazed that you are a professor of computer science! If I had written software that relied on the _exact_ meaning of the least significant digit of a floating point number (either at university, or at work), I would have been the subject of ritual humiliation! You should NOT be using floating point numbers for such an application. Floating point numbers are _approximate_ representations of the continuous number series that shares the same approximate value. That the IEEE format is an integer multiplied by some power of two is an implementation detail. Floating point hardware is frequently not 100% accurate in the LSB of the mantissa due to internal rounding errors and the datasheets will often tell you so. That being said, the thing which completely floors me is that you are relying on behaviour which is clearly beyond that given in the language specification. This is one of the most rudimentary mistakes in programming. Frankly, this is beyond belief for someone in your position. C doubles are accurate to 16 or 17 decimal places, if you expect 48 significant figures then you deserve all the bad results you get. That you should then choose a public forum (and the wrong one at that!) to complain about this is astounding. Ask yourself this: if your brain surgeon uses an axe, will the inquest find the axe at fault or the surgeon? ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the H.E Information Systems Ltd. Tel:0161 866 9066 Web: www.heis.co.uk This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- 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/
RE: seg fault in cygwin1.dll during gdb session
On 06 March 2006 17:25, Shmuel Vagner wrote: HI, I am using a SlickEdit IDE to compile and debug my projects. When debugging a new operator gdb reports a segmentation fault. I found this problem in the archives and the proposed solution is to ignore the fault and continue debugging. Unfortunately this is possible with gdb or ddd but not with slic (No CLI there). My question: Is there a patch for this By this, do you mean the sheer utter mind-boggling insanity of the design of slic? Or something else? and how can I install it (does it involves building Cygwin from source or is there another simpler way)? There's nothing wrong with Cygwin. The problem is that slic was designed by an insane gibbering maniac and coded by a team of hairy handed programmers just when it happened to be a full moon. The solution would be to shoot it with a silver bullet or drive a stake through its heart. Seriously, though, I find it beyond the bounds of credibility to believe that someone has actually built an IDE that has a built in debugger that doesn't give you any means to continue the program after it hits a breakpoint. Perhaps you have misunderstood how to operate slic? cheers, DaveK -- Can't think of a witty .sigline today -- 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/
RE: Precision of doubles and stdio
On 06 March 2006 17:36, Phil Betts wrote: [ This is *still* nothing to do with cygwin. It's a newlib issue. I have set the Reply-To to take this thread to the talk list and removed the other lists and Jim and Roberto from the Cc line. ] I'm absolutely amazed that you are a professor of computer science! I'm not, but then again, I've been paying attention to what Roberto has posted before, and therefore have some idea of his level of expertise and experience, whereas you are assuming that you know all there is to know and therefore do not need to check your beliefs against reality. If I had written software that relied on the _exact_ meaning of the least significant digit of a floating point number (either at university, or at work), I would have been the subject of ritual humiliation! See, the problem with indulging in this sort of posturing is that you better be /very/ sure that you're right, or you're going to make a fool of yourself. In this case, you have not revealed your great intellect: you have revealed that you have failed to understand what Roberto is doing in his application, and why it is valid. You have mistaken your lack of knowledge for an insight into necessity. Bad call. You should NOT be using floating point numbers for such an application. Floating point numbers are _approximate_ representations of the continuous number series that shares the same approximate value. That the IEEE format is an integer multiplied by some power of two is an implementation detail. You see, not only does your grandmother already /know/ how to suck eggs, but she's also been doing it for years, has learnt a whole load of techniques and methods of which you have never even imagined, and in this particular case has a far more thorough grounding in the fundamental concepts. Floating point numbers are not approximate anything. They are exactly precise representations of a subset of the rational numbers. Those numbers can be exactly represented in floating point. Other numbers cannot. What you choose to do about those other numbers is up to you. You can collapse the range centered around each precisely-representable number onto that number, or you can use the next lowest exact number, or the next highest; then each precise FP number represents a small range on the irrational number line. And in Roberto's application, he is using them to represent - with exact precision - upper and lower error limits for his calculations. You see, Roberto is doing far more advanced maths than anything you have taken into consideration. He is not just blindly throwing some number into a FP representation, passing a couple of operators over it, and then trying to printf a result. He is measuring and tracking the error and uncertainty in those calculations, starting with the potential range of error in the initial FP representation, and taking into account the operations that are performed on it, in order to have an absolutely certain upper and lower bounds of the margin-of-error for the final result. That is something he most certainly can do precisely. Floating point hardware is frequently not 100% accurate in the LSB of the mantissa due to internal rounding errors and the datasheets will often tell you so. This is utter fantasy. Floating point hardware either conforms to IEEE754, which specifies the exact algorithms to be used in different rounding modes, or it is broken. There is no room for ambiguity in the standard. It specifies guard and rounding bits precisely. It does not say that any part of the calculation may be random. IEEE-754 is entirely deterministic, and every implementation should produce EXACTLY the same results, down to the last bits. That being said, the thing which completely floors me is that you are relying on behaviour which is clearly beyond that given in the language specification. Really? Exactly what and where? Nobody has yet pointed to a precise paragraph in the C language spec. If you are as gobsmacked as you claim to be, you should be pretty damn sure exactly what behaviour he is relying on and in what way the says that is unspecified/undefined; I'm sure you've already referred to your copy of the standard to refresh your memory and make sure you aren't mistaken, no? This is one of the most rudimentary mistakes in programming. Frankly, this is beyond belief for someone in your position. C doubles are accurate to 16 or 17 decimal places, if you expect 48 significant figures then you deserve all the bad results you get. This claim (ISTM) is based on the fallacious line of reasoning that if you can represent an N-bit binary integer with D decimal digits, you can also represent an N-bit binary fraction (the mantissa) with D decimal digits. Alas, you cannot. A 3 bit binary number - assuming all three of those bits to be above the decimal place - can represent the numbers 0 to 7, and hence requires only one decimal
Re: Cron jobs in cygwin implementation in windows
On Mon, 6 Mar 2006, Suresh Kumar wrote: Dear Igor: I am a database architect and using cygwin (win implementation) to do some scripting. I am aware that cron is an excellent scheduler and would like to get my hands on this resource. Can u please walk me thru of how I can go about doing this?? BTW, I am a newbie in cygwin and any resource that will educate me on the cron subject would be much appreciated. Thanks Suresh Kumar Suresh, It is generally considered bad netiquette to send unsolicited private mail with Cygwin questions to members of the Cygwin community. There's a mailing list dedicated to all things Cygwin (see http://cygwin.com/acronyms/#PPIOSPE for a list of reasons to use it). I'm redirecting this reply to the list, and setting Reply-To: accordingly. As for cron documentation, whatever is included in the Cygwin cron package is pretty useful -- see first of all the Cygwin-specific cron readme in /usr/share/doc/Cygwin/cron.README, and then the upstream documentation in /usr/share/doc/cron/README (and the man pages at man cron and man crontab). Other people on the list may have more information on this. Please direct any further Cygwin-related cron questions to the main Cygwin list. If you have further general questions about cron, try some other resource, such as a cron-specific newsgroup. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- 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/
RE: Precision of doubles and stdio
On Mon, 2006-03-06 at 18:40 +, Dave Korn wrote: This is utter fantasy. Floating point hardware either conforms to IEEE754, which specifies the exact algorithms to be used in different rounding modes, or it is broken. .. as Intel found out :)) -- John Skaller skaller at users dot sourceforge dot net Async PL, Realtime software consultants Checkout Felix: http://felix.sourceforge.net -- 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/
Re: bash Couldn't Allocate Heap error - info.
Antony Baxter wrote: Hello, This afternoon, for the first time, I began experiencing the C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap ... child_copy: stack write copy failed,... errors that have been reported on this list before. I am getting these errors on every '#! /bin/bash' script, though I can initially open a bash shell. I tried changing the heap sizes, and tried rebaseall - neither made a difference. Earlier today I had installed the drivers for my new Logitech webcam. Suspecting that these might be the problem, I killed all the Logitech processes, restarted all my Cygwin services, restarted Cygwin/X, and lo behold, all the errors disappeared and everything worked fine. It'd be great to get these to work together, but not the end of the world if its not possible. Any thoughts? Thank you Thank you Thank you! That's it exactly. I was wondering why my Cygwin/X stuff started behaving badly. Unfortunately, I had just done a big update, so I blamed that for awhile. But this is definitely it. And after much experimentation, I think you just need to stop one file from running. I'm not sure what was causing it to run, as it wasn't in any of my startup folder. But if you rename /program files/common/logitech/LVMVFM/LVPrcSrv.exe to something else (I called it LVPrcSrv.exe.old), Cygwin/X starts working again, and there is no loss of functionality that I can tell. -- Jonathan Arnold (mailto:[EMAIL PROTECTED]) Jiggle The Handle, a personal bloghttp://jiggle.anaze.us Procrastination is the art of keeping up with yesterday. - Don Marquis -- 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/
Re: bash Couldn't Allocate Heap error - info.
Jonathan Arnold wrote: Antony Baxter wrote: Hello, This afternoon, for the first time, I began experiencing the C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap ... child_copy: stack write copy failed,... errors that have been reported on this list before. I am getting these errors on every '#! /bin/bash' script, though I can initially open a bash shell. I tried changing the heap sizes, and tried rebaseall - neither made a difference. Earlier today I had installed the drivers for my new Logitech webcam. Suspecting that these might be the problem, I killed all the Logitech processes, restarted all my Cygwin services, restarted Cygwin/X, and lo behold, all the errors disappeared and everything worked fine. It'd be great to get these to work together, but not the end of the world if its not possible. Any thoughts? Thank you Thank you Thank you! That's it exactly. I was wondering why my Cygwin/X stuff started behaving badly. Unfortunately, I had just done a big update, so I blamed that for awhile. But this is definitely it. And after much experimentation, I think you just need to stop one file from running. I'm not sure what was causing it to run, as it wasn't in any of my startup folder. But if you rename /program files/common/logitech/LVMVFM/LVPrcSrv.exe to something else (I called it LVPrcSrv.exe.old), Cygwin/X starts working again, and there is no loss of functionality that I can tell. A simple Google unearthed: http://www.liutilities.com/products/wintaskspro/processlibrary/LVPrcSrv/ This sheds a little light on the subject of what this service is there for. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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/
Re: seg fault in cygwin1.dll during gdb session
Shmuel Vagner wrote: My question: Is there a patch for this and how can I install it (does it involves building Cygwin from source or is there another simpler way)? Patches to avoid the spurious SIGSEGV faults are already in CVS for both Cygwin and gdb. But you'll have to build both of them from source. Or at least on the cygwin side you can use a snapshot, but that won't cover the gdb side. Brian -- 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/
cvs 1.11.21-1 still experimental
The experimental version of cvs (1.11.21-1) has been in the experimental state since November. Isn't it ready for 'current' status yet? -- 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/
Re: tput init fails - TERMINFO
Hi, Quite late, but... Cédric Bretaudeau, le Fri 10 Feb 2006 10:25:56 +, a écrit : Brian Dessent, le Fri 10 Feb 2006 01:25:45 -0800, a écrit : Samuel Thibault wrote: in man 5 terminfo, there is no init string indeed. There is is1, is2 and is3 however. See further in man page for details. Yes, but man tput says that tput init should work: Ah indeed. Ok, found the issue: try tput init.exe that should work. The problem is how the is_init variable is set in progs/tput.c:check_aliases(): is_init = (strcmp(name, PROG_INIT) == 0); PROG_INIT is defined in the transform.h file, generated by the Makefile: echo #define PROG_INIT \$(actual_init)\ $@ and actual_init = `echo init$x| $(TRANSFORM)` i.e. PROG_INIT has the pending .exe extension. Check_aliases() should just discard any extension when comparing name and PROG_INIT/PROG_RESET. Regards, Samuel -- 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/
RE: bash Couldn't Allocate Heap error - info.
Thanks for the enlightment. I turned the service to `Manual' for now. Funny to see what the service manager says: Display Name: Logitech Process Manager Description: Webcam Effects Helper Is that supposed to be the ``face overlay'' features, or? Haven't yet scanned the Logitech support site/forum... I wonder :-\ Again, thanks for the enligthment. /norling -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Antony Baxter Sent: Monday, March 06, 2006 6:22 PM To: cygwin@cygwin.com Subject: bash Couldn't Allocate Heap error - info. Hello, This afternoon, for the first time, I began experiencing the C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap ... child_copy: stack write copy failed,... errors that have been reported on this list before. I am getting these errors on every '#! /bin/bash' script, though I can initially open a bash shell. I tried changing the heap sizes, and tried rebaseall - neither made a difference. Earlier today I had installed the drivers for my new Logitech webcam. Suspecting that these might be the problem, I killed all the Logitech processes, restarted all my Cygwin services, restarted Cygwin/X, and lo behold, all the errors disappeared and everything worked fine. It'd be great to get these to work together, but not the end of the world if its not possible. Any thoughts? Thanks, Ant. ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com -- 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/ -- 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/
Re: cvs 1.11.21-1 still experimental
The experimental version of cvs (1.11.21-1) has been in the experimental state since November. Isn't it ready for 'current' status yet? I would like to see this resolved first, if the maintainer is listening: http://cygwin.com/ml/cygwin/2006-01/msg01385.html -- Eric Blake -- 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/
Re: cvs 1.11.21-1 still experimental
Jerry D. Hedden wrote: The experimental version of cvs (1.11.21-1) has been in the experimental state since November. Isn't it ready for 'current' status yet? Dunno. I never got any feedback, so I guess nobody has tested it. Therefore, it's still in testing. -- Chuck -- 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/
RE: bash Couldn't Allocate Heap error - info.
Jonathan, Gunnar, Excellent! Well done. Stopping that service does indeed allow Cygwin to work properly again. Gunnar - yes, its the process that makes the face overlay work. I think I can live without this, though it'll be a great disappointment to my 2.5 yr old nephew who thinks that his uncle has turned into a shark and, to be honest, is now far more interested in talking to me. How about a new marketing slogan: Cygwin - makes children cry? :) Ant. --- Gunnar Norling [EMAIL PROTECTED] wrote: Thanks for the enlightment. I turned the service to `Manual' for now. Funny to see what the service manager says: Display Name: Logitech Process Manager Description: Webcam Effects Helper Is that supposed to be the ``face overlay'' features, or? Haven't yet scanned the Logitech support site/forum... I wonder :-\ Again, thanks for the enligthment. /norling -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Antony Baxter Sent: Monday, March 06, 2006 6:22 PM To: cygwin@cygwin.com Subject: bash Couldn't Allocate Heap error - info. Hello, This afternoon, for the first time, I began experiencing the C:\cygwin\bin\bash.exe: *** fatal error - couldn't allocate heap ... child_copy: stack write copy failed,... errors that have been reported on this list before. I am getting these errors on every '#! /bin/bash' script, though I can initially open a bash shell. I tried changing the heap sizes, and tried rebaseall - neither made a difference. Earlier today I had installed the drivers for my new Logitech webcam. Suspecting that these might be the problem, I killed all the Logitech processes, restarted all my Cygwin services, restarted Cygwin/X, and lo behold, all the errors disappeared and everything worked fine. It'd be great to get these to work together, but not the end of the world if its not possible. Any thoughts? Thanks, Ant. ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com -- 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/ ___ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com -- 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/
Re: cvs 1.11.21-1 still experimental
Eric Blake wrote: The experimental version of cvs (1.11.21-1) has been in the experimental state since November. Isn't it ready for 'current' status yet? I would like to see this resolved first, if the maintainer is listening: http://cygwin.com/ml/cygwin/2006-01/msg01385.html Oh. That. Totally forgot about that. Sorry. I've had no blinding flashes of insight, either. I *do* know that it's not blindly adding a . to the end of the tempdir in order to defeat some name-hiding thing in cygwin. Here's the actually command list being sent back-n-forth (by inserting printfs in the command loop): *** up here server_temp_dir=/tmp/cvs-serv2116 *** *** and /tmp/cvs-serv2116 DOES get created*** Root /usr/local/src/CVSRoot Valid-responses ok error Valid-requests Checked-in New-entry Checksum Copy-file Updated Created Update-existing Merged Patched Rcs-diff Mode Mod-time Removed Remove-entry Set-static-directory Clear-static-directory Set-sticky Clear-sticky Template Notified Module-expansion Wrapper-rcsOption M Mbinary E F MT valid-requests UseUnchanged Global_option -t Argument cygipc Directory . expand-modules Argument -N Argument -P Argument -- Argument cygipc Directory . co *** down here we try to mkdir_p /tmp/cvs-serv2116/. *** I believe it is because the Directory value is being appended to server_temp_dir, which would be fine if Directory were anything but '.' Basically we just need to check if Directory = '.' and skip the dir-creation step. But I don't know where that's happening. I don't have a similar level of debug output from a (working) 1.11.17 build -- that's as far as I've gotten. PTC. -- Chuck -- 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/
Updated: libgii1-1.0.1-1, libgii1-devel-1.0.1-1 and libgii1-input-x-1.0.1-1
A new version of 'libgii' is available for download. It is an upstreams bugfix release, but also includes a packaging fix to enable debugging. - Look at GII_DEBUGSYNC instead of GGI_DEBUGSYNC - Update doc/README.directx to help MinGW users configure properly - input-mouse: ignore undefined bit in IMPS/2 protocol. Now buttons recognized properly. - input-quartz: make mouse moving and mouse wheel work properly - buildsystem: include/ggi/system.h is no longer (unintentionally) distributed. It disturbed out of tree builds. - buildsystem: libtool update / fixes - Prevent (broken) loading of dynamic modules if linking with static libgg. - Fix internal bugs in configuration parsing, which prevented the .include directive to work properly. - gg-tree(3): RedBlack tree fixes - Fixed signal based scheduler so that it finds the ggtick executable even if configuring with the default prefix. Bug reported by Rodney Lamb. New packages: libgii1-1.0.1-1 libgii1-devel-1.0.1-1 libgii1-display-x-1.0.1-1 For a brief description of these packages, see http://cygwin.com/packages/ . To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Run setup.exe to install or update the libgii1 packages. If you have questions or comments, please send them to the Cygwin mailing list. I would appreciate it if you would use the mailing list rather than emailing me directly. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL. Cheers, Peter
Updated: libggi2-2.2.1-1, libggi2-devel-2.2.1-1, libggi2-display-aa-2.2.1-1, libggi2-display-file-2.2.1-1, libggi2-display-terminfo-2.2.1-1, libggi2-display-x-2.2.1-1 and libggi2-samples-2.2.1-1
A new version of 'libggi' is available for download. It is an upstreams bugfix release, but also includes a packaging fix to enable debugging. - Update doc/README.directx to help MinGW users configure properly - display-fbdev(7): correct path in config-file. The mach64 fbdev accelerator-sublib loads again - display-kgi(7): Make it compile with gcc 4. - display-file(7): fix crash on exit - display-aa(7): Documentation fix: aalib reads settings from AAOPTS env. variable - buildsystem: libtool update / fixes New packages: libggi2-2.2.1-1 libggi2-devel-2.2.1-1 libggi2-display-aa-2.2.1-1 libggi2-display-file-2.2.1-1 libggi2-display-terminfo-2.2.1-1 libggi2-display-x-2.2.1-1 libggi2-samples-2.2.1-1 For a brief description of these packages, see http://cygwin.com/packages/ . To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Run setup.exe to install or update the libggi2 packages. If you have questions or comments, please send them to the Cygwin mailing list. I would appreciate it if you would use the mailing list rather than emailing me directly. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL. Cheers, Peter
Updated: libggiwmh2-0.3.1-1, libggiwmh2-devel-0.3.1-1, libggiwmh2-display-x-0.3.1-1 and libggiwmh2-samples-0.3.1-1
A new version of 'libggiwmh' is available for download. It is an upstreams bugfix release, but also includes a packaging fix to enable debugging. - Cleanup properly on failure in ggiWmhInit - buildsystem: libtool update / fixes New packages: libggiwmh2-0.3.1-1 libggiwmh2-devel-0.3.1-1 libggiwmh2-display-x-0.3.1-1 libggiwmh2-samples-0.3.1-1 For a brief description of these packages, see http://cygwin.com/packages/ . To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Run setup.exe to install or update the libggiwmh0 packages. If you have questions or comments, please send them to the Cygwin mailing list. I would appreciate it if you would use the mailing list rather than emailing me directly. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at the above URL. Cheers, Peter
