Re: Save and restore setup.exe window geometry attempt #2
Jonathon Merz wrote: Hi all, I've reworked the patch based on the advice I recieved from my last submission, Thanks for persisting. My questions are: 1. In my current version, the GeometrySetting class just writes/reads a raw WINDOWPLACEMENT struct to/from the geometry settings file. This keeps the code nice and succinct, but is a departure from the way the other settings files are handled in that the resulting file is not human readable/editable. The question is: is it preferred to have the settings files be human readable at the expense of larger code (which would be entirely contained within the new GeometrySetting class's save() and load() functions) or is it acceptable as attached? I'm afraid not, but it's a simple thing to fix. We do want the setting files to be plain ascii text. Makes it a lot easier to debug people's setup problems sometimes if we can get them to post the contents. Should be as easy as reading the io_stream's contents into some sort of strsteambuf (but don't quote me on that until I've had time to look up an STL reference) and using the or operators. 2. At this time, I've got the call to getWindowPlacement within the handling of the WM_SIZE message in the block in the same block as all of the existing resizing code, where it will deliberately not catch when the window is minimized, so setup will never restore in a minimized state. As far as I can tell, there is not any typical way to exit while minimized. You _can_ minimize the window then right-click and close it, but if you want to completely finish setup, you have to click the finish button to execute your choices on the last dialog. My original choice to arrange the code this way was fairly arbitrary, so if anyone thinks it would be useful in some way to catch minimization as well, or if you just think it should catch minimization, by all means let me know. I think that not restoring minimisation is absolutely the correct thing to do. 3. And of course, let me know if you see any other problems, since I think the code is pretty close to complete pending any changes resulting from the answers to 1 and 2. I'll apply your patch to my local tree and have a play with it. cheers, DaveK
[RFU 1.7] subversion-1.6.2-2
wget -x -nH --cut-dirs=2 \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/subversion-1.6.2-2-src.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/subversion-1.6.2-2.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/subversion-apache2/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/subversion-apache2/subversion-apache2-1.6.2-2.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/subversion-devel/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/subversion-devel/subversion-devel-1.6.2-2.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/subversion-perl/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/subversion-perl/subversion-perl-1.6.2-2.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/subversion-python/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/subversion-python/subversion-python-1.6.2-2.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/subversion-ruby/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin-1.7/subversion/subversion-ruby/subversion-ruby-1.6.2-2.tar.bz2 -- David Rothenberger daver...@acm.org Incumbent, n.: Person of liveliest interest to the outcumbents. -- Ambrose Bierce, The Devil's Dictionary
[RFU 1.5] subversion-1.6.2-1
wget -x -nH --cut-dirs=2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-1.6.2-1-src.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-1.6.2-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-apache2/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-apache2/subversion-apache2-1.6.2-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-devel/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-devel/subversion-devel-1.6.2-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-perl/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-perl/subversion-perl-1.6.2-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-python/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-python/subversion-python-1.6.2-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-ruby/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-ruby/subversion-ruby-1.6.2-1.tar.bz2 -- David Rothenberger daver...@acm.org Incumbent, n.: Person of liveliest interest to the outcumbents. -- Ambrose Bierce, The Devil's Dictionary
Re: Save and restore setup.exe window geometry attempt #2
On Wed, May 20, 2009 at 11:50 AM, Dave Korn wrote: Jonathon Merz wrote: 1. In my current version, the GeometrySetting class just writes/reads a raw WINDOWPLACEMENT struct to/from the geometry settings file. This keeps the code nice and succinct, but is a departure from the way the other settings files are handled in that the resulting file is not human readable/editable. The question is: is it preferred to have the settings files be human readable at the expense of larger code (which would be entirely contained within the new GeometrySetting class's save() and load() functions) or is it acceptable as attached? I'm afraid not, but it's a simple thing to fix. We do want the setting files to be plain ascii text. Makes it a lot easier to debug people's setup problems sometimes if we can get them to post the contents. Should be as easy as reading the io_stream's contents into some sort of strsteambuf (but don't quote me on that until I've had time to look up an STL reference) and using the or operators. Makes sense, and was rather what I assumed. I've found istringstream and ostringstream (the [io]strstream's have been marked deprecated at some point.) and they will work fine. Since the WINDOWPLACEMENT struct is more complex than some of the other data recorded in setup's settings files (it consists of 6 values, of which 3 are structs themselves with 2, 2, and 4 values in them), is there any preference regarding file layout? I'm inclined to write them all out as key=value, but it could be as short as a comma separated list. I wouldn't plan to actually parse the key names (the code will read values in an expected order) but having the keys will make it easier to remember which value is which when examining the settings file manually. -Jonathon
Re: Save and restore setup.exe window geometry attempt #2
On Mon, May 18, 2009 at 07:49:48PM -0400, Jonathon Merz wrote: I've reworked the patch based on the advice I recieved from my last submission, and have come to a couple of questions. I've attached a current copy of my patch since that will probably be easier to look at than my descriptions of what the code does. My questions are: 1. In my current version, the GeometrySetting class just writes/reads a raw WINDOWPLACEMENT struct to/from the geometry settings file. This keeps the code nice and succinct, but is a departure from the way the other settings files are handled in that the resulting file is not human readable/editable. The question is: is it preferred to have the settings files be human readable at the expense of larger code (which would be entirely contained within the new GeometrySetting class's save() and load() functions) or is it acceptable as attached? 2. At this time, I've got the call to getWindowPlacement within the handling of the WM_SIZE message in the block in the same block as all of the existing resizing code, where it will deliberately not catch when the window is minimized, so setup will never restore in a minimized state. As far as I can tell, there is not any typical way to exit while minimized. You _can_ minimize the window then right-click and close it, but if you want to completely finish setup, you have to click the finish button to execute your choices on the last dialog. My original choice to arrange the code this way was fairly arbitrary, so if anyone thinks it would be useful in some way to catch minimization as well, or if you just think it should catch minimization, by all means let me know. 3. And of course, let me know if you see any other problems, since I think the code is pretty close to complete pending any changes resulting from the answers to 1 and 2. This patch doesn't do what I expected. I thought that it would affect the package chooser screen maximized settings but it doesn't seem to touch that. I did manage to do something that made the initial screen maximized, though, although I never maximized any of the original screens. It seems to affect the size of every screen but the package chooser screen which doesn't seem useful to me. But, I'm probably not the best judge. In case it isn't really clear, please don't anyon apply this patch until I've indicated that it I'm satisfied with its usability + code maintenance tradeoffs. cgf
Times are difficult now
Hey There We can make a $1,200 cash advance to you and deposit it to your account in less than 24 hours. Let us help you if you need it. Get what yopu need today, we are standing by: http://cid-310aea044a130436.spaces.live.com/ -- 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/
winsup/cygwin ChangeLog net.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2009-05-20 14:56:48 Modified files: cygwin : ChangeLog net.cc Log message: * net.cc (gethostby_helper): Use correct signedness. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4492r2=1.4493 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/net.cc.diff?cvsroot=uberbaumr1=1.254r2=1.255
avoid compiler warning with DEBUGGING
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I noticed a complaint about comparing signed and unsigned values, when compiling with DEBUGGING enabled. net.cc also has a lot of trailing blanks. 2009-05-20 Eric Blake e...@byu.net * net.cc (gethostby_helper): Use correct signedness. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoT/McACgkQ84KuGfSFAYB5yACbBSHBbYlplWSHVtl32doXLLRP tFYAni2YcsLFsNUgUp62jYlqGc82jD/y =WPYH -END PGP SIGNATURE- diff --git a/winsup/cygwin/net.cc b/winsup/cygwin/net.cc index cb0a5cd..79b2dfa 100644 --- a/winsup/cygwin/net.cc +++ b/winsup/cygwin/net.cc @@ -960,7 +960,8 @@ gethostby_helper (const char *name, const int af, const int type, record * anptr = NULL, * prevptr = NULL, * curptr; int i, alias_count = 0, string_size = 0, address_count = 0; - int complen, namelen1 = 0, address_len = 0, antype, anclass, ansize; + unsigned int complen; + int namelen1 = 0, address_len = 0, antype, anclass, ansize; /* Get the count of answers */ ancount = ntohs (((HEADER *) msg)-ancount); -- 1.6.2.4
Re: avoid compiler warning with DEBUGGING
On Wed, May 20, 2009 at 06:51:19AM -0600, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I noticed a complaint about comparing signed and unsigned values, when compiling with DEBUGGING enabled. net.cc also has a lot of trailing blanks. 2009-05-20 Eric Blake e...@byu.net * net.cc (gethostby_helper): Use correct signedness. I've applied this even though I couldn't duplicate the problem with gcc 4. I think that may be a first since gcc 4 is much more picky than gcc 3.4. Thanks. cgf
R: Package dependency issues for octave-devel
--- Mar 19/5/09, Kris Thielemans ha scritto: Da: Kris Thielemans Oggetto: Package dependency issues for octave-devel A: cygwin Data: Martedì 19 maggio 2009, 22:01 Hi I have octave-3.0.3-1 and octave-devel installed, but had problems using mkoctfile. I had to download gcc4-fortran (for -lgfortranbegin), libhdf_0 (for -lhdf5) and readline (for -lreadline). After that, it seems to work nicely. Thanks Kris on cygwin-1.5 the requirement for octave are: cygwin lapack gnuplot less libreadline6 texinfo libfftw3_3 libhdf5_0 so libhdf5_0 and libreadline6 should be already there. Or are you speaking about the devel packages ? On octave-devel I forgot to bump the requirement from gcc-g++ gcc-g77 to gcc4-g++ gcc4-fortran but if you are developing, you should know that you need the compiler :-)) On cygwin-1.7 I removed the gcc-g++ gcc-g77 requirement at all. So please be aware of it. Regards Marco cygwin octave maintainer -- 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: Security Concern: setup.exe signature difficult to verify
Greg Chicares Wrote: Here's a native msw binary: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.9.exe Thanks for the response Greg. This still raises 2 concerns: 1) If this method is the official cygwin authenticity verification procedure, it should be well documented on the website, as the process is non-trivial. 2) The gnupg-w32cli-1.4.9.exe itself also isn't signed. So we still have the bootstrapping problem. Bottom line, the install procedure is still insecure and vulnerable to attack until a pervasive authentication mechanism is used (either signed windows executable or SSL download with a verifiable cert). With organized and highly sophisticated attackers becoming even more wide spread (often backed by organized crime or other well funded agencies), security is important, especially for a project as prestigious and important as Cygwin. Of course, I'll mention this to the gnupg.org people too, as they have the same problem. Thanks for the response. Best Regards, Doug -- 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/
dialog ?
Hi, In early versions of cygwin, I've used dialog for some scripts. Now I want to start the script and dialog is not installed on the current cygwin version. I tried to install it with Cygwin-setup, but I can't find a packet named dialog. Which packet do I have to install for dialog? thanks in advance Markus -- 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: dialog ?
Markus Wenke wrote: In early versions of cygwin, I've used dialog for some scripts. Now I want to start the script and dialog is not installed on the current cygwin version. I tried to install it with Cygwin-setup, but I can't find a packet named dialog. Which packet do I have to install for dialog? For this sort of question, you can either use the package search at http://cygwin.com/packages/ or simply use cygcheck: $ cygcheck -p dialog.exe Found 2 matches for dialog.exe. tetex-bin/tetex-bin-2.0.2-15The TeX text formatting system (binaries). tetex-bin/tetex-bin-3.0.0-3 The TeX text formatting system (binaries). In this case however, tetex-bin does not contain dialog.exe but tcdialog.exe. That file does seem to be dialog.exe by a different name though, so you might want to add alias dialog=tcdialog to ~/.bashrc This might be a packaging bug: typing man tcdialog brings up the dialog(1) man page, which suggests that something is not quite right. Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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/
FTP Client of Linux
Hi all, I´m trying to use the ftp client of linux on windows through cygwin, but it uses the native ftp client of windows. Can I use the native ftp client of Linux on Cygwin? I need this because the sintax between them is different. -- Att. Bruno Galindro da Costa bruno.galin...@gmail.com Florianópolis - SC -- 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: FTP Client of Linux
Bruno Galindro da Costa wrote: Hi all, I´m trying to use the ftp client of linux on windows through cygwin, but it uses the native ftp client of windows. Can I use the native ftp client of Linux on Cygwin? I need this because the sintax between them is different. Use setup.exe to install the inetutils package, that has a Linux-alike FTP client in it. cheers, DaveK -- 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: dialog ?
Phil Betts wrote on Wednesday, May 20, 2009 6:08 AM: Markus Wenke wrote: In early versions of cygwin, I've used dialog for some scripts. Now I want to start the script and dialog is not installed on the current cygwin version. I tried to install it with Cygwin-setup, but I can't find a packet named dialog. Which packet do I have to install for dialog? For this sort of question, you can either use the package search at http://cygwin.com/packages/ or simply use cygcheck: $ cygcheck -p dialog.exe Found 2 matches for dialog.exe. tetex-bin/tetex-bin-2.0.2-15The TeX text formatting system (binaries). tetex-bin/tetex-bin-3.0.0-3 The TeX text formatting system (binaries). In this case however, tetex-bin does not contain dialog.exe but tcdialog.exe. That file does seem to be dialog.exe by a different name though, so you might want to add alias dialog=tcdialog to ~/.bashrc This might be a packaging bug: typing man tcdialog brings up the dialog(1) man page, which suggests that something is not quite right. Cygwin Ports http://sourceware.org/cygwinports/ has dialog 1.1.20080316 -- 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: FTP Client of Linux
Dave, Thank you very much, it works great! 2009/5/20 Dave Korn dave.korn.cyg...@googlemail.com: Bruno Galindro da Costa wrote: Hi all, I´m trying to use the ftp client of linux on windows through cygwin, but it uses the native ftp client of windows. Can I use the native ftp client of Linux on Cygwin? I need this because the sintax between them is different. Use setup.exe to install the inetutils package, that has a Linux-alike FTP client in it. cheers, DaveK -- 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/ -- Att. Bruno Galindro da Costa bruno.galin...@gmail.com Florianópolis - SC -- 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: iconv: Xft UTF-8 rendering
Yaakov (Cygwin/X) wrote: I'm having some issues with iconv, Xft, and UTF-8 rendering. Could you please help me look into this: http://sourceware.org/bugzilla/show_bug.cgi?id=10122 The easiest of those to reproduce is probably blackbox: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/x11/blackbox/ If you omit 0.70.1-disable-unicode-fonts.patch, build blackbox, and run it within a standard X display (not multiwindow), you'll see what I mean; you don't have to install it to run it for this purpose. Right now, I want to figure out if the problem is with Cygwin, iconv, libXft, or these packages (although I doubt the latter). Any assistance you can provide would be appreciated. I think iconv is exonerated. This seems to be breakage due to a sizeof(wchar_t) == 4 assumption in blackbox. The file in question has a trolltech copyright on it so it wouldn't surprise me if the same code turns up in Qt :-) I've an attached an example patch to fix it in bugzilla. -- 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: FTP Client of Linux
Bruno Galindro da Costa wrote: Dave, Thank you very much, it works great! You may also want to look into other ftp clients which, while the syntax is different, offer much more power like ncftp and lftp. -- Andrew DeFaria http://defaria.com Do I BELIEVE in the Bible? Hell, I've actually SEEN one! -- 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 I speed up running configure script?
I type ./configure in xterm to configure package. The script runs very slowly - above 40 minutes. I suppose it should run faster on the E8400 2x3GHz CPU. Can I speed up / boost this ? Windows Task Manager shows idle process takes ~70%. Sorry if the question is stupid, I am beginner at cygwin. Host is Vista Home Premium 32, and cygwin is 1.5.25-15. Regards, Mark -- View this message in context: http://www.nabble.com/Can-I-speed-up-running-%22configure%22-script--tp23637104p23637104.html Sent from the Cygwin list mailing list archive at Nabble.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: Warning: auto-export
faiz2009 wrote: J'utilise une librairie cogitant sous cygwin, et lors de l'édition des liens j'obtiens le warning suivant: Warning: auto-importing has been activated without --enable-auto-export specified in the line commande. This should work unless it involoves constant data structure referencing symbols from auto-imported DLL. Info: Resolving cogitant::IOHundler::LINEARFORM by linking to __imp___ZN8cogitant9IOHundler10LINEARform (auto-import). Que est ce que cela signifie et comment peut on le résoudre Ajoúter vos LDFLAGS avec -Wl,--enable-auto-export, dans la Makefile. cheers, DaveK -- 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: Python enabled GDB (Archer) -Help
2009/5/19 Jason Tishler ja...@tishler.net:
Sreejith,
On Tue, May 19, 2009 at 04:04:06PM +0530, Sreejith wrote:
The observation is that python static library (in case of linux-
libpython2.5.so in /usr/lib/) is missing in cygwin and that is exactly
what gcc is complaining when building gdb (please refer to the config
log in my previous post). I dont know whether this is handled
differently in cygwin. Please give your suggestions.
Can you get configure to add -L/usr/lib/python2.5/config when linking?
I think the following should work:
$ LDFLAGS=-L/usr/lib/python2.5/config configure ...
Does this solve the problem?
Thanks a lot. It solved the issue partially. I could enable the python
scripting in GDB. But still the STL containers are not printing data.
It worked straight in debian. The following log (Cygwin) explains
more:
(gdb) python print 10
10
Python is
enabled
(gdb) print myList
$1 = {_List_baseint, std::allocatorint = {
_M_impl = {allocatorstd::_List_nodeint = {new_allocatorstd::_List_n
odeint = {No data fields}, No data fields}, _M_node = {
_M_next = 0x681838, _M_prev = 0x6818c8}}}, No data fields}
libstdc++ printer is not used
(gdb) python print myList
Traceback (most recent call last):
File string, line 1, in module
NameError: name 'myList' is not defined
Error while executing Python code.
I will ask in archer list.
(gdb)
But I dont know whether it has some thing to do with Cygwin. I will
ask in archer mailing list too. Mean while if anyone has some clue,
please share.
-Sreejith
--
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/
rsync repeates transfers Vista--Ubuntu
Hi all, this is my first post here, so I hope that I am posting in the right place. I am trying to set up a backup system using rsync to transfer files from a client running Vista and rsync in cygwin to a server running Linux (Ubuntu 8.10). The server has an external drive formatted FAT32. The client initiates the transfer and uses the rsync daemon (though the same thing happened over SSH). When I back up the client's c drive to the server's external drive, the transfer seems to go fine. However, if I run it again immediately, it does another huge file transfer, repeating much of what it has already done. The modification dates on the files don't always match on the client and server--some are listed one hour off if they are in standard, rather than daylight, time. I don't know if the actual times are different, it might just be the OSs different ways of displaying them. Anyway, that does not seem to affect which files are recopied. Even with rsync using --modify-window=4000 to give more than an hour of slop on the time, it does the same thing. My only remaining thought is that the FAT format on the server's external drive might be causing trouble. Any ideas what might be causing this and how to get around it? I'm not an expert, so I'm hoping it's something silly that I've overlooked. Thanks in advance for any advice! Weston -- 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: [Fwd: [1.7] wcwidth failing configure tests]
Corinna Vinschen wrote: On May 12 17:56, Andy Koppe wrote: And here's another question. ?The utf8*.h files claim they have been generated from the unicode.txt file of the Unicode 3.2 standard. ?Do we have the script which generated the utf8*.h files? ?Can we regenerate the files to match the current Unicode 5.1 standard? I've updated my editor mined to Unicode 5.1 data already. I can provide an according wcwidth function if that's desired. I also have scripts for semi-automatic generation of this information, however semi as I said, to be improved. There's Markus Kuhn's wcwidth implementation, which says it's based on Unicode 5.0: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c This looks nice. I'm sure Markus will update to 5.1 one day too... Trouble is, there's the thorny issue of the CJK Ambiguous Width category of characters, which consists of things like Greek and Cyrillic letters as well as line drawing symbols. Those have a width of 1 in Western use, yet with CJK fonts they have a width of 2. That's why Markus Kuhn's code includes the mk_wcswidth_cjk() variant. We should use the standard variation alone, imho. And we need some workaround for UTF-16 systems like Cygwin. Unfortunately, surrogate pairs only work well as part of a string, not as standalone chars. So wcwidth would return -1 for each single char, but wcswidth could be tweaked to handle them gracefully. This gets me to the related question how to output non-BMP characters; currently, the cygwin console display them all as two square boxes, using two screen columns. This indicates that probably just the single surrogate characters are being output. Could proper non-BMP character display be achieved by simply combining the surrogates and outputting them to Windows as a true Unicode character? (The Windows function would need to be 32 bit which I don't know, the string elements could stay as they are.) Just an idea which might lead to a simple solution. On May 15 00:58, IWAMURO Motonori wrote: 2009/5/13 Corinna Vinschen vinsc...@redhat.com: Trouble is, there's the thorny issue of the CJK Ambiguous Width ... (see above) We should use the standard variation alone, imho. I don't think so. 1) It is very very inconvenient for me :-) 2) Unicode Standard Annex #11 http://www.unicode.org/unicode/reports/tr11/ recommends: 5 Recommendations (snip) When processing or displaying data (snip) Ambiguous characters behave like wide or narrow characters depending on the context (language tag, script identification, associated font, source of data, or explicit markup; all can provide the context). If the context cannot be established reliably, they should be treated as narrow characters by default. The recommendation is independent of legacy encoding. I think that a new locale category that specifies the context is necessary. Because the context influences only the display or text layout. However, there is no such standard now. Therefore, I propose to use *_cjk() when the language part of LC_CTYPE is 'ja', 'ko', 'vi' or 'zh'. The problem with this is 1. As you say, there is no standard. 2. If you wish to handle character widths compliant with the terminal your application is running in, there is no guarantee that your assumption of CJK width (or the actual locale setting if that model would be implemented) does indeed reflect the terminal's width properties. 3. In mintty, you can dynamically change width properties by selecting different fonts; mintty changes CJK width behaviour according to certain font properties. static configuration in your shell using a locale variable would not reflect this change I see two ways to handle this: a) Ask Andy (author of mintty) to not do this switching; however, I don't know what display consequences that might have. On the other hand, other terminals don't switch either. Or maybe mintty could at leasts issue a warning on CJK width switching, or maintain two separate font lists, or... b) Determine the actual CJK width behaviour dynamically. That's what mined does (in addition to other width property detection in general). That's why it can handle the alternative quite seamlessly. That would be fine with me, but tests for the actual language are not used anywhere in newlib, so that's something very new. So I would suggest not to introduce it before the concept is sufficiently discussed. And I'm not happy with the idea of a cygwin-specific solution (or workaround). Kind regards, Thomas -- 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: Can I speed up running configure script?
Ravenik wrote: I type ./configure in xterm to configure package. The script runs very slowly - above 40 minutes. I suppose it should run faster on the E8400 2x3GHz CPU. Can I speed up / boost this ? Windows Task Manager shows idle process takes ~70%. Sorry if the question is stupid, I am beginner at cygwin. Host is Vista Home Premium 32, and cygwin is 1.5.25-15. Usually, when something takes this long, is not using 100% CPU, but is nevertheless progressing, it's because of network timeouts. Is it possible that you have a reference to a non-existent network share in your PATH? If not, you could try identifying where configure is spending its time by adding set -x near the top of the script (without the quotes, and after the line starting #!.) That will slow things down even more, but as the output scrolls by, you might spot it taking longer than you'd expect somewhere. If you don't get anywhere, please follow the instructions here: Problem reports: http://cygwin.com/problems.html particularly the bit about *attaching* the output from cygcheck -svr You might also check whether you're suffering from BLODA. See http://cygwin.com/faq/faq.using.html#faq.using.bloda and http://cygwin.com/acronyms/#BLODA Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- 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: Warning: auto-export
faiz2009 wrote: I am very sorry Vincent R if i posted in french, i don't know that is forbidden, and thanks for your response Dave. Is there an other way to add flags directly in the line commande c++ -o prog prog.cpp because i do not know how to use the Makefile. Just add LDFLAGS=-Wl,--enable-auto-import to your ./configure command line. The configure script will put it into the makefile for you. cheers, DaveK -- 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: Warning: auto-export
I am very sorry Vincent R if i posted in french, i don't know that is forbidden, and thanks for your response Dave. Is there an other way to add flags directly in the line commande c++ -o prog prog.cpp because i do not know how to use the Makefile. Dave Korn-6 wrote: faiz2009 wrote: J'utilise une librairie cogitant sous cygwin, et lors de l'édition des liens j'obtiens le warning suivant: Warning: auto-importing has been activated without --enable-auto-export specified in the line commande. This should work unless it involoves constant data structure referencing symbols from auto-imported DLL. Info: Resolving cogitant::IOHundler::LINEARFORM by linking to __imp___ZN8cogitant9IOHundler10LINEARform (auto-import). Que est ce que cela signifie et comment peut on le résoudre Ajoúter vos LDFLAGS avec -Wl,--enable-auto-export, dans la Makefile. cheers, DaveK -- 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/ -- View this message in context: http://www.nabble.com/Warning%3A-auto-export-tp23638372p23640194.html Sent from the Cygwin list mailing list archive at Nabble.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/
Warning: auto-export
Bonjour, J'ai cherché une solution avant de poster ce message, j'ai trouvé que ce sujet est traité mais dans le cas ou on compile on utilisant un fichier Makefile. Par contre moi j'utilise la compilation par: c++ -c prog.cpp et c++ -o prog prog.o -lcogitant J'utilise une librairie cogitant sous cygwin, et lors de l'édition des liens j'obtiens le warning suivant: Warning: auto-importing has been activated without --enable-auto-export specified in the line commande. This should work unless it involoves constant data structure referencing symbols from auto-imported DLL. Info: Resolving cogitant::IOHundler::LINEARFORM by linking to __imp___ZN8cogitant9IOHundler10LINEARform (auto-import). Que est ce que cela signifie et comment peut on le résoudre Merci à vous tous -- View this message in context: http://www.nabble.com/Warning%3A-auto-export-tp23638372p23638372.html Sent from the Cygwin list mailing list archive at Nabble.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: [Fwd: [1.7] wcwidth failing configure tests]
2009/5/21 Thomas Wolff t...@towo.net: Therefore, I propose to use *_cjk() when the language part of LC_CTYPE is 'ja', 'ko', 'vi' or 'zh'. The problem with this is 1. As you say, there is no standard. But, - I think that my proposal doesn't violate any specification. - I heard that there is an existing implementation that behave like my proposal. (Sorry, I didn't hear the system name.) 2. If you wish to handle character widths compliant with the terminal your application is running in, there is no guarantee that your assumption of CJK width (or the actual locale setting if that model would be implemented) does indeed reflect the terminal's width properties. Yes, I understand it, too. My proposal is completely workaround. But it is the best solution because we have no specification/standard for my wish. 3. In mintty, you can dynamically change width properties by selecting different fonts; mintty changes CJK width behaviour according to certain font properties. static configuration in your shell using a locale variable would not reflect this change It is no problem because we -- most Japanese language users -- need not change the settings of mintty and locale after first setup. We set LANG=ja_JP.UTF-8 and select a Japanese font for mintty. I see two ways to handle this: a) Ask Andy (author of mintty) to not do this switching; It is not necessary bacause the mechanism is based on my another poroposal. (deenheart is my handle on google code.) other terminals don't switch either. If we use other terminals, we need switch CJK width option manually. (xterm, mlterm, putty, ...) b) Determine the actual CJK width behaviour dynamically. That's what mined does (in addition to other width property detection in general). It is the best solution. I think that we need specify the following: - the escape sequence about language context for terminal emulater. -- setting language context -- getting language context -- getting capability of language context (context is fixed, static or dynamic / acceptable languages) - new multilingualized string/terminal API for terminal based applications. And, we need rewrite too many applications by new API. I'm not happy with the idea of a cygwin-specific solution (or workaround). I think that it is not cygwin-specific solution. -- IWAMURO Motnori http://vmi.jp/ -- 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: expr error
Xima Lenik wrote: Yes, I've rebased. After extracted cyggmp-3.dll from libgmp3-4.3, it's In may case, reinstalling libgmp3 pulled back emacs 21.2!? After installing emacs 23.0.92 again, I find myself with: - the same exec error at startup - libgmp3 4.3.0-1 Incomplete Marc -- View this message in context: http://www.nabble.com/expr-error-tp23583036p23642946.html Sent from the Cygwin list mailing list archive at Nabble.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: expr error
Marc Girod wrote: In my case, reinstalling libgmp3 pulled back emacs 21.2!? OK... I have to mark emacs 23.0.92 as keep... Anyway, now I installed libgmp3 4.2.4-2 (no older option) and even if it is still incomplete too, the exec error disappeared. -- View this message in context: http://www.nabble.com/expr-error-tp23583036p23643116.html Sent from the Cygwin list mailing list archive at Nabble.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/
Long file names not working in cygwin-1.7.0-48
I can't access long path and file names after updating to cygwin-1.7.0-48. Reverting to cygwin-1.7.0-47 fixes the problem. I also tried the 2009-05-18 Snapshot DLL. Hopefully this isn't a user error. -- 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: expr error
On 5/20/2009 4:42 PM, Marc Girod wrote: OK... I have to mark emacs 23.0.92 as keep... This is, unfortunately, a nuisance that you have to put up with when you're using experimental packages. I hope to promote emacs 23.0.92 to current relatively soon, but I think I need to let it get more testing first. I will soon be releasing emacs 23.0.92 for cygwin 1.5, so that should increase the number of people who try it. Ken -- 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/
file execute access with noacl mount with Cygwin-1.7.0 20090518 snapshot
Hi All... I just tried executing a file on my desktop as /c/Users/me/Desktop/file.exe in Vista Business SP1. The file would not tab complete in bash and an ls -al showed no execute access. Do I need to add the exec or cygexec explicitly, or should that be the default with noacl? Thanks, ...Karl _ Insert movie times and more without leaving Hotmail®. http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd1_052009 -- 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: file execute access with noacl mount with Cygwin-1.7.0 20090518 snapshot
From: Subject: file execute access with noacl mount with Cygwin-1.7.0 20090518 snapshot Date: Wed, 20 May 2009 20:59:20 -0700 Hi All... I just tried executing a file on my desktop as /c/Users/me/Desktop/file.exe in Vista Business SP1. The file would not tab complete in bash and an ls -al showed no execute access. Do I need to add the exec or cygexec explicitly, or should that be the default with noacl? Thanks, ...Karl I'm ok with adding it explicitly, and perhaps that is cleaner in the long run with no hidden assumptions. It is just that my file ended in .exe and the documentation says: While normally the execute permission bits are used to evaluate executability, this is not possible on filesystems which don't support permissions at all (like FAT/FAT32), or if ACLs are ignored on filesystems supporting them (see the aforementioned acl mount option). In these cases, the following heuristic is used to evaluate if a file is executable: Files ending in certain extensions (.exe, .com, .bat, .btm, .cmd) are assumed to be executable. So the current behavior is not what I expected. Thanks, ...Karl _ Hotmail® has ever-growing storage! Don’t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009 -- 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: file execute access with noacl mount with Cygwin-1.7.0 20090518 snapshot
Karl M wrote: Karl M wrote: Hi All... I just tried executing a file on my desktop as /c/Users/me/Desktop/file.exe in Vista Business SP1. The file would not tab complete in bash and an ls -al showed no execute access. Do I need to add the exec or cygexec explicitly, or should that be the default with noacl? Thanks, ...Karl I'm ok with adding it explicitly, and perhaps that is cleaner in the long run with no hidden assumptions. It is just that my file ended in .exe and the documentation says: While normally the execute permission bits are used to evaluate executability, this is not possible on filesystems which don't support permissions at all (like FAT/FAT32), or if ACLs are ignored on filesystems supporting them (see the aforementioned acl mount option). In these cases, the following heuristic is used to evaluate if a file is executable: Files ending in certain extensions (.exe, .com, .bat, .btm, .cmd) are assumed to be executable. So the current behavior is not what I expected. Does 'file.exe' report itself as executable if you move it to somewhere that's not under '/c/Users/'? Is there a reason you don't want 'acl' (other than the fact that you're working under '/c/Users' on Vista)? While setting 'exec' or 'cygexec' may help in your situation, I'm not at all clear why you think it's 'cleaner'. Perhaps you could be more explicit. See http://cygwin.com/problems.html for guidelines on providing a complete problem report, which might help us all understand the heart of your question. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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/
