From jelson@gmail.com Thu Aug 1 00:55:00 2013 From: jelson@gmail.com (Jeremy Elson) Date: Thu, 01 Aug 2013 00:55:00 -0000 Subject: xterm title setting breaks when upgrading from 32-bit to 64-bit cygwin Message-ID: I recently upgraded from the 32-bit to the 64-bit build of Cygwin 1.7.22 on Windows 8 x64. For the most part, everything works identically (except faster!). But I have noticed one problem: xterm no longer seems to respond to the magic escape codes that change its title. My shell uses this to update the title to reflect the current hostname and working directory, but after the upgrade all my xterms just have the same title: "tcsh". I haven't seen any mention of this bug on the mailing lists. Is anyone else experiencing this problem? -- 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/ From angelo.graziosi@alice.it Thu Aug 1 11:20:00 2013 From: angelo.graziosi@alice.it (Angelo Graziosi) Date: Thu, 01 Aug 2013 11:20:00 -0000 Subject: Cygwin 1.7.22 calls dumper when starting X Message-ID: <51FA445D.40606@alice.it> Charles Wilson wrote: > Is there a way to test run-2.0? What is the syntax to replace: > > C:\Cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe > > Sure: and how to replace C:\cygwin-2\bin\run.exe bash -l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl -multiwindow -clipboard -silent-dup-error 2>/dev/null &' (which works fine with run-1.2!) I have tried this: $ cat /home/angelo/XWinServer.xml -l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl -multiwindow -clipboard -silent-dup-error 2>/dev/null &' with this target in the link (.lnk): C:\cygwin-2\bin\run2.exe /home/angelo/XWinServer.xml but it doesn't work... Ciao, Angelo. -- 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/ From cygwin@cwilson.fastmail.fm Thu Aug 1 13:09:00 2013 From: cygwin@cwilson.fastmail.fm (Charles Wilson) Date: Thu, 01 Aug 2013 13:09:00 -0000 Subject: Cygwin 1.7.22 calls dumper when starting X In-Reply-To: <51FA445D.40606@alice.it> References: <51FA445D.40606@alice.it> Message-ID: <51FA5DFA.8030207@cwilson.fastmail.fm> On 8/1/2013 7:19 AM, Angelo Graziosi wrote: > Charles Wilson wrote: >> Is there a way to test run-2.0? What is the syntax to replace: >> >> C:\Cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe >> >> Sure: > > and how to replace > > C:\cygwin-2\bin\run.exe bash -l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; > XWin -nowgl -multiwindow -clipboard -silent-dup-error 2>/dev/null &' > > > (which works fine with run-1.2!) > > I have tried this: > > $ cat /home/angelo/XWinServer.xml > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:noNamespaceSchemaLocation="run2.xsd"> > > > > > -l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl > -multiwindow -clipboard -silent-dup-error 2>/dev/null &' > > > > > with this target in the link (.lnk): > > C:\cygwin-2\bin\run2.exe /home/angelo/XWinServer.xml Two errors: the extra semicolon after XMLSchema-instance, and you do need to use the '&' construction instead of '&'. See attached. (I'm not sure why you need & at all; unless it allows the bash shell to exit, where otherwise it would hang around?) FWIW, I've never tested run2 with multibyte UTF-8, so...you might be better off setting the encoding to us-ascii. -- Chuck -------------- next part -------------- A non-text attachment was scrubbed... Name: XWinServer.xml Type: text/xml Size: 438 bytes Desc: not available URL: -------------- next part -------------- -- 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/ From jon.turney@dronecode.org.uk Thu Aug 1 17:29:00 2013 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Thu, 01 Aug 2013 17:29:00 -0000 Subject: xterm title setting breaks when upgrading from 32-bit to 64-bit cygwin In-Reply-To: References: Message-ID: <51FA9AD3.2010906@dronecode.org.uk> On 01/08/2013 01:55, Jeremy Elson wrote: > I recently upgraded from the 32-bit to the 64-bit build of Cygwin > 1.7.22 on Windows 8 x64. For the most part, everything works > identically (except faster!). But I have noticed one problem: xterm no > longer seems to respond to the magic escape codes that change its > title. My shell uses this to update the title to reflect the current > hostname and working directory, but after the upgrade all my xterms > just have the same title: "tcsh". > > I haven't seen any mention of this bug on the mailing lists. Is anyone > else experiencing this problem? Thanks for pointing out this problem. It seems that x86_64 X server has a bug that meant that no window could change it's title after it started. I've uploaded a snapshot at [1]. Perhaps you could try that and see if it improves things for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.x86_64.20130801-git-beadc5a3202e096a.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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/ From jelson@gmail.com Thu Aug 1 18:51:00 2013 From: jelson@gmail.com (Jeremy Elson) Date: Thu, 01 Aug 2013 18:51:00 -0000 Subject: xterm title setting breaks when upgrading from 32-bit to 64-bit cygwin In-Reply-To: <51FA9AD3.2010906@dronecode.org.uk> References: <51FA9AD3.2010906@dronecode.org.uk> Message-ID: On Thu, Aug 1, 2013 at 10:28 AM, Jon TURNEY wrote: > On 01/08/2013 01:55, Jeremy Elson wrote: > > I recently upgraded from the 32-bit to the 64-bit build of Cygwin > > 1.7.22 on Windows 8 x64. For the most part, everything works > > identically (except faster!). But I have noticed one problem: xterm no > > longer seems to respond to the magic escape codes that change its > > title. My shell uses this to update the title to reflect the current > > hostname and working directory, but after the upgrade all my xterms > > just have the same title: "tcsh". > > > > I haven't seen any mention of this bug on the mailing lists. Is anyone > > else experiencing this problem? > > Thanks for pointing out this problem. > > It seems that x86_64 X server has a bug that meant that no window could > change > it's title after it started. > > I've uploaded a snapshot at [1]. Perhaps you could try that and see if it > improves things for you? > > [1] > ftp://cygwin.com/pub/cygwinx/XWin.x86_64.20130801-git-beadc5a3202e096a.exe.bz2 > Thanks for the very fast followup - yes, using the XWin binary below, my xterm can now set its title correctly! Thanks again, and regards, Jeremy -- 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/ From angelo.graziosi@alice.it Thu Aug 1 21:34:00 2013 From: angelo.graziosi@alice.it (Angelo Graziosi) Date: Thu, 01 Aug 2013 21:34:00 -0000 Subject: Cygwin 1.7.22 calls dumper when starting X Message-ID: <51FAD439.6050302@alice.it> Charles Wilson wrote: > (I'm not sure why you need & at all; unless it allows the bash shell to exit, where otherwise it would hang around?) Without the "&", there is an extra bash process running: I want just to start XWin... > See attached. > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:noNamespaceSchemaLocation="run2.xsd"> > > > > > -l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl -multiwindow -clipboard -silent-dup-error 2>/dev/null &' > > > I have copy/pasted it, but it doesn't work (I have also tried with us-ascii) If I add the debug options you suggested, I got opt_loglevel: 9 opt_nogui : 0 opt_notty : 1 opt_timeout : 0.50 opt_wait : 0 opt_force : auto (run2_xml_stardocument) ctx=0x22aa8c (run2_xml_enddocument) ctx=0x22aa8c /home/angelo/XWinServer.xml: validation generated an internal error There was an error parsing XWinServer.xml exit status 1 Ciao, Angelo. -- 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/ From meh@winfirst.com Thu Aug 1 22:06:00 2013 From: meh@winfirst.com (Mark Hansen) Date: Thu, 01 Aug 2013 22:06:00 -0000 Subject: Cygwin 1.7.22 calls dumper when starting X In-Reply-To: <51FAD439.6050302@alice.it> References: <51FAD439.6050302@alice.it> Message-ID: <51FADBE3.4030700@winfirst.com> See below... On 8/1/2013 2:33 PM, Angelo Graziosi wrote: > Charles Wilson wrote: >> (I'm not sure why you need & at all; unless it allows the bash shell to exit, where otherwise it would hang around?) > > Without the "&", there is an extra bash process running: I want just to > start XWin... > >> See attached. > > > >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; The semicolon at the end of the above line is a syntax error. You need to remove it. >> xsi:noNamespaceSchemaLocation="run2.xsd"> >> >> >> >> >> -l -c 'rm -rf /tmp/{.X*,dbus*,orbit*,*}; XWin -nowgl -multiwindow -clipboard -silent-dup-error 2>/dev/null &' >> >> >> > > I have copy/pasted it, but it doesn't work (I have also tried with us-ascii) > > If I add the debug options you suggested, I got > > opt_loglevel: 9 > opt_nogui : 0 > opt_notty : 1 > opt_timeout : 0.50 > opt_wait : 0 > opt_force : auto > > (run2_xml_stardocument) ctx=0x22aa8c > (run2_xml_enddocument) ctx=0x22aa8c > /home/angelo/XWinServer.xml: validation generated an internal error > There was an error parsing XWinServer.xml > exit status 1 > > > Ciao, > Angelo. > -- 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/ From angelo.graziosi@alice.it Fri Aug 2 07:42:00 2013 From: angelo.graziosi@alice.it (Angelo Graziosi) Date: Fri, 02 Aug 2013 07:42:00 -0000 Subject: Fwd: Fwd: Re: Cygwin 1.7.22 calls dumper when starting X In-Reply-To: <51FB6191.6030901@alice.it> References: <51FB6191.6030901@alice.it> Message-ID: <51FB62F0.9010900@alice.it> Mark Hansen wrote: > The semicolon at the end of the above line is a syntax error. You need to remove it. Hey, but it is "something" that adds the extra ";"!!! Not me.. I have verified my replays in the Sent box and they DO NOT contain the ";" Se the attachments... Ciao, Angelo. (PS. I have tried to attach the xml file but the mail bounces... I resend without it.. 3rd try) -------------- next part -------------- A non-text attachment was scrubbed... Name: my_replaypng.tar.xz Type: application/octet-stream Size: 66544 bytes Desc: not available URL: -------------- next part -------------- -- 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/ From jon.turney@dronecode.org.uk Fri Aug 2 20:17:00 2013 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Fri, 02 Aug 2013 20:17:00 -0000 Subject: [ANNOUNCEMENT] Updated: xorg-server-1.14.2-2 (64 bit only) Message-ID: The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.14.2-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.14.2-1: * [cygwin64] Fix multiwindow mode windows not being able to change title, icon or decoration after they are first shown. * [cygwin64] Fix ARGB cursors being vertically stretched by interleaving blank rows of pixels. 7eb32909079742014613b541aac1d96c *xorg-server-1.14.2-2.tar.bz2 af4b7b7d185b6e17a5635a9aa338b588 *xorg-server-common-1.14.2-2.tar.bz2 def267cf3f0ca22884f7879c90e0ef4a *xorg-server-debuginfo-1.14.2-2.tar.bz2 0a813828717cfd40d723572ae8c7dd0b *xorg-server-devel-1.14.2-2.tar.bz2 7f4d8456cb743eadfd25418e47549b6c *xorg-server-dmx-1.14.2-2.tar.bz2 1d0f60c30ac8c83b3ae7f329f4ecd22d *xorg-server-extra-1.14.2-2.tar.bz2 fcd30f2e0429052db28b17d413b58b1b *xserver-cygwin-1.14.2-2.tar.bz2 7d9b72fae0f5f0e3b0b7abf423c68073 *xwinclip-1.14.2-2.tar.bz2 41f4913fe1725e943a49a6fd49e60888 *xorg-server-1.14.2-2-src.tar.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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/ From jon.turney@dronecode.org.uk Sun Aug 4 19:37:00 2013 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Sun, 04 Aug 2013 19:37:00 -0000 Subject: [ANNOUNCEMENT] Updated: XtoW, a native compositing window manager (experimental) In-Reply-To: <50D34EDE.3010608@dronecode.org.uk> References: <50D34EDE.3010608@dronecode.org.uk> Message-ID: The following packages have been updated in the Cygwin distribution: *** XtoW-20130802-1 *** libxcwm0-20130802-1 *** libxcwm-devel-20130802-1 xtow is a window manager using the libxcwm library, which is: * native: it integrates with native window management by putting each top-level X window in it's own Windows window (similar to XWin -multiwindow) * compositing: X windows with per-pixel alpha are composited into the native DWM desktop on Windows Vista and later (e.g. a native window can be seen through a semi-transparent X window placed over it) XtoW is still experimental, but should now be usable enough for doing some actual work. Testing and problem reports are appreciated. Changes since 20121220-1: * Window images are now transferred from the X server using shared memory when possible, which improves drawing speed measurably. This can be disabled with -noshm * XtoW exits cleanly when X server is shutdown * XtoW exits immediately when sent an unhandled signal (e.g SIGTERM from being ctrl-c'ed) * When X windows resize or reposition themselves, those changes are propagated to the native windows * Handle tilt wheel and renumber buttons to align with XWin -multiwindow * Implement iconic state. Handle WM_HINTS.initial_state on map and WM_CHANGE_STATE messages correctly * The active window is moved to the top of the stacking order to ensure it receives mouse events over itself (This is shortcut until proper Z-order <-> stacking synchronization is implemented) * Try harder to ensure newly created windows are at the top of the Z-order * Add -verbose option. Multiple -verbose options increase verbosity. * Lots of libxcwm cleanup, logging improvements, bug-fixes and refactoring * Fixes for x86_64 build Missing features compared to XWin -multiwindow: * You must manually use setxkbmap to set a keyboard layout matching the windows layout. * Probably lots more To use: * A startxtow script is provided, which writes a suitable xorg.conf, starts the X server, XtoW, xwinclip and a transparent urxvt. This script is intended to be temporary, to be replaced by something better later on... 32-bit: 74673adf7504f9c7c463e2760eb54d3f *libxcwm-20130802-1-src.tar.bz2 dc09df025e7bc1c6c2c4c0a05773840f *libxcwm-debuginfo-20130802-1.tar.bz2 6c9d5d4189f6aedb598c5f0aaaa8a40b *libxcwm-devel-20130802-1.tar.bz2 b504e1e2a35b5ed261948fd222c79778 *libxcwm0-20130802-1.tar.bz2 87ec6a8c0edf1db142676a3d085a89e4 *XtoW-20130802-1-src.tar.bz2 445379bb679c83d7a3976d974c1d203d *XtoW-20130802-1.tar.bz2 c51aaa365fc7bc3a6d5db1a332c6d90e *XtoW-debuginfo-20130802-1.tar.bz2 64-bit: d95f6482b93eb50a5fabec34721cbde7 *libxcwm0-20130802-1.tar.bz2 edec6064c8526cafe30c675bf13c0abc *libxcwm-debuginfo-20130802-1.tar.bz2 fd402a3380909866e7084c7297913efd *libxcwm-devel-20130802-1.tar.bz2 0851bffc634ba9ec651b0579f42329dd *libxcwm-20130802-1-src.tar.bz2 8d427629181968c6c113d738d187fd0d *XtoW-20130802-1.tar.bz2 309ae5649e80b1142ef096b5cd65bc80 *XtoW-debuginfo-20130802-1.tar.bz2 4d467a813653ffc8be0fb92bdb34a585 *XtoW-20130802-1-src.tar.bz2 -- 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/ From corinna-cygwin@cygwin.com Mon Aug 5 08:54:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Mon, 05 Aug 2013 08:54:00 -0000 Subject: [ANNOUNCEMENT] Updated: XtoW, a native compositing window manager (experimental) In-Reply-To: References: <50D34EDE.3010608@dronecode.org.uk> Message-ID: <20130805085419.GL23060@calimero.vinschen.de> On Aug 4 19:17, Jon TURNEY wrote: > > The following packages have been updated in the Cygwin distribution: > > *** XtoW-20130802-1 > *** libxcwm0-20130802-1 > *** libxcwm-devel-20130802-1 I fixed http://cygwin.com/cygwin-64bit-missing > To use: > > * A startxtow script is provided, which writes a suitable xorg.conf, starts > the X server, XtoW, xwinclip and a transparent urxvt. This script is intended > to be temporary, to be replaced by something better later on... The script is missing in the 64 bit version. How to start XtoW without that script? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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/ From jon.turney@dronecode.org.uk Mon Aug 5 10:01:00 2013 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 05 Aug 2013 10:01:00 -0000 Subject: [ANNOUNCEMENT] Updated: XtoW, a native compositing window manager (experimental) In-Reply-To: <20130805085419.GL23060@calimero.vinschen.de> References: <50D34EDE.3010608@dronecode.org.uk> <20130805085419.GL23060@calimero.vinschen.de> Message-ID: <51FF77DA.4000805@dronecode.org.uk> On 05/08/2013 09:54, Corinna Vinschen wrote: > On Aug 4 19:17, Jon TURNEY wrote: > I fixed http://cygwin.com/cygwin-64bit-missing > >> To use: >> >> * A startxtow script is provided, which writes a suitable xorg.conf, starts >> the X server, XtoW, xwinclip and a transparent urxvt. This script is intended >> to be temporary, to be replaced by something better later on... > > The script is missing in the 64 bit version. How to start XtoW > without that script? Oops. It seems that I made a packaging error and startxtow is missing from both x86 and x86_64 packages. I've uploaded a XtoW-20130802-2 which includes the script. It'll still need some adjusting on x86_64, as it requires both perl-Win32-GUI and rxvt-unicode-X which aren't yet packaged, but you could work around that by hard-coding your display dimensions and using a different X terminal... -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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/ From corinna-cygwin@cygwin.com Mon Aug 5 10:04:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Mon, 05 Aug 2013 10:04:00 -0000 Subject: [ANNOUNCEMENT] Updated: XtoW, a native compositing window manager (experimental) In-Reply-To: <51FF77DA.4000805@dronecode.org.uk> References: <50D34EDE.3010608@dronecode.org.uk> <20130805085419.GL23060@calimero.vinschen.de> <51FF77DA.4000805@dronecode.org.uk> Message-ID: <20130805100447.GA24397@calimero.vinschen.de> On Aug 5 11:00, Jon TURNEY wrote: > On 05/08/2013 09:54, Corinna Vinschen wrote: > > On Aug 4 19:17, Jon TURNEY wrote: > > I fixed http://cygwin.com/cygwin-64bit-missing > > > >> To use: > >> > >> * A startxtow script is provided, which writes a suitable xorg.conf, starts > >> the X server, XtoW, xwinclip and a transparent urxvt. This script is intended > >> to be temporary, to be replaced by something better later on... > > > > The script is missing in the 64 bit version. How to start XtoW > > without that script? > > Oops. It seems that I made a packaging error and startxtow is missing from > both x86 and x86_64 packages. > > I've uploaded a XtoW-20130802-2 which includes the script. > > It'll still need some adjusting on x86_64, as it requires both perl-Win32-GUI > and rxvt-unicode-X which aren't yet packaged, but you could work around that > by hard-coding your display dimensions and using a different X terminal... Ok, thanks! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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/ From jon.turney@dronecode.org.uk Mon Aug 5 10:05:00 2013 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 05 Aug 2013 10:05:00 -0000 Subject: [ANNOUNCEMENT] Updated: XtoW, a native compositing window manager (experimental) In-Reply-To: <50D34EDE.3010608@dronecode.org.uk> References: <50D34EDE.3010608@dronecode.org.uk> Message-ID: The following packages have been updated in the Cygwin distribution: *** XtoW-20130802-2 xtow is a window manager using the libxcwm library, which is: * native: it integrates with native window management by putting each top-level X window in it's own Windows window (similar to XWin -multiwindow) * compositing: X windows with per-pixel alpha are composited into the native DWM desktop on Windows Vista and later (e.g. a native window can be seen through a semi-transparent X window placed over it) XtoW is still experimental, but should now be usable enough for doing some actual work. Testing and problem reports are appreciated. Changes since 20130802-1: * Fix packaging to include the startxtow script omitted in error 32-bit: 8257d61cd3009f8650557d7bb51fc3c2 *XtoW-20130802-2-src.tar.bz2 ed03f3f86b3b9c8169d4d87c5afd5ef7 *XtoW-20130802-2.tar.bz2 68507bbf78b450afeb5eeb317a3de52c *XtoW-debuginfo-20130802-2.tar.bz2 64-bit: 0c0f2fefcf7397a014f4c0dfd3c27feb *XtoW-20130802-2.tar.bz2 57feeed6aa8cfd6aa6ba643ef15d83a7 *XtoW-debuginfo-20130802-2.tar.bz2 4bdc965921b2a75e7dd2a4f0ca9c86b5 *XtoW-20130802-2-src.tar.bz2 -- 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/ From weixie@rcf.rhic.bnl.gov Thu Aug 8 14:21:00 2013 From: weixie@rcf.rhic.bnl.gov (Wei Xie) Date: Thu, 08 Aug 2013 14:21:00 -0000 Subject: unable to get setup.ini In-Reply-To: <4E6E1E6A.5020501@rcf.rhic.bnl.gov> References: <4E6E1E6A.5020501@rcf.rhic.bnl.gov> Message-ID: <5203A966.608@rcf.rhic.bnl.gov> Trying to update the cygwin but the setup script send a "unable to get setup.ini". I tried different download site and got the same error. Thanks --Wei -- 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/ From davidl@lmert.com Thu Aug 8 16:06:00 2013 From: davidl@lmert.com (David Lee Lambert) Date: Thu, 08 Aug 2013 16:06:00 -0000 Subject: unable to get setup.ini In-Reply-To: <5203A966.608@rcf.rhic.bnl.gov> References: <4E6E1E6A.5020501@rcf.rhic.bnl.gov> <5203A966.608@rcf.rhic.bnl.gov> Message-ID: if you go out to "cygwin.com" and look, there are now two different setup clients, one for 32-bit and one for 64-bit. Pick one and use it; there seems to have been an incompatible chage from what old versions of "setup.exe" expected. 2013/8/8 Wei Xie : > Trying to update the cygwin but the setup script send a "unable to get > setup.ini". I tried different download site and got the same error. > > Thanks > --Wei > > -- > 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/ > -- -- David L. Lambert (also davidleelambert@yahoo.com) Member IEEE, ACM (david.lee.lambert@acm.org) - formerly as4109@wayne.edu, lamber45@msu.edu Ph# (616)676-7375 IM: davidleelambert (Yahoo!) or lamber45@cse.msu.edu (MSN) -- 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/ From firmeromanesti@gmail.com Mon Aug 12 02:45:00 2013 From: firmeromanesti@gmail.com (firme romanesti) Date: Mon, 12 Aug 2013 02:45:00 -0000 Subject: buna ziua Message-ID: <20130812024338500.7609174C4EC13F12@Calin-PC> Buna ziua, Va intereseaza un catalog de firme in format electronic (tabele excel) cu 59.000 firme cu date complete de identificare, din tara, clasificate in 418 domenii de activitate pentru revigorarea afacerii dvs.-150 RON? Puteti primi mai multe informatii prin email daca sunteti interesati Daca acest mesaj a ajuns din gresala la dvs. si nu prezinta interes va rog dati un reply cu subiectul :"NU". Multumim pentru intelegere. O zi buna -- 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/ From yselkowitz@users.sourceforge.net Mon Aug 12 19:38:00 2013 From: yselkowitz@users.sourceforge.net (Yaakov (Cygwin/X)) Date: Mon, 12 Aug 2013 19:38:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August Message-ID: The following packages (and their subpackages) have been updated for both arches: * at-spi2-atk-2.8.1-1 * at-spi2-core-2.8.0-1 * atk1.0-2.8.0-1 * dconf-0.16.1-1 * font-cantarell-otf-0.0.13-1 * fontconfig-2.10.93-1 * gamin-0.1.10-14 * GConf2-3.2.6-2 * gcr-3.8.2-1 * gdk-pixbuf2.0-2.28.2-1 * glib2.0-2.36.4-1 * glib2.0-networking-2.36.2-1 * gnome-common-3.7.4-2 * gnome-icon-theme-3.8.3-1 * gnome-keyring-3.8.2-1 * gnome-themes-standard-3.8.3-1 * gobject-introspection-1.36.0-1 * graphite2-1.2.3-1 * gsettings-desktop-schemas-3.8.2-1 * gstreamer1.0-1.0.9-1 * gstreamer1.0-plugins-base-1.0.9-1 * gstreamer1.0-plugins-good-1.0.9-1 * gtk-doc-1.19-1 * gtk2.0-2.24.20-1 * gtk3-3.8.2-1 * gvfs-1.16.3-1 * harfbuzz-0.9.19-1 * libgnome-keyring-3.8.0-1 * libgsf-1.14.28-1 * libsecret1-0.15-1 * libsoup2.4-2.42.2-1 * nspr-4.9.6-1 * pango1.0-1.34.1-1 * pcre-8.33-1 * perl-Clone-0.34-1 * pixman-0.30.2-1 * python-gi-3.8.3-1 * python3-gi-3.8.3-1 * vala-0.20.1-1 * xorg-cf-files-1.0.5-2 * yelp-xsl-3.8.1-1 This update brings the GNOME components in the distro up to the latest stable release. -- Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO ====================================== If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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: cygwin-xfree-announce-unsubscribe-you=yourdomain.com@cygwin.com 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 this URL. -- 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/ From angelo.graziosi@alice.it Tue Aug 13 12:08:00 2013 From: angelo.graziosi@alice.it (Angelo Graziosi) Date: Tue, 13 Aug 2013 12:08:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520A01DF.1040208@alice.it> References: <520A01DF.1040208@alice.it> Message-ID: <520A21B1.8060503@alice.it> Il 13/08/2013 11.52, Angelo Graziosi ha scritto: > Yaakov wrote: >> The following packages (and their subpackages) have been updated for >> both arches: > > After this update my GTK builds of Emacs trunk do not work any more. For > example, the bootstrap of rev. 113816 I did yesterday and that worked > fine up to before this update, now fails so: > > $ emacs -Q & > [1] 3044 > > ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes > (alignment: 512): Function not implemented > > > [1]+ Aborted (core dumped) emacs -Q > > > So, after this update, I tried a new bootstrap (rev.113838) but id fails > in the same manner: > > if test "no" = "yes"; then \ > rm -f bootstrap-emacs.exe; \ > ln temacs.exe bootstrap-emacs.exe; \ > else \ > `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \ > test "X" = X || -zex emacs.exe; \ > mv -f emacs.exe bootstrap-emacs.exe; \ > fi > > ***MEMORY-ERROR***: [896]: GSlice: failed to allocate 504 bytes > (alignment: 512): Function not implemented > > /bin/sh: line 7: 896 Aborted (core dumped) > `/bin/pwd`/temacs --batch --load loadup bootstrap > Makefile:835: recipe for target `bootstrap-emacs.exe' failed > make[2]: *** [bootstrap-emacs.exe] Error 1 > make[2]: uscita dalla directory "/work/emacs/Work/src" > Makefile:379: recipe for target `src' failed > make[1]: *** [src] Error 2 > make[1]: uscita dalla directory "/work/emacs/Work" > Makefile:1040: recipe for target `bootstrap' failed > make: *** [bootstrap] Error 2 > build-emacs.sh: Bootstrap failure... > > > Probably this issue affects also the Cygwin (GTK) package of Emacs.. > > It seems that the workaround is to start Emacs with G_SLICE=always-malloc, > > $ G_SLICE=always-malloc emacs -Q & > > > Ken, wasn't this issue fixed upstream some time ago? Just for the record, I can reproduce the same issue with emacs-x11 from Cygwin package. > > Ciao, > Angelo. PS. My previous replay was sent to the wrong mailing list... :( Sorry! -- 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/ From kbrown@cornell.edu Tue Aug 13 14:13:00 2013 From: kbrown@cornell.edu (Ken Brown) Date: Tue, 13 Aug 2013 14:13:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520A21B1.8060503@alice.it> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> Message-ID: <520A3EF6.80700@cornell.edu> On 8/13/2013 8:08 AM, Angelo Graziosi wrote: > Il 13/08/2013 11.52, Angelo Graziosi ha scritto: >> Yaakov wrote: >>> The following packages (and their subpackages) have been updated for >>> both arches: >> >> After this update my GTK builds of Emacs trunk do not work any more. For >> example, the bootstrap of rev. 113816 I did yesterday and that worked >> fine up to before this update, now fails so: >> >> $ emacs -Q & >> [1] 3044 >> >> ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes >> (alignment: 512): Function not implemented >> >> >> [1]+ Aborted (core dumped) emacs -Q >> >> >> So, after this update, I tried a new bootstrap (rev.113838) but id fails >> in the same manner: >> >> if test "no" = "yes"; then \ >> rm -f bootstrap-emacs.exe; \ >> ln temacs.exe bootstrap-emacs.exe; \ >> else \ >> `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \ >> test "X" = X || -zex emacs.exe; \ >> mv -f emacs.exe bootstrap-emacs.exe; \ >> fi >> >> ***MEMORY-ERROR***: [896]: GSlice: failed to allocate 504 bytes >> (alignment: 512): Function not implemented >> >> /bin/sh: line 7: 896 Aborted (core dumped) >> `/bin/pwd`/temacs --batch --load loadup bootstrap >> Makefile:835: recipe for target `bootstrap-emacs.exe' failed >> make[2]: *** [bootstrap-emacs.exe] Error 1 >> make[2]: uscita dalla directory "/work/emacs/Work/src" >> Makefile:379: recipe for target `src' failed >> make[1]: *** [src] Error 2 >> make[1]: uscita dalla directory "/work/emacs/Work" >> Makefile:1040: recipe for target `bootstrap' failed >> make: *** [bootstrap] Error 2 >> build-emacs.sh: Bootstrap failure... >> >> >> Probably this issue affects also the Cygwin (GTK) package of Emacs.. >> >> It seems that the workaround is to start Emacs with >> G_SLICE=always-malloc, >> >> $ G_SLICE=always-malloc emacs -Q & >> >> >> Ken, wasn't this issue fixed upstream some time ago? Yes. The fix was to add the following for the Cygwin build, very early in main(): setenv ("G_SLICE", "always-malloc", 1); I don't know why this no longer works. Maybe Glib now does its memory management initialization before emacs's main() is entered. Yaakov, is there any chance that you could patch Glib to do the equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an emacs issue. It would affect any GTK application that provides its own malloc rather than using Cygwin's malloc. (But emacs is probably the only such application in the distro.) An alternative to patching Glib would be to fix the problem directly in Cygwin, but I don't know how hard that is and whether Corinna and cgf are interested. The issue, as I understand it, is this: Cygwin allows programs to supply their own malloc but not their own memalign. Glib calls memalign, which becomes Cygwin's memalign, which returns ENOSYS when Cygwin's malloc is not being used. There was a long discussion about this on the Cygwin mailing list in 2007. The thread starts at http://cygwin.com/ml/cygwin/2007-02/msg00469.html and continues at http://cygwin.com/ml/cygwin/2007-02/msg00503.html and did not resolve the issue. Ken -- 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/ From kbrown@cornell.edu Tue Aug 13 14:30:00 2013 From: kbrown@cornell.edu (Ken Brown) Date: Tue, 13 Aug 2013 14:30:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520A3EF6.80700@cornell.edu> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> Message-ID: <520A42F0.3080306@cornell.edu> On 8/13/2013 10:13 AM, Ken Brown wrote: > On 8/13/2013 8:08 AM, Angelo Graziosi wrote: >> Il 13/08/2013 11.52, Angelo Graziosi ha scritto: >>> Yaakov wrote: >>>> The following packages (and their subpackages) have been updated for >>>> both arches: >>> >>> After this update my GTK builds of Emacs trunk do not work any more. For >>> example, the bootstrap of rev. 113816 I did yesterday and that worked >>> fine up to before this update, now fails so: >>> >>> $ emacs -Q & >>> [1] 3044 >>> >>> ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes >>> (alignment: 512): Function not implemented >>> >>> >>> [1]+ Aborted (core dumped) emacs -Q >>> >>> >>> So, after this update, I tried a new bootstrap (rev.113838) but id fails >>> in the same manner: >>> >>> if test "no" = "yes"; then \ >>> rm -f bootstrap-emacs.exe; \ >>> ln temacs.exe bootstrap-emacs.exe; \ >>> else \ >>> `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \ >>> test "X" = X || -zex emacs.exe; \ >>> mv -f emacs.exe bootstrap-emacs.exe; \ >>> fi >>> >>> ***MEMORY-ERROR***: [896]: GSlice: failed to allocate 504 bytes >>> (alignment: 512): Function not implemented >>> >>> /bin/sh: line 7: 896 Aborted (core dumped) >>> `/bin/pwd`/temacs --batch --load loadup bootstrap >>> Makefile:835: recipe for target `bootstrap-emacs.exe' failed >>> make[2]: *** [bootstrap-emacs.exe] Error 1 >>> make[2]: uscita dalla directory "/work/emacs/Work/src" >>> Makefile:379: recipe for target `src' failed >>> make[1]: *** [src] Error 2 >>> make[1]: uscita dalla directory "/work/emacs/Work" >>> Makefile:1040: recipe for target `bootstrap' failed >>> make: *** [bootstrap] Error 2 >>> build-emacs.sh: Bootstrap failure... >>> >>> >>> Probably this issue affects also the Cygwin (GTK) package of Emacs.. >>> >>> It seems that the workaround is to start Emacs with >>> G_SLICE=always-malloc, >>> >>> $ G_SLICE=always-malloc emacs -Q & >>> >>> >>> Ken, wasn't this issue fixed upstream some time ago? > > Yes. The fix was to add the following for the Cygwin build, very early > in main(): > > setenv ("G_SLICE", "always-malloc", 1); > > I don't know why this no longer works. Maybe Glib now does its memory > management initialization before emacs's main() is entered. > > Yaakov, is there any chance that you could patch Glib to do the > equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an > emacs issue. It would affect any GTK application that provides its own > malloc rather than using Cygwin's malloc. (But emacs is probably the > only such application in the distro.) > > An alternative to patching Glib would be to fix the problem directly in > Cygwin, but I don't know how hard that is and whether Corinna and cgf > are interested. The issue, as I understand it, is this: Cygwin allows > programs to supply their own malloc but not their own memalign. Glib > calls memalign, which becomes Cygwin's memalign, which returns ENOSYS > when Cygwin's malloc is not being used. > > There was a long discussion about this on the Cygwin mailing list in > 2007. The thread starts at > > http://cygwin.com/ml/cygwin/2007-02/msg00469.html > > and continues at > > http://cygwin.com/ml/cygwin/2007-02/msg00503.html > > and did not resolve the issue. While we're waiting for a good solution, I could quickly repackage emacs-X11 so that it supplies a wrapper script that sets G_SLICE=always-malloc before calling emacs-X11. If people think that's a good idea, I should be able to do it later today. Ken -- 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/ From angelo.graziosi@alice.it Tue Aug 13 14:46:00 2013 From: angelo.graziosi@alice.it (Angelo Graziosi) Date: Tue, 13 Aug 2013 14:46:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520A21B1.8060503@alice.it> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> Message-ID: <520A46A5.1010601@alice.it> Ken Brown wrote: > Yes. The fix was to add the following for the Cygwin build, very early in main(): > Indeed.. I have verified that G_SLICE_ALWAYS_MALLOC is 1 in config.h so that in emacs.c #ifdef G_SLICE_ALWAYS_MALLOC /* This is used by the Cygwin build. */ xputenv ("G_SLICE=always-malloc"); #endif defines rightly G_SLICE... > setenv ("G_SLICE", "always-malloc", 1); > > I don't know why this no longer works. Maybe Glib now does its memory management initialization before emacs's main() is entered. ...evidently, this is not sufficient, too late: Emacs has already aborted Probably, the problem is elsewhere... Ciao, Angelo. -- 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/ From yselkowitz@users.sourceforge.net Tue Aug 13 18:09:00 2013 From: yselkowitz@users.sourceforge.net (Yaakov (Cygwin/X)) Date: Tue, 13 Aug 2013 18:09:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520A3EF6.80700@cornell.edu> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> Message-ID: <520A7654.3080207@users.sourceforge.net> On 2013-08-13 09:13, Ken Brown wrote: > Yes. The fix was to add the following for the Cygwin build, very early > in main(): > > setenv ("G_SLICE", "always-malloc", 1); > > I don't know why this no longer works. Maybe Glib now does its memory > management initialization before emacs's main() is entered. Exactly; in glib-2.36, g_type_init has been moved to a ctor, which is automatically called before main(); hence, this setenv is too late now. Mozilla software is also affected by this, see: https://bugzilla.gnome.org/show_bug.cgi?id=687763 https://bugzilla.mozilla.org/show_bug.cgi?id=833117 and many others. Firefox et al already use launcher scripts, so adding one more line won't be a big deal for them. > Yaakov, is there any chance that you could patch Glib to do the > equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an > emacs issue. It would affect any GTK application that provides its own > malloc rather than using Cygwin's malloc. (But emacs is probably the > only such application in the distro.) Given that the only programs which seem to be *practically* affected by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't have yet), and using G_SLICE=always-malloc apparently affects performance, I don't think that would be an appropriate solution. For now, I think you'll have to add a wrapper script. Yaakov -- 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/ From corinna-cygwin@cygwin.com Tue Aug 13 18:26:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Tue, 13 Aug 2013 18:26:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520A7654.3080207@users.sourceforge.net> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> Message-ID: <20130813182653.GA4315@calimero.vinschen.de> On Aug 13 13:09, Yaakov (Cygwin/X) wrote: > On 2013-08-13 09:13, Ken Brown wrote: > >Yes. The fix was to add the following for the Cygwin build, very early > >in main(): > > > > setenv ("G_SLICE", "always-malloc", 1); > > > >I don't know why this no longer works. Maybe Glib now does its memory > >management initialization before emacs's main() is entered. > > Exactly; in glib-2.36, g_type_init has been moved to a ctor, which > is automatically called before main(); hence, this setenv is too > late now. Mozilla software is also affected by this, see: > > https://bugzilla.gnome.org/show_bug.cgi?id=687763 > https://bugzilla.mozilla.org/show_bug.cgi?id=833117 > > and many others. Firefox et al already use launcher scripts, so > adding one more line won't be a big deal for them. > > >Yaakov, is there any chance that you could patch Glib to do the > >equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an > >emacs issue. It would affect any GTK application that provides its own > >malloc rather than using Cygwin's malloc. (But emacs is probably the > >only such application in the distro.) > > Given that the only programs which seem to be *practically* affected > by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't > have yet), and using G_SLICE=always-malloc apparently affects > performance, I don't think that would be an appropriate solution. > > For now, I think you'll have to add a wrapper script. Can anybody of you explain to me what the actual underlying problem is? I mean, why this error message: ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From cygwin@cwilson.fastmail.fm Tue Aug 13 19:26:00 2013 From: cygwin@cwilson.fastmail.fm (Charles Wilson) Date: Tue, 13 Aug 2013 19:26:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520A7654.3080207@users.sourceforge.net> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> Message-ID: <520A886B.3030401@cwilson.fastmail.fm> On 8/13/2013 2:09 PM, Yaakov (Cygwin/X) wrote: > For now, I think you'll have to add a wrapper script. Which would cause issues (dos boxes, etc) when launching from a shortcut, unless you use run.exe or run2.exe. With run2 (assuming the upcoming(?) release fixes the known issues), you can set environment vars directly in the xml script: ...various stuff... ...various stuff... ...various stuff... ...ought to work. But there are still extant issues with run2 IIRC (been on vacation for a while so my memory from pre-vacation is still fuzzy). -- Chuck -- 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/ From kbrown@cornell.edu Tue Aug 13 22:00:00 2013 From: kbrown@cornell.edu (Ken Brown) Date: Tue, 13 Aug 2013 22:00:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <20130813182653.GA4315@calimero.vinschen.de> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> Message-ID: <520AAC65.1090708@cornell.edu> On 8/13/2013 2:26 PM, Corinna Vinschen wrote: > On Aug 13 13:09, Yaakov (Cygwin/X) wrote: >> On 2013-08-13 09:13, Ken Brown wrote: >>> Yes. The fix was to add the following for the Cygwin build, very early >>> in main(): >>> >>> setenv ("G_SLICE", "always-malloc", 1); >>> >>> I don't know why this no longer works. Maybe Glib now does its memory >>> management initialization before emacs's main() is entered. >> >> Exactly; in glib-2.36, g_type_init has been moved to a ctor, which >> is automatically called before main(); hence, this setenv is too >> late now. Mozilla software is also affected by this, see: >> >> https://bugzilla.gnome.org/show_bug.cgi?id=687763 >> https://bugzilla.mozilla.org/show_bug.cgi?id=833117 >> >> and many others. Firefox et al already use launcher scripts, so >> adding one more line won't be a big deal for them. >> >>> Yaakov, is there any chance that you could patch Glib to do the >>> equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an >>> emacs issue. It would affect any GTK application that provides its own >>> malloc rather than using Cygwin's malloc. (But emacs is probably the >>> only such application in the distro.) >> >> Given that the only programs which seem to be *practically* affected >> by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't >> have yet), and using G_SLICE=always-malloc apparently affects >> performance, I don't think that would be an appropriate solution. >> >> For now, I think you'll have to add a wrapper script. > > Can anybody of you explain to me what the actual underlying problem is? > I mean, why this error message: > > ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes > (alignment: 512): Function not implemented > > What function is not implemented? Is that something we can fix, > perhaps in the Cygwin DLL? It's memalign, or at least that's what it was in 2007. See http://cygwin.com/ml/cygwin/2007-02/msg00678.html Ken -- 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/ From corinna-cygwin@cygwin.com Wed Aug 14 08:10:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Wed, 14 Aug 2013 08:10:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520AAC65.1090708@cornell.edu> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> Message-ID: <20130814081003.GA29227@calimero.vinschen.de> On Aug 13 18:00, Ken Brown wrote: > On 8/13/2013 2:26 PM, Corinna Vinschen wrote: > >On Aug 13 13:09, Yaakov (Cygwin/X) wrote: > >>On 2013-08-13 09:13, Ken Brown wrote: > >>>Yaakov, is there any chance that you could patch Glib to do the > >>>equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an > >>>emacs issue. It would affect any GTK application that provides its own > >>>malloc rather than using Cygwin's malloc. (But emacs is probably the > >>>only such application in the distro.) > >> > >>Given that the only programs which seem to be *practically* affected > >>by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't > >>have yet), and using G_SLICE=always-malloc apparently affects > >>performance, I don't think that would be an appropriate solution. > >> > >>For now, I think you'll have to add a wrapper script. > > > >Can anybody of you explain to me what the actual underlying problem is? > >I mean, why this error message: > > > > ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes > > (alignment: 512): Function not implemented > > > >What function is not implemented? Is that something we can fix, > >perhaps in the Cygwin DLL? > > It's memalign, or at least that's what it was in 2007. See > > http://cygwin.com/ml/cygwin/2007-02/msg00678.html So it's using its own malloc but we don't support overriding other functions besides malloc/realloc/calloc/free. In theory we could do that in future. We still have room for 10 (x86) resp. 12 (x86_64) pointers in the per_process structure, which could be used for this purpose. This would only require applications which need this feature to be rebuilt with the next Cygwin version providing these pointers. But we shouldn't waste those unused slots either, so the number of overridable functions should be kept small. In theory we have mallopt, mallinfo, posix_memalign, memalign, and valloc. I guess we can skip mallopt and mallinfo since they are pretty seldomly used in user-provided malloc implementations. Memalign is an old, deprecated function, so I wonder why it's used at all. GSlice should use posix_memalign instead. Yaakov, is there an option to use posix_memalign rather than memalign? Anyway, that would be three extra pointers in the per_process structure, for memalig, posic_memalign, and valloc, and we could get rid of the `if (!use_internal) set_errno(ENOSYS);' in those functions and rather call the user provided functions then. Does that make sense? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From corinna-cygwin@cygwin.com Wed Aug 14 09:17:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Wed, 14 Aug 2013 09:17:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <20130814081003.GA29227@calimero.vinschen.de> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> <20130814081003.GA29227@calimero.vinschen.de> Message-ID: <20130814091656.GE4315@calimero.vinschen.de> On Aug 14 10:10, Corinna Vinschen wrote: > On Aug 13 18:00, Ken Brown wrote: > > On 8/13/2013 2:26 PM, Corinna Vinschen wrote: > > >On Aug 13 13:09, Yaakov (Cygwin/X) wrote: > > >>On 2013-08-13 09:13, Ken Brown wrote: > > >>>Yaakov, is there any chance that you could patch Glib to do the > > >>>equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an > > >>>emacs issue. It would affect any GTK application that provides its own > > >>>malloc rather than using Cygwin's malloc. (But emacs is probably the > > >>>only such application in the distro.) > > >> > > >>Given that the only programs which seem to be *practically* affected > > >>by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't > > >>have yet), and using G_SLICE=always-malloc apparently affects > > >>performance, I don't think that would be an appropriate solution. > > >> > > >>For now, I think you'll have to add a wrapper script. > > > > > >Can anybody of you explain to me what the actual underlying problem is? > > >I mean, why this error message: > > > > > > ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes > > > (alignment: 512): Function not implemented > > > > > >What function is not implemented? Is that something we can fix, > > >perhaps in the Cygwin DLL? > > > > It's memalign, or at least that's what it was in 2007. See > > > > http://cygwin.com/ml/cygwin/2007-02/msg00678.html > > So it's using its own malloc but we don't support overriding other > functions besides malloc/realloc/calloc/free. > > In theory we could do that in future. We still have room for 10 (x86) > resp. 12 (x86_64) pointers in the per_process structure, which could be > used for this purpose. This would only require applications which need > this feature to be rebuilt with the next Cygwin version providing these > pointers. More precisely, they have to be rebuild using crt0.o from the next Cygwin release, and they would have to run under the next Cygwin release. If you omit one step, you're back to the current behaviour. > But we shouldn't waste those unused slots either, so the number of > overridable functions should be kept small. In theory we have mallopt, > mallinfo, posix_memalign, memalign, and valloc. > > I guess we can skip mallopt and mallinfo since they are pretty > seldomly used in user-provided malloc implementations. > > Memalign is an old, deprecated function, so I wonder why it's used at > all. GSlice should use posix_memalign instead. Yaakov, is there an > option to use posix_memalign rather than memalign? > > Anyway, that would be three extra pointers in the per_process structure, > for memalig, posic_memalign, and valloc, and we could get rid of the `if > (!use_internal) set_errno(ENOSYS);' in those functions and rather call > the user provided functions then. > > Does that make sense? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From kbrown@cornell.edu Wed Aug 14 10:28:00 2013 From: kbrown@cornell.edu (Ken Brown) Date: Wed, 14 Aug 2013 10:28:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <20130814091656.GE4315@calimero.vinschen.de> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> <20130814081003.GA29227@calimero.vinschen <20130814091656.GE4315@calimero.vinschen.de> Message-ID: <520B5BC7.4060306@cornell.edu> On 8/14/2013 5:16 AM, Corinna Vinschen wrote: > On Aug 14 10:10, Corinna Vinschen wrote: >> On Aug 13 18:00, Ken Brown wrote: >>> On 8/13/2013 2:26 PM, Corinna Vinschen wrote: >>>> On Aug 13 13:09, Yaakov (Cygwin/X) wrote: >>>>> On 2013-08-13 09:13, Ken Brown wrote: >>>>>> Yaakov, is there any chance that you could patch Glib to do the >>>>>> equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an >>>>>> emacs issue. It would affect any GTK application that provides its own >>>>>> malloc rather than using Cygwin's malloc. (But emacs is probably the >>>>>> only such application in the distro.) >>>>> >>>>> Given that the only programs which seem to be *practically* affected >>>>> by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't >>>>> have yet), and using G_SLICE=always-malloc apparently affects >>>>> performance, I don't think that would be an appropriate solution. >>>>> >>>>> For now, I think you'll have to add a wrapper script. >>>> >>>> Can anybody of you explain to me what the actual underlying problem is? >>>> I mean, why this error message: >>>> >>>> ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes >>>> (alignment: 512): Function not implemented >>>> >>>> What function is not implemented? Is that something we can fix, >>>> perhaps in the Cygwin DLL? >>> >>> It's memalign, or at least that's what it was in 2007. See >>> >>> http://cygwin.com/ml/cygwin/2007-02/msg00678.html >> >> So it's using its own malloc but we don't support overriding other >> functions besides malloc/realloc/calloc/free. >> >> In theory we could do that in future. We still have room for 10 (x86) >> resp. 12 (x86_64) pointers in the per_process structure, which could be >> used for this purpose. This would only require applications which need >> this feature to be rebuilt with the next Cygwin version providing these >> pointers. > > More precisely, they have to be rebuild using crt0.o from the next > Cygwin release, and they would have to run under the next Cygwin > release. If you omit one step, you're back to the current behaviour. > >> But we shouldn't waste those unused slots either, so the number of >> overridable functions should be kept small. In theory we have mallopt, >> mallinfo, posix_memalign, memalign, and valloc. >> >> I guess we can skip mallopt and mallinfo since they are pretty >> seldomly used in user-provided malloc implementations. >> >> Memalign is an old, deprecated function, so I wonder why it's used at >> all. GSlice should use posix_memalign instead. Yaakov, is there an >> option to use posix_memalign rather than memalign? I just checked the glib source, and it does use posix_memalign if it's available. I was quoting a 2007 discussion when I said it was memalign that GSlice wanted to use. >> Anyway, that would be three extra pointers in the per_process structure, >> for memalig, posic_memalign, and valloc, and we could get rid of the `if >> (!use_internal) set_errno(ENOSYS);' in those functions and rather call >> the user provided functions then. >> >> Does that make sense? Yes. Ken -- 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/ From corinna-cygwin@cygwin.com Wed Aug 14 10:53:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Wed, 14 Aug 2013 10:53:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520B5BC7.4060306@cornell.edu> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> <20130814091656.GE4315@calimero.vinschen.de> <520B5BC7.4060306@cornell.edu> Message-ID: <20130814105326.GF4315@calimero.vinschen.de> On Aug 14 06:28, Ken Brown wrote: > On 8/14/2013 5:16 AM, Corinna Vinschen wrote: > >On Aug 14 10:10, Corinna Vinschen wrote: > >>On Aug 13 18:00, Ken Brown wrote: > >>>On 8/13/2013 2:26 PM, Corinna Vinschen wrote: > >>>>On Aug 13 13:09, Yaakov (Cygwin/X) wrote: > >>>>>On 2013-08-13 09:13, Ken Brown wrote: > >>>>>>Yaakov, is there any chance that you could patch Glib to do the > >>>>>>equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an > >>>>>>emacs issue. It would affect any GTK application that provides its own > >>>>>>malloc rather than using Cygwin's malloc. (But emacs is probably the > >>>>>>only such application in the distro.) > >>>>> > >>>>>Given that the only programs which seem to be *practically* affected > >>>>>by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't > >>>>>have yet), and using G_SLICE=always-malloc apparently affects > >>>>>performance, I don't think that would be an appropriate solution. > >>>>> > >>>>>For now, I think you'll have to add a wrapper script. > >>>> > >>>>Can anybody of you explain to me what the actual underlying problem is? > >>>>I mean, why this error message: > >>>> > >>>> ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes > >>>> (alignment: 512): Function not implemented > >>>> > >>>>What function is not implemented? Is that something we can fix, > >>>>perhaps in the Cygwin DLL? > >>> > >>>It's memalign, or at least that's what it was in 2007. See > >>> > >>> http://cygwin.com/ml/cygwin/2007-02/msg00678.html > >> > >>So it's using its own malloc but we don't support overriding other > >>functions besides malloc/realloc/calloc/free. > >> > >>In theory we could do that in future. We still have room for 10 (x86) > >>resp. 12 (x86_64) pointers in the per_process structure, which could be > >>used for this purpose. This would only require applications which need > >>this feature to be rebuilt with the next Cygwin version providing these > >>pointers. > > > >More precisely, they have to be rebuild using crt0.o from the next > >Cygwin release, and they would have to run under the next Cygwin > >release. If you omit one step, you're back to the current behaviour. > > > >>But we shouldn't waste those unused slots either, so the number of > >>overridable functions should be kept small. In theory we have mallopt, > >>mallinfo, posix_memalign, memalign, and valloc. > >> > >>I guess we can skip mallopt and mallinfo since they are pretty > >>seldomly used in user-provided malloc implementations. > >> > >>Memalign is an old, deprecated function, so I wonder why it's used at > >>all. GSlice should use posix_memalign instead. Yaakov, is there an > >>option to use posix_memalign rather than memalign? > > I just checked the glib source, and it does use posix_memalign if > it's available. I was quoting a 2007 discussion when I said it was > memalign that GSlice wanted to use. Given that, we should perhaps skip the memalign override. > >>Anyway, that would be three extra pointers in the per_process structure, > >>for memalig, posic_memalign, and valloc, and we could get rid of the `if > >>(!use_internal) set_errno(ENOSYS);' in those functions and rather call > >>the user provided functions then. > >> > >>Does that make sense? > > Yes. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From corinna-cygwin@cygwin.com Wed Aug 14 11:34:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Wed, 14 Aug 2013 11:34:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <20130814105326.GF4315@calimero.vinschen.de> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> <20130814091656.GE4315@calimero.vinschen.de> <520B5BC7.4060306@cornell.edu> <20130814105326.GF4315@calimero.vinschen.de> Message-ID: <20130814113351.GG4315@calimero.vinschen.de> On Aug 14 12:53, Corinna Vinschen wrote: > On Aug 14 06:28, Ken Brown wrote: > > On 8/14/2013 5:16 AM, Corinna Vinschen wrote: > > >On Aug 14 10:10, Corinna Vinschen wrote: > > >>On Aug 13 18:00, Ken Brown wrote: > > >>>On 8/13/2013 2:26 PM, Corinna Vinschen wrote: > > >>>>What function is not implemented? Is that something we can fix, > > >>>>perhaps in the Cygwin DLL? > > >>> > > >>>It's memalign, or at least that's what it was in 2007. See > > >>> > > >>> http://cygwin.com/ml/cygwin/2007-02/msg00678.html > > >> > > >>So it's using its own malloc but we don't support overriding other > > >>functions besides malloc/realloc/calloc/free. > > >> > > >>In theory we could do that in future. We still have room for 10 (x86) > > >>resp. 12 (x86_64) pointers in the per_process structure, which could be > > >>used for this purpose. This would only require applications which need > > >>this feature to be rebuilt with the next Cygwin version providing these > > >>pointers. > > > > > >More precisely, they have to be rebuild using crt0.o from the next > > >Cygwin release, and they would have to run under the next Cygwin > > >release. If you omit one step, you're back to the current behaviour. > > > > > >>But we shouldn't waste those unused slots either, so the number of > > >>overridable functions should be kept small. In theory we have mallopt, > > >>mallinfo, posix_memalign, memalign, and valloc. > > >> > > >>I guess we can skip mallopt and mallinfo since they are pretty > > >>seldomly used in user-provided malloc implementations. > > >> > > >>Memalign is an old, deprecated function, so I wonder why it's used at > > >>all. GSlice should use posix_memalign instead. Yaakov, is there an > > >>option to use posix_memalign rather than memalign? > > > > I just checked the glib source, and it does use posix_memalign if > > it's available. I was quoting a 2007 discussion when I said it was > > memalign that GSlice wanted to use. > > Given that, we should perhaps skip the memalign override. On second (third? fourth?) thought, I think we should do this with posix_memalign only. valloc is just as obsolete as posix_memalign. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From corinna-cygwin@cygwin.com Wed Aug 14 11:59:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Wed, 14 Aug 2013 11:59:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <20130814113351.GG4315@calimero.vinschen.de> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> <20130814091656.GE4315@calimero.vinschen.de> <520B5BC7.4060306@cornell.edu> <20130814105326.GF4315@calimero.vinschen.de> <20130814113351.GG4315@calimero.vinschen.de> Message-ID: <20130814115920.GH4315@calimero.vinschen.de> On Aug 14 13:33, Corinna Vinschen wrote: > On Aug 14 12:53, Corinna Vinschen wrote: > > On Aug 14 06:28, Ken Brown wrote: > > > On 8/14/2013 5:16 AM, Corinna Vinschen wrote: > > > >On Aug 14 10:10, Corinna Vinschen wrote: > > > >>On Aug 13 18:00, Ken Brown wrote: > > > >>>On 8/13/2013 2:26 PM, Corinna Vinschen wrote: > > > >>>>What function is not implemented? Is that something we can fix, > > > >>>>perhaps in the Cygwin DLL? > > > >>> > > > >>>It's memalign, or at least that's what it was in 2007. See > > > >>> > > > >>> http://cygwin.com/ml/cygwin/2007-02/msg00678.html > > > >> > > > >>So it's using its own malloc but we don't support overriding other > > > >>functions besides malloc/realloc/calloc/free. > > > >> > > > >>In theory we could do that in future. We still have room for 10 (x86) > > > >>resp. 12 (x86_64) pointers in the per_process structure, which could be > > > >>used for this purpose. This would only require applications which need > > > >>this feature to be rebuilt with the next Cygwin version providing these > > > >>pointers. > > > > > > > >More precisely, they have to be rebuild using crt0.o from the next > > > >Cygwin release, and they would have to run under the next Cygwin > > > >release. If you omit one step, you're back to the current behaviour. > > > > > > > >>But we shouldn't waste those unused slots either, so the number of > > > >>overridable functions should be kept small. In theory we have mallopt, > > > >>mallinfo, posix_memalign, memalign, and valloc. > > > >> > > > >>I guess we can skip mallopt and mallinfo since they are pretty > > > >>seldomly used in user-provided malloc implementations. > > > >> > > > >>Memalign is an old, deprecated function, so I wonder why it's used at > > > >>all. GSlice should use posix_memalign instead. Yaakov, is there an > > > >>option to use posix_memalign rather than memalign? > > > > > > I just checked the glib source, and it does use posix_memalign if > > > it's available. I was quoting a 2007 discussion when I said it was > > > memalign that GSlice wanted to use. > > > > Given that, we should perhaps skip the memalign override. > > On second (third? fourth?) thought, I think we should do this with > posix_memalign only. valloc is just as obsolete as posix_memalign. I applied the patch to allow overriding posix_memalloc only, and I'm building snapshots right now. For testing, this requires to rebuild either emacs, or glib, or both, I'm not sure. Make sure to link against the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From kbrown@cornell.edu Wed Aug 14 12:14:00 2013 From: kbrown@cornell.edu (Ken Brown) Date: Wed, 14 Aug 2013 12:14:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <20130814115920.GH4315@calimero.vinschen.de> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> <20130814091656.GE4315@calimero.vinschen.de> <520B5BC7.4060306@cornell.edu> <20130814105326.GF4315@calimero.vinschen.de> <20130814113351.GG4315@calimero.vinschen.de> <20130814115920.GH4315@calimero.vinschen.de> Message-ID: <520B748A.30302@cornell.edu> On 8/14/2013 7:59 AM, Corinna Vinschen wrote: > On Aug 14 13:33, Corinna Vinschen wrote: >> On Aug 14 12:53, Corinna Vinschen wrote: >>> On Aug 14 06:28, Ken Brown wrote: >>>> On 8/14/2013 5:16 AM, Corinna Vinschen wrote: >>>>> On Aug 14 10:10, Corinna Vinschen wrote: >>>>>> On Aug 13 18:00, Ken Brown wrote: >>>>>>> On 8/13/2013 2:26 PM, Corinna Vinschen wrote: >>>>>>>> What function is not implemented? Is that something we can fix, >>>>>>>> perhaps in the Cygwin DLL? >>>>>>> >>>>>>> It's memalign, or at least that's what it was in 2007. See >>>>>>> >>>>>>> http://cygwin.com/ml/cygwin/2007-02/msg00678.html >>>>>> >>>>>> So it's using its own malloc but we don't support overriding other >>>>>> functions besides malloc/realloc/calloc/free. >>>>>> >>>>>> In theory we could do that in future. We still have room for 10 (x86) >>>>>> resp. 12 (x86_64) pointers in the per_process structure, which could be >>>>>> used for this purpose. This would only require applications which need >>>>>> this feature to be rebuilt with the next Cygwin version providing these >>>>>> pointers. >>>>> >>>>> More precisely, they have to be rebuild using crt0.o from the next >>>>> Cygwin release, and they would have to run under the next Cygwin >>>>> release. If you omit one step, you're back to the current behaviour. >>>>> >>>>>> But we shouldn't waste those unused slots either, so the number of >>>>>> overridable functions should be kept small. In theory we have mallopt, >>>>>> mallinfo, posix_memalign, memalign, and valloc. >>>>>> >>>>>> I guess we can skip mallopt and mallinfo since they are pretty >>>>>> seldomly used in user-provided malloc implementations. >>>>>> >>>>>> Memalign is an old, deprecated function, so I wonder why it's used at >>>>>> all. GSlice should use posix_memalign instead. Yaakov, is there an >>>>>> option to use posix_memalign rather than memalign? >>>> >>>> I just checked the glib source, and it does use posix_memalign if >>>> it's available. I was quoting a 2007 discussion when I said it was >>>> memalign that GSlice wanted to use. >>> >>> Given that, we should perhaps skip the memalign override. >> >> On second (third? fourth?) thought, I think we should do this with >> posix_memalign only. valloc is just as obsolete as posix_memalign. > > I applied the patch to allow overriding posix_memalloc only, and I'm > building snapshots right now. For testing, this requires to rebuild > either emacs, or glib, or both, I'm not sure. Make sure to link against > the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. Thanks. It should only be emacs that needs rebuilding; glib doesn't supply its own malloc, but emacs does. I'll test it and report back. Ken -- 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/ From ryan.johnson@cs.utoronto.ca Wed Aug 14 12:28:00 2013 From: ryan.johnson@cs.utoronto.ca (Ryan Johnson) Date: Wed, 14 Aug 2013 12:28:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <20130814115920.GH4315@calimero.vinschen.de> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> <20130814091656.GE4315@calimero.vinschen.de> <520B5BC7.4060306@cornell.edu> <20130814105326.GF4315@calimero.vinschen.de> <20130814113351.GG4315@calimero.vinschen.de> <20130814115920.GH4315@calimero.vinschen.de> Message-ID: <520B77F0.9010009@cs.utoronto.ca> On 14/08/2013 7:59 AM, Corinna Vinschen wrote: > On Aug 14 13:33, Corinna Vinschen wrote: >> On Aug 14 12:53, Corinna Vinschen wrote: >>> On Aug 14 06:28, Ken Brown wrote: >>>> On 8/14/2013 5:16 AM, Corinna Vinschen wrote: >>>>> On Aug 14 10:10, Corinna Vinschen wrote: >>>>>> On Aug 13 18:00, Ken Brown wrote: >>>>>>> On 8/13/2013 2:26 PM, Corinna Vinschen wrote: >>>>>>>> What function is not implemented? Is that something we can fix, >>>>>>>> perhaps in the Cygwin DLL? >>>>>>> It's memalign, or at least that's what it was in 2007. See >>>>>>> >>>>>>> http://cygwin.com/ml/cygwin/2007-02/msg00678.html >>>>>> So it's using its own malloc but we don't support overriding other >>>>>> functions besides malloc/realloc/calloc/free. >>>>>> >>>>>> In theory we could do that in future. We still have room for 10 (x86) >>>>>> resp. 12 (x86_64) pointers in the per_process structure, which could be >>>>>> used for this purpose. This would only require applications which need >>>>>> this feature to be rebuilt with the next Cygwin version providing these >>>>>> pointers. >>>>> More precisely, they have to be rebuild using crt0.o from the next >>>>> Cygwin release, and they would have to run under the next Cygwin >>>>> release. If you omit one step, you're back to the current behaviour. >>>>> >>>>>> But we shouldn't waste those unused slots either, so the number of >>>>>> overridable functions should be kept small. In theory we have mallopt, >>>>>> mallinfo, posix_memalign, memalign, and valloc. >>>>>> >>>>>> I guess we can skip mallopt and mallinfo since they are pretty >>>>>> seldomly used in user-provided malloc implementations. >>>>>> >>>>>> Memalign is an old, deprecated function, so I wonder why it's used at >>>>>> all. GSlice should use posix_memalign instead. Yaakov, is there an >>>>>> option to use posix_memalign rather than memalign? >>>> I just checked the glib source, and it does use posix_memalign if >>>> it's available. I was quoting a 2007 discussion when I said it was >>>> memalign that GSlice wanted to use. >>> Given that, we should perhaps skip the memalign override. >> On second (third? fourth?) thought, I think we should do this with >> posix_memalign only. valloc is just as obsolete as posix_memalign. > I applied the patch to allow overriding posix_memalloc only, and I'm > building snapshots right now. For testing, this requires to rebuild > either emacs, or glib, or both, I'm not sure. Make sure to link against > the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. Wait, it's "memalign" that's obsolete and "posix_memalign" that you added a patch for, right? The last couple of paragraphs were a little confusing... Ryan -- 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/ From corinna-cygwin@cygwin.com Wed Aug 14 14:05:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Wed, 14 Aug 2013 14:05:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520B77F0.9010009@cs.utoronto.ca> References: <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> <20130814091656.GE4315@calimero.vinschen.de> <520B5BC7.4060306@cornell.edu> <20130814105326.GF4315@calimero.vinschen.de> <20130814113351.GG4315@calimero.vinschen.de> <20130814115920.GH4315@calimero.vinschen.de> <520B77F0.9010009@cs.utoronto.ca> Message-ID: <20130814140518.GK4315@calimero.vinschen.de> On Aug 14 08:28, Ryan Johnson wrote: > On 14/08/2013 7:59 AM, Corinna Vinschen wrote: > >On Aug 14 13:33, Corinna Vinschen wrote: > >>On Aug 14 12:53, Corinna Vinschen wrote: > >>>On Aug 14 06:28, Ken Brown wrote: > >>>>On 8/14/2013 5:16 AM, Corinna Vinschen wrote: > >>>>>On Aug 14 10:10, Corinna Vinschen wrote: > >>>>>>On Aug 13 18:00, Ken Brown wrote: > >>>>>>>On 8/13/2013 2:26 PM, Corinna Vinschen wrote: > >>>>>>>>What function is not implemented? Is that something we can fix, > >>>>>>>>perhaps in the Cygwin DLL? > >>>>>>>It's memalign, or at least that's what it was in 2007. See > >>>>>>> > >>>>>>> http://cygwin.com/ml/cygwin/2007-02/msg00678.html > >>>>>>So it's using its own malloc but we don't support overriding other > >>>>>>functions besides malloc/realloc/calloc/free. > >>>>>> > >>>>>>In theory we could do that in future. We still have room for 10 (x86) > >>>>>>resp. 12 (x86_64) pointers in the per_process structure, which could be > >>>>>>used for this purpose. This would only require applications which need > >>>>>>this feature to be rebuilt with the next Cygwin version providing these > >>>>>>pointers. > >>>>>More precisely, they have to be rebuild using crt0.o from the next > >>>>>Cygwin release, and they would have to run under the next Cygwin > >>>>>release. If you omit one step, you're back to the current behaviour. > >>>>> > >>>>>>But we shouldn't waste those unused slots either, so the number of > >>>>>>overridable functions should be kept small. In theory we have mallopt, > >>>>>>mallinfo, posix_memalign, memalign, and valloc. > >>>>>> > >>>>>>I guess we can skip mallopt and mallinfo since they are pretty > >>>>>>seldomly used in user-provided malloc implementations. > >>>>>> > >>>>>>Memalign is an old, deprecated function, so I wonder why it's used at > >>>>>>all. GSlice should use posix_memalign instead. Yaakov, is there an > >>>>>>option to use posix_memalign rather than memalign? > >>>>I just checked the glib source, and it does use posix_memalign if > >>>>it's available. I was quoting a 2007 discussion when I said it was > >>>>memalign that GSlice wanted to use. > >>>Given that, we should perhaps skip the memalign override. > >>On second (third? fourth?) thought, I think we should do this with > >>posix_memalign only. valloc is just as obsolete as posix_memalign. > >I applied the patch to allow overriding posix_memalloc only, and I'm ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >building snapshots right now. For testing, this requires to rebuild > >either emacs, or glib, or both, I'm not sure. Make sure to link against > >the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. > Wait, it's "memalign" that's obsolete and "posix_memalign" that you > added a patch for, right? The last couple of paragraphs were a > little confusing... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From corinna-cygwin@cygwin.com Wed Aug 14 14:55:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Wed, 14 Aug 2013 14:55:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <20130814140518.GK4315@calimero.vinschen.de> References: <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> <20130814091656.GE4315@calimero.vinschen.de> <520B5BC7.4060306@cornell.edu> <20130814105326.GF4315@calimero.vinschen.de> <20130814113351.GG4315@calimero.vinschen.de> <20130814115920.GH4315@calimero.vinschen.de> <520B77F0.9010009@cs.utoronto.ca> <20130814140518.GK4315@calimero.vinschen.de> Message-ID: <20130814145522.GL4315@calimero.vinschen.de> On Aug 14 16:05, Corinna Vinschen wrote: > On Aug 14 08:28, Ryan Johnson wrote: > > On 14/08/2013 7:59 AM, Corinna Vinschen wrote: > > >On Aug 14 13:33, Corinna Vinschen wrote: > > >>On Aug 14 12:53, Corinna Vinschen wrote: > > >>>Given that, we should perhaps skip the memalign override. > > >>On second (third? fourth?) thought, I think we should do this with > > >>posix_memalign only. valloc is just as obsolete as posix_memalign. Oops. Make that "valloc is just as obsolete as memalign." > > >I applied the patch to allow overriding posix_memalloc only, and I'm > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >building snapshots right now. For testing, this requires to rebuild > > >either emacs, or glib, or both, I'm not sure. Make sure to link against > > >the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. > > Wait, it's "memalign" that's obsolete and "posix_memalign" that you > > added a patch for, right? The last couple of paragraphs were a > > little confusing... Sorry, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From kbrown@cornell.edu Wed Aug 14 15:55:00 2013 From: kbrown@cornell.edu (Ken Brown) Date: Wed, 14 Aug 2013 15:55:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520B748A.30302@cornell.edu> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> <20130814091656.GE4315@calimero.vinschen.de> <520B5BC7.4060306@cornell.edu> <20130814105326.GF4315@calimero.vinschen.de> <20130814113351.GG4315@calimero.vinschen.de> <20130814115920.GH4315@calimero.vinschen.de> <520B748A.30302@cornell.edu> Message-ID: <520BA88E.10804@cornell.edu> On 8/14/2013 8:14 AM, Ken Brown wrote: > On 8/14/2013 7:59 AM, Corinna Vinschen wrote: >> On Aug 14 13:33, Corinna Vinschen wrote: >>> On Aug 14 12:53, Corinna Vinschen wrote: >>>> On Aug 14 06:28, Ken Brown wrote: >>>>> On 8/14/2013 5:16 AM, Corinna Vinschen wrote: >>>>>> On Aug 14 10:10, Corinna Vinschen wrote: >>>>>>> On Aug 13 18:00, Ken Brown wrote: >>>>>>>> On 8/13/2013 2:26 PM, Corinna Vinschen wrote: >>>>>>>>> What function is not implemented? Is that something we can fix, >>>>>>>>> perhaps in the Cygwin DLL? >>>>>>>> >>>>>>>> It's memalign, or at least that's what it was in 2007. See >>>>>>>> >>>>>>>> http://cygwin.com/ml/cygwin/2007-02/msg00678.html >>>>>>> >>>>>>> So it's using its own malloc but we don't support overriding other >>>>>>> functions besides malloc/realloc/calloc/free. >>>>>>> >>>>>>> In theory we could do that in future. We still have room for 10 >>>>>>> (x86) >>>>>>> resp. 12 (x86_64) pointers in the per_process structure, which >>>>>>> could be >>>>>>> used for this purpose. This would only require applications >>>>>>> which need >>>>>>> this feature to be rebuilt with the next Cygwin version providing >>>>>>> these >>>>>>> pointers. >>>>>> >>>>>> More precisely, they have to be rebuild using crt0.o from the next >>>>>> Cygwin release, and they would have to run under the next Cygwin >>>>>> release. If you omit one step, you're back to the current behaviour. >>>>>> >>>>>>> But we shouldn't waste those unused slots either, so the number of >>>>>>> overridable functions should be kept small. In theory we have >>>>>>> mallopt, >>>>>>> mallinfo, posix_memalign, memalign, and valloc. >>>>>>> >>>>>>> I guess we can skip mallopt and mallinfo since they are pretty >>>>>>> seldomly used in user-provided malloc implementations. >>>>>>> >>>>>>> Memalign is an old, deprecated function, so I wonder why it's >>>>>>> used at >>>>>>> all. GSlice should use posix_memalign instead. Yaakov, is there an >>>>>>> option to use posix_memalign rather than memalign? >>>>> >>>>> I just checked the glib source, and it does use posix_memalign if >>>>> it's available. I was quoting a 2007 discussion when I said it was >>>>> memalign that GSlice wanted to use. >>>> >>>> Given that, we should perhaps skip the memalign override. >>> >>> On second (third? fourth?) thought, I think we should do this with >>> posix_memalign only. valloc is just as obsolete as posix_memalign. >> >> I applied the patch to allow overriding posix_memalloc only, and I'm >> building snapshots right now. For testing, this requires to rebuild >> either emacs, or glib, or both, I'm not sure. Make sure to link against >> the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. > > Thanks. It should only be emacs that needs rebuilding; glib doesn't > supply its own malloc, but emacs does. I'll test it and report back. Success! Thanks very much for the quick fix. I've got new emacs packages ready to go for both 32-bit and 64-bit. Do you expect to release cygwin-1.7.24 soon? If not, I'll upload the new packages as test releases for anyone who wants to install the snapshot. Ken P.S. For anyone (like Angelo) who wants to build the emacs trunk, I need to patch gmalloc.c upstream before the fix will take effect. -- 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/ From corinna-cygwin@cygwin.com Wed Aug 14 19:00:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Wed, 14 Aug 2013 19:00:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520BA88E.10804@cornell.edu> References: <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> <20130814091656.GE4315@calimero.vinschen.de> <520B5BC7.4060306@cornell.edu> <20130814105326.GF4315@calimero.vinschen.de> <20130814113351.GG4315@calimero.vinschen.de> <20130814115920.GH4315@calimero.vinschen.de> <520B748A.30302@cornell.edu> <520BA88E.10804@cornell.edu> Message-ID: <20130814190050.GN4315@calimero.vinschen.de> On Aug 14 11:55, Ken Brown wrote: > On 8/14/2013 8:14 AM, Ken Brown wrote: > >On 8/14/2013 7:59 AM, Corinna Vinschen wrote: > >>I applied the patch to allow overriding posix_memalloc only, and I'm > >>building snapshots right now. For testing, this requires to rebuild > >>either emacs, or glib, or both, I'm not sure. Make sure to link against > >>the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. > > > >Thanks. It should only be emacs that needs rebuilding; glib doesn't > >supply its own malloc, but emacs does. I'll test it and report back. > > Success! Thanks very much for the quick fix. I've got new emacs > packages ready to go for both 32-bit and 64-bit. Do you expect to > release cygwin-1.7.24 soon? If not, I'll upload the new packages as > test releases for anyone who wants to install the snapshot. Thanks for testing. I'll update to 1.7.24 tomorrow. We have lots of unused version numbers left ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From angelo.graziosi@alice.it Wed Aug 14 19:59:00 2013 From: angelo.graziosi@alice.it (Angelo Graziosi) Date: Wed, 14 Aug 2013 19:59:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520A46A5.1010601@alice.it> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A46A5.1010601@alice.it> Message-ID: <520BE195.4020006@alice.it> Ken Brown wrote: > P.S. For anyone (like Angelo) who wants to build the emacs trunk, I need to patch gmalloc.c upstream before the fix will take effect. Thanks, I will wait for your patches and the Cygwin upgrade. Corin.. oops... Mum wrote it will be released tomorrow.. ;-) Ciao, Angelo. -- 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/ From angelafantj@gmail.com Thu Aug 15 11:47:00 2013 From: angelafantj@gmail.com (angelafan) Date: Thu, 15 Aug 2013 11:47:00 -0000 Subject: I-Tech tablet PC manufacturer Message-ID: <201308151947182592334@gmail.com> Dear Sir ? How are you? This is Angela from i-tech company,our company was founded in 2003,existing staff of more than 100 people. We are commited to research, develope and manufacture fashion digital products, like Tablet PC, game player and so on. Now please allowed me to introduce some hot sale models and popular product to you and your colleagues for tablet PC. We do promotion for tablets for July: 7 inch Dual core IPS 3G and without 3G 7 inch Quadcore IPS screen 7.85 inch dual core IPS with 3G Bluetooth and GPS 8.1 inch dual core with 3G Bluetooth and GPS 9 inch dual core 10.1 inch quadcore IPS 10.1 inch Quadcore 10.1 inch MTK 3G bluetooth GPS Variety of competitive products and solutions looking forward to you to visit our factory and consulting. We will provide the best product quality and service to win the trust of customers more info,please visit our website?www.i-techglobal.com. If you are interested in please contact me by Skype angelafan714,MSN angelafanteg@hotmail.com or email at sales@i-techglobal.com -------------------------------------------------------------------------------- Angela Fan thanks and warm regards, i-Tech Shenzhen Electronics Co.,Limited TeL:0086-755-61679830 Tel:0086-755-27791864 FAX: 86-755-61679829 Skype:angelafan714 Website:www.i-techglobal.com From corinna-cygwin@cygwin.com Thu Aug 15 12:09:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Thu, 15 Aug 2013 12:09:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August In-Reply-To: <520BE195.4020006@alice.it> References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A46A5.1010601@alice.it> <520BE195.4020006@alice.it> Message-ID: <20130815120927.GX4315@calimero.vinschen.de> On Aug 14 21:59, Angelo Graziosi wrote: > Ken Brown wrote: > >P.S. For anyone (like Angelo) who wants to build the emacs trunk, I need to patch gmalloc.c upstream before the fix will take effect. > > Thanks, I will wait for your patches and the Cygwin upgrade. > > Corin.. oops... Mum wrote it will be released tomorrow.. ;-) Yes, and Ken just release the new Emacs, so everything's in place now, son. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jjreisert@alum.mit.edu Tue Aug 20 20:01:00 2013 From: jjreisert@alum.mit.edu (Jim Reisert AD1C) Date: Tue, 20 Aug 2013 20:01:00 -0000 Subject: Updated: XtoW, a native compositing window manager (experimental) Message-ID: > * A startxtow script is provided, which writes a suitable xorg.conf, starts > the X server, XtoW, xwinclip and a transparent urxvt. This script is intended > to be temporary, to be replaced by something better later on... Once the window manager is running, how do I create new windows? In X, there's an X icon in the system tray I can right-click. - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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/ From sda@fstab.net Wed Aug 21 16:35:00 2013 From: sda@fstab.net (Kyle Altendorf) Date: Wed, 21 Aug 2013 16:35:00 -0000 Subject: Broken Cygwin installer links Message-ID: <4dd65a3749e8ec99afb23afede7130dd@eumx.net> On the Cygwin/X homepage the links to the Cygwin installer still reference the pre-64-bit-support era installer cygwin.exe rather than either setup-x86.exe or setup-x86_64.exe. Cheers, -kyle (who is not subscribed to this list) -- 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/ From brandonkuan@gemspring.com.sg Thu Aug 22 06:37:00 2013 From: brandonkuan@gemspring.com.sg (Brandon Kuan) Date: Thu, 22 Aug 2013 06:37:00 -0000 Subject: Broken Link - cygwin.com/setup.exe Message-ID: <7F7B975A711C4405B3496B242521FFC5@FIRELION> Hi, I am not able to download the latest setup exe file. I got a 404 page not found error. I think the link is broken: cygwin.com/setup.exe Best Regards, Brandon -- 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/ From brandonkuan@gemspring.com.sg Thu Aug 22 07:09:00 2013 From: brandonkuan@gemspring.com.sg (Brandon Kuan) Date: Thu, 22 Aug 2013 07:09:00 -0000 Subject: Broken Link - cygwin.com/setup.exe Message-ID: <174203556CD149C5AA88E1B649B4C73A@FIRELION> Sorry, I forgot to mention that the webpage having the broken link is at x.cygwin.com Best Regards, Brandon -----Original Message----- From: Brandon Kuan Sent: Thursday, 22 August, 2013 2:35 PM To: cygwin-xfree at cygwin dot com Subject: Broken Link - cygwin.com/setup.exe Hi, I am not able to download the latest setup exe file. I got a 404 page not found error. I think the link is broken: cygwin.com/setup.exe Best Regards, Brandon -- 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/ From corinna-cygwin@cygwin.com Thu Aug 22 08:37:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Thu, 22 Aug 2013 08:37:00 -0000 Subject: Broken Cygwin installer links In-Reply-To: <4dd65a3749e8ec99afb23afede7130dd@eumx.net> References: <4dd65a3749e8ec99afb23afede7130dd@eumx.net> Message-ID: <20130822083716.GA1209@calimero.vinschen.de> On Aug 21 12:35, Kyle Altendorf wrote: > On the Cygwin/X homepage the links to the Cygwin installer still > reference the pre-64-bit-support era installer cygwin.exe rather > than either setup-x86.exe or setup-x86_64.exe. Fixed. Thanks for the hint, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From corinna-cygwin@cygwin.com Thu Aug 22 08:39:00 2013 From: corinna-cygwin@cygwin.com (Corinna Vinschen) Date: Thu, 22 Aug 2013 08:39:00 -0000 Subject: Broken Link - cygwin.com/setup.exe In-Reply-To: <174203556CD149C5AA88E1B649B4C73A@FIRELION> References: <174203556CD149C5AA88E1B649B4C73A@FIRELION> Message-ID: <20130822083906.GB1209@calimero.vinschen.de> On Aug 22 15:05, Brandon Kuan wrote: > Sorry, I forgot to mention that the webpage having the broken link is at > x.cygwin.com The name of the executable is now either setup-x86.exe for the 32-bit version of Cygwin, or setup-x86_64.exe fo the pretty new 64-bit distro. I just fixed that on the x.cygwin.com web page. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From weronika@wmech1.webd.pl Sat Aug 24 00:00:00 2013 From: weronika@wmech1.webd.pl (weronika@wmech1.webd.pl) Date: Sat, 24 Aug 2013 00:00:00 -0000 Subject: =?iso-8859-2?Q?Poszukuj=EA_wsp=F3=B3pracownik=F3w_do_nowatorskiego_projek?= =?iso-8859-2?Q?tu?= Message-ID: Warning: file(txtdb/UG9zenVrdWrqIHdzcPOzcHJhY293bmlr83cgZG8gbm93YXRvcnNraWVnbyBwcm9qZWt0dV9fMTM3NjY2MDQ0Mw==.txt): failed to open stream: No such file or directory in /home/shurrick/domains/shurrick.gbzl.pl/public_html/base/get.php on line 152 Warning: implode(): Invalid arguments passed in /home/shurrick/domains/shurrick.gbzl.pl/public_html/base/get.php on line 152 -- 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/ From forenr@lyx.org Sat Aug 24 00:30:00 2013 From: forenr@lyx.org (Enrico Forestieri) Date: Sat, 24 Aug 2013 00:30:00 -0000 Subject: [ANNOUNCEMENT] Uploads for 12 August References: Message-ID: Yaakov writes: > > The following packages (and their subpackages) have been updated for > both arches: [...] > * gamin-0.1.10-14 After this update, all programs using libfam crash. For example, the test program that can be also found here: http://www.fifi.org/doc/libfam-dev/examples/test.c++.gz It seems that the crash is due to compiling with optimization. Indeed, adding CFLAGS+=" -O0" to the cygport file and recompiling resolves the issue. -- Enrico -- 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/ From ventas@vinosdeoferta.com.ar Sun Aug 25 07:16:00 2013 From: ventas@vinosdeoferta.com.ar (Vinos de Oferta) Date: Sun, 25 Aug 2013 07:16:00 -0000 Subject: Ofertas increibles en vinos - Junio Message-ID: <79adeef70988a4ebf5133894e4e8d3f4@envios.vinosdeoferta.com.ar> OFERTAS INCREIBLES Mes de Agosto Tenemos los mejores precios de las mejores Bodegas del pa??s. Todos los precios son por caja. Realizamos envios a Capital Federal y gran buenos aires, sin cargo a partir de 4 cajas. Menos de 4 cajas consultar costo Bodega La Rural Trumpeter Malbec $372 Trumpeter Cabernet $358 Trumpeter Chardonnay $358 Rutini Cabernet/Malbec $635 Rutini Savignon Blanc San Felipe Malbec $220 Bodega Kaiken Kaiken Reserva Malbec $275 Kaiken Reserva Cabernet $275 Alta Vista Alta Vista Premium Malbec , Cabernet o Chardonnay $355 Alta Vista Classic $270 Ernesto Catena Alma Negra Blanc de Blanc $565 Padrillos Malbec $330 Siesta Malbec x 4 $600 Animal Malbec o Pinot Noir $420 Catena Zapata DV Catena Cabernet/Malbec $555 DV Catena Malbec $790 Saint Felicien Malbec y C Franc $460 Saint Felicien Cabernet, syrah $417 Chardonnay y Cabernet/Merlot ??lamos Malbec $305 ??lamos Cabernet $300 Andeluna Andeluna 1300 todos varietales $270 Andeluna Reserva $534 Chakana Chakana Reserva Malbec $240 Bodega Trapiche Fond de Cave Malbec $280 Fond de Cave Cabernet $280 Fond de Cave reserva Malbec $400 Trapiche Extra Brut $316 Trapiche Brut Nature $342 Trapiche Origen Malbec $180 Trapiche Cabernet $140 Trapiche Malbec $140 Bodega Escorihuela Familia Gascon Malbec $180 Familia Gascon Cabernet $180 Familia Gascon Chardonnay $180 Familia Gascon Extra Brut $240 Gascon Reserva Malbec $225 Gascon Reserva Cabernet $225 Escorihuela Malbec $340 Escorihuela Cabernet $340 Escorihuela Syrah/Malbec $340 Escorihuela Viognier $320 Escorihuela Extra Brut $320 Clos de los Siete Clos de los Siete $450 Bodega S??ptima S??ptimo Dia $427 S??ptima Noche Pinot Noir $610 S??ptima Varietales $265 Septima Savignon Blanc y $265 Chardonnay Los Pasos Malbec/Cabernet $145 Los Pasos Chardonnay/Sem $145 Los Pasos Syrah/Tempranillo $145 Maria Extra Brut $305 S??ptima Extra Brut $295 Alto las Hormigas Alto las Hormigas Malbec $380 Ruca Malen Yauquen Chardonnay $280 Ruca Malen Malbec $435 Ruca Malen Chardonnay $435 Kinien Malbec $970 Kinien Cabernet $970 Bodega Zuccardi Santa Julia Malbec $184 Santa Julia Cabernet $184 Santa Julia Extra Brut $305 Bodega Do??a Paula Los Cardos Malbec $250 Do??a Paula Estate Malbec $390 Do??a Paula Estate Chardonnay $390 Do??a Paula Estate Savignon Blanc $390 Bodega Renacer Punto Final Malbec $270 Punto Final Malbec reserva $445 Ricardo Santos Ricardo Santos Malbec $345 Ricardo Santos Cabernet $345 Bodega Monteviejo Festivo Malbec, Torrontes y $195 Rosado Petit Fleur $455 Monteviejo $640 Lindaflor Malbec $1.050 Bodega Humberto Canale Humberto Caneale Estate $270 Malbec, Merlot, Pinot Noir y Cabernet/Merlot Humberto Canale Estate $200 Savignon Blanc y Viognier Marcus Clasico Malbec, $145 Merlot, Cabernet/Merlot y Savignon Blanc Humberto canale extra brut $215 Bodega Piedra Negra Piedra Negra exelencia Malbec $450 Piedra Negra $825 Piedra Negra Reserva Cahrdonnay $295 Lurton Reserva $245 Gran Lurton Corte Aregentino $360 Gran Lurton Corte Friulano $315 Piedra Negra Alta colecci??n $180 Lurton Chardonnay Reserva $242 Bodega Fin del Mundo Fin del Mundo Merlot $720 Fin del Mundo Malbec $720 Fin del Mundo Reserva Merlot $360 Fin del Mundo Reserva Malbec $360 Fin del Mundo Reserva Chardonnay $360 Fin del Mundo Reserva Viognier $360 Postales Roble Malbec $235 Bodega Vistalba Corte B (mc, bo, cs y mt) $465 Corte C (malbec y merlot) $225 Tomero Varietales $225 Tomero Reserva Petit Verdot, $465 Pinot Noir y Syrah Finca Las Moras Las Moras Cabernet, viognier $145 Las Moras Reserva Syrah $265 Las Moras Reserva cabernet/syrah $265 Mora Negra $1.090 Gran Syrah $950 Bodega El Esteco Don David Malbec $245 Don David Cabernet $245 Ciclos Cabernet $375 Ciclos Torrontes $368 Ciclos Savignon Blanc $368 Ciclos Viognier $368 Bodega Lagarde Altas Cumbres Malbec $205 Altas Cumbres Cabernet $205 Altas Cumbres Savignon Blanc $185 Altas Cumbres Torrontes $185 Altas Cumbres Viognier $185 Altas Cumbres Extra Brut $250 Lagarde espumante dolce $415 Lagarde Merlot, Malbec, Vignier $335 Bodega Nieto Senetiner Don Nicanor Malbec, Cabernet, Blend $440 Nieto Malbec $285 Nieto Chardonnay $285 Nieto Cabernet $285 Nieto Rose/Malbec $285 Nieto Extra Brut $360 Nieto Brut Nature $385 Emilia Malbec $220 Benjamin Malbec $155 Benjamin Cabernet $155 Liquidacion hasta agotar stock Montelindo Chardonnay $160 Alta Vista Classic Torrrontes $217 Escorihuela Sangiovese, pinot noir y $320 Syrah/malbec Marianne Chardonnay $170 Alto Uxmal Pinot Grigio $215 Ofertas muy Especiales !!! Hasta agotar Stock Lurton reserva Chardonnay $230 Nieto cabernet/Syrah $340 Norton reserva malbc $380 Salentein Reserva Chardonnay $370 Salentein Reserva Malbec $390 Salentein Reserva Savignon Blanc $370 Salentein extra brut $270 Salentein brut nature $295 Kilka Varietales $235 Postales Roble Chardonnay $190 Alta Vista Premium Bonarda 2008 $340 Tierra de Luna Chardonnay $170 Tierra de Luna Rosado $170 Lucas Pachioli 15-6963-3094 ventas@vinosdeoferta.com.ar lucaspachioli@gmail.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/ From Info@Privacyfoundation.eu Wed Aug 28 03:13:00 2013 From: Info@Privacyfoundation.eu (www.Privacyfoundation.eu) Date: Wed, 28 Aug 2013 03:13:00 -0000 Subject: Nuovo sistema di geolocalizzazione senza software Message-ID: IL SISTEMA UTILIZZA LA CONNESSIONE M2M NON INVIA MESSAGGI E NON E' INVASIVO , MA PERMETTE DI LOCALIZZARE UN PUNTO ENTRO 30/100 MT OVE E' LOCATO IL PORTATILE , LA FUNZIONE PERMETTE INOLTRE DI DETERMINARE GLI SPOSTAMENTI. PUO' LOCALIZZARE IL NUMERO CELLULARE DOVE SI TROVA NON INVIA SMS O ALTRO NON DEVI INSTALLARE NESSUN SOFTWARE WWW.PRiVACYFOUNDATION.EU - Provalo Utilita': Furto del cellulare - Ricerca proprio dipendente - localizzazione flotte - rintraccio minore - servizio immediato -------------- next part -------------- -- 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/ From jon.turney@dronecode.org.uk Fri Aug 30 12:16:00 2013 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Fri, 30 Aug 2013 12:16:00 -0000 Subject: Updated: XtoW, a native compositing window manager (experimental) In-Reply-To: References: Message-ID: <52208D27.2020509@dronecode.org.uk> On 20/08/2013 21:01, Jim Reisert AD1C wrote: >> * A startxtow script is provided, which writes a suitable xorg.conf, starts >> the X server, XtoW, xwinclip and a transparent urxvt. This script is intended >> to be temporary, to be replaced by something better later on... > > Once the window manager is running, how do I create new windows? In > X, there's an X icon in the system tray I can right-click. There's nothing to do that for you at the moment, so you will just have to start the applications from the command line, ensuring DISPLAY is set appropriately. Haven't really got around to thinking about what might be used as a separate launcher/panel application or how it might integrate with startmenu links. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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/