[RFU] SuiteSparse-3.6.1
new upstream version To download: wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/SuiteSparse/index.html rm ./index.html \ ./libSuiteSparse-devel/index.html file list: libSuiteSparse-devel/libSuiteSparse-devel-3.6.1-1.tar.bz2 libSuiteSparse-devel/setup.hint setup.hint SuiteSparse-3.6.1-1-src.tar.bz2 SuiteSparse-3.6.1-1.tar.bz2 Regards Marco
Re: [RFU] SuiteSparse-3.6.1
On Aug 5 08:59, Marco atzeri wrote: new upstream version To download: wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/SuiteSparse/index.html rm ./index.html \ ./libSuiteSparse-devel/index.html Uploaded. What about the old versions 3.2.0-3, 3.4.0-3, 3.5.0-1? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] SuiteSparse-3.6.1
On 8/5/2011 9:41 AM, Corinna Vinschen wrote: On Aug 5 08:59, Marco atzeri wrote: new upstream version To download: wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/SuiteSparse/index.html rm ./index.html \ ./libSuiteSparse-devel/index.html Uploaded. What about the old versions 3.2.0-3, 3.4.0-3, 3.5.0-1? Thanks, Corinna only 3.5.0-1 Thanks Marco
Re: [RFU] SuiteSparse-3.6.1
On Aug 5 09:46, Marco atzeri wrote: On 8/5/2011 9:41 AM, Corinna Vinschen wrote: On Aug 5 08:59, Marco atzeri wrote: new upstream version To download: wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/SuiteSparse/index.html rm ./index.html \ ./libSuiteSparse-devel/index.html Uploaded. What about the old versions 3.2.0-3, 3.4.0-3, 3.5.0-1? Thanks, Corinna only 3.5.0-1 Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[patch/rebase] peflags.c: Use official file structures, make 64 bit capable
Hi Chuck,
the below patch cleans up peflags so that it uses the official Windows
types to access the COFF and PE flags via a memory map, rather than
seek/read, seek/write to some undocumented byte offsets. This patch
also makes peflags capable to read and change 64 bit files.
Reading and writing other header info (namely stacksize) follows later.
Patch builds and is tested on Cygwin and x86_64-mingw64.
Ok to apply?
Thanks,
Corinna
* peflags.c: Include sys/mman.h on Cygwin and msys. Drop conditional
definitions of uint16_t and uint32_t. Use WORD rather than uint16_t
throughout, size_t rather than uint32_t.
(IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE): Define if non-existant to
workaround broken w32api. Fix usage of broken definition throughout.
(IMAGE_DLLCHARACTERISTICS_NX_COMPAT): Ditto.
(IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY): Ditto.
(pe_get16): Remove.
(pe_get32): Remove.
(pe_set16): Remove.
(mmap): Define in terms of Win32 calls for non-Cygwin systems.
(munmap): Ditto.
(pe_file): New type to keep file mapping info.
(pe_open): New function to mmap PE/COFF files.
(pe_close): New function to unmap PE/COFF files.
(get_characteristics): Use pe_opem/pe_close and direct Windows
file structure access.
(set_coff_characteristics): Ditto.
(set_pe_characteristics): Ditto.
Index: peflags.c
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/peflags.c,v
retrieving revision 1.5
diff -u -p -r1.5 peflags.c
--- peflags.c 29 Jul 2011 13:17:44 - 1.5
+++ peflags.c 5 Aug 2011 11:09:42 -
@@ -29,25 +29,34 @@
#include unistd.h
#include getopt.h
#include errno.h
+#if defined (__CYGWIN__) || defined (__MSYS__)
+#include sys/mman.h
+#endif
#include windows.h
-#if defined(__MSYS__)
-typedef unsigned short uint16_t;
-typedef unsigned int uint32_t;
+/* Fix broken definitions in older w32api. */
+#ifndef IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE
+#define IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE
IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE
+#endif
+#ifndef IMAGE_DLLCHARACTERISTICS_NX_COMPAT
+#define IMAGE_DLLCHARACTERISTICS_NX_COMPAT IMAGE_DLL_CHARACTERISTICS_NX_COMPAT
+#endif
+#ifndef IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY
+#define IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY
IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY
#endif
-static uint16_t coff_characteristics_set;
-static uint16_t coff_characteristics_clr;
-static uint16_t coff_characteristics_show;
-static uint16_t pe_characteristics_set;
-static uint16_t pe_characteristics_clr;
-static uint16_t pe_characteristics_show;
+static WORD coff_characteristics_set;
+static WORD coff_characteristics_clr;
+static WORD coff_characteristics_show;
+static WORD pe_characteristics_set;
+static WORD pe_characteristics_clr;
+static WORD pe_characteristics_show;
typedef struct {
long flag;
const char * name;
- uint32_t len;
+ size_tlen;
} symbolic_flags_t;
#define CF(flag,name) { flag, #name, sizeof(#name) - 1 }
@@ -118,29 +127,26 @@ static void version (FILE *f);
int do_mark (const char *pathname);
int get_characteristics(const char *pathname,
-uint16_t* coff_characteristics,
-uint16_t* pe_characteristics);
+WORD* coff_characteristics,
+WORD* pe_characteristics);
int set_coff_characteristics(const char *pathname,
- uint16_t coff_characteristics);
+ WORD coff_characteristics);
int set_pe_characteristics(const char *pathname,
- uint16_t pe_characteristics);
-static int pe_get16 (int fd, off_t offset, uint16_t* value);
-static int pe_get32 (int fd, off_t offset, uint32_t* value);
-static int pe_set16 (int fd, off_t offset, uint16_t value);
+ WORD pe_characteristics);
static void display_flags (const char *field_name, const symbolic_flags_t
*syms,
- uint16_t show_symbolic, uint16_t old_flag_value,
- uint16_t new_flag_value);
+ WORD show_symbolic, WORD old_flag_value,
+ WORD new_flag_value);
static char *symbolic_flags (const symbolic_flags_t *syms, long show, long
value);
static void append_and_decorate (char **str, int is_set, const char *name, int
len);
static void *xmalloc (size_t num);
#define XMALLOC(type, num) ((type *) xmalloc ((num) * sizeof(type)))
static void handle_coff_flag_option (const char *option_name,
const char *option_arg,
- uint16_t flag_value);
+ WORD flag_value);
static void handle_pe_flag_option (const char *option_name,
Re: [Patch] Add rebase-dump application to rebase package
On Aug 3 09:44, Charles Wilson wrote:
On 8/3/2011 4:30 AM, Corinna Vinschen wrote:
Hmm. I just figured that moving the entire db stuff into rebase-db.c
isn't as simple as I imagined. Functions and global variables are
pretty much intertwined in a non modular way.
Yep...I had similar, but much smaller, issues when moving the dump_*
methods to rebase-db.[h,c]. This will be a non-trivial refactoring.
I assume you might just go ahead and apply your dumper and we get
a new rebase package out of the door. We can clean this up later.
Ack. Given Jason hasn't reponded to my patch, and your positive review,
I've invoked the libtool 3-day rule and committed it.
Idle musing: I think we should create some sort of global settings
structure which can be used as a parameter or something...
Yep. That's typically the way I handle these issues, even in very simple
apps that don't need it -- 'cause they ALWAYS grow to become non-simple,
and it's a lot harder to add it later. :-)
But that can also wait until after the next release. AFAICT, we're
ready to go -- so it's up to Jason to bump the library and application
version numbers, tag it in cvs, and publish a new package.
Your rebase-dump doesn't build cleanly on mingw64:
cc1: warnings being treated as errors
rebase-dump.c: In function ‘load_image_info’:
rebase-dump.c:128:6: error: format ‘%u’ expects type ‘unsigned int’, but
argument 2 has type ‘long long unsigned int’
rebase-dump.c:128:6: error: format ‘%08x’ expects type ‘unsigned int’, but
argument 3 has type ‘long long unsigned int’
rebase-dump.c:183:15: error: format ‘%u’ expects type ‘unsigned int’, but
argument 2 has type ‘long long unsigned int’
rebase-dump.c:183:15: error: format ‘%08x’ expects type ‘unsigned int’, but
argument 3 has type ‘long long unsigned int’
make: *** [rebase-dump.o] Error 1
Here's my fix:
Index: rebase-dump.c
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/rebase-dump.c,v
retrieving revision 1.1
diff -u -p -r1.1 rebase-dump.c
--- rebase-dump.c 3 Aug 2011 13:40:16 - 1.1
+++ rebase-dump.c 5 Aug 2011 11:31:28 -
@@ -124,7 +124,7 @@ load_image_info ()
return -1;
}
if (verbose)
-printf (== read %u (0x%08x) bytes (database header)\n,
+printf (== read %zu (0x%08zx) bytes (database header)\n,
sizeof hdr, sizeof hdr);
/* Check the header. */
@@ -178,7 +178,7 @@ load_image_info ()
}
if (ret == 0 verbose)
{
- printf (== read %u (0x%08x) bytes (database w/o strings)\n,
+ printf (== read %zu (0x%08zx) bytes (database w/o strings)\n,
img_info_size * sizeof (img_info_t),
img_info_size * sizeof (img_info_t));
}
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [patch/rebase] peflags.c: Use official file structures, make 64 bit capable
On Aug 5 13:17, Corinna Vinschen wrote:
Hi Chuck,
the below patch cleans up peflags so that it uses the official Windows
types to access the COFF and PE flags via a memory map, rather than
seek/read, seek/write to some undocumented byte offsets. This patch
also makes peflags capable to read and change 64 bit files.
Reading and writing other header info (namely stacksize) follows later.
Patch builds and is tested on Cygwin and x86_64-mingw64.
Ok to apply?
Second service. I left in everything I only added for debugging a
problem I had with my the native mmap implementation. For some reason
the data was never written back to the file. Turned out I had used
flags instead of prot in the conditionals. That was already fixed
in the previous patch, but the debug stuff was really supposed to go away.
Here we go, ChangeLog is unchanged...
Corinna
Index: peflags.c
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/peflags.c,v
retrieving revision 1.5
diff -u -p -r1.5 peflags.c
--- peflags.c 29 Jul 2011 13:17:44 - 1.5
+++ peflags.c 5 Aug 2011 12:50:29 -
@@ -29,25 +29,34 @@
#include unistd.h
#include getopt.h
#include errno.h
+#if defined (__CYGWIN__) || defined (__MSYS__)
+#include sys/mman.h
+#endif
#include windows.h
-#if defined(__MSYS__)
-typedef unsigned short uint16_t;
-typedef unsigned int uint32_t;
+/* Fix broken definitions in older w32api. */
+#ifndef IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE
+#define IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE
IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE
+#endif
+#ifndef IMAGE_DLLCHARACTERISTICS_NX_COMPAT
+#define IMAGE_DLLCHARACTERISTICS_NX_COMPAT IMAGE_DLL_CHARACTERISTICS_NX_COMPAT
+#endif
+#ifndef IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY
+#define IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY
IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY
#endif
-static uint16_t coff_characteristics_set;
-static uint16_t coff_characteristics_clr;
-static uint16_t coff_characteristics_show;
-static uint16_t pe_characteristics_set;
-static uint16_t pe_characteristics_clr;
-static uint16_t pe_characteristics_show;
+static WORD coff_characteristics_set;
+static WORD coff_characteristics_clr;
+static WORD coff_characteristics_show;
+static WORD pe_characteristics_set;
+static WORD pe_characteristics_clr;
+static WORD pe_characteristics_show;
typedef struct {
long flag;
const char * name;
- uint32_t len;
+ size_tlen;
} symbolic_flags_t;
#define CF(flag,name) { flag, #name, sizeof(#name) - 1 }
@@ -118,29 +127,26 @@ static void version (FILE *f);
int do_mark (const char *pathname);
int get_characteristics(const char *pathname,
-uint16_t* coff_characteristics,
-uint16_t* pe_characteristics);
+WORD* coff_characteristics,
+WORD* pe_characteristics);
int set_coff_characteristics(const char *pathname,
- uint16_t coff_characteristics);
+ WORD coff_characteristics);
int set_pe_characteristics(const char *pathname,
- uint16_t pe_characteristics);
-static int pe_get16 (int fd, off_t offset, uint16_t* value);
-static int pe_get32 (int fd, off_t offset, uint32_t* value);
-static int pe_set16 (int fd, off_t offset, uint16_t value);
+ WORD pe_characteristics);
static void display_flags (const char *field_name, const symbolic_flags_t
*syms,
- uint16_t show_symbolic, uint16_t old_flag_value,
- uint16_t new_flag_value);
+ WORD show_symbolic, WORD old_flag_value,
+ WORD new_flag_value);
static char *symbolic_flags (const symbolic_flags_t *syms, long show, long
value);
static void append_and_decorate (char **str, int is_set, const char *name, int
len);
static void *xmalloc (size_t num);
#define XMALLOC(type, num) ((type *) xmalloc ((num) * sizeof(type)))
static void handle_coff_flag_option (const char *option_name,
const char *option_arg,
- uint16_t flag_value);
+ WORD flag_value);
static void handle_pe_flag_option (const char *option_name,
const char *option_arg,
- uint16_t flag_value);
+ WORD flag_value);
void parse_args (int argc, char *argv[]);
int string_to_bool (const char *string, int *value);
int string_to_ulong (const char *string, unsigned long *value);
@@ -221,10 +227,10 @@ do_mark (const char *pathname)
int has_relocs;
int is_executable;
int is_dll;
- uint16_t old_coff_characteristics;
- uint16_t new_coff_characteristics;
- uint16_t old_pe_characteristics;
- uint16_t new_pe_characteristics;
+
Re: [Patch] Add rebase-dump application to rebase package
On 8/5/2011 7:31 AM, Corinna Vinschen wrote: Your rebase-dump doesn't build cleanly on mingw64: Here's my fix: -printf (== read %u (0x%08x) bytes (database header)\n, +printf (== read %zu (0x%08zx) bytes (database header)\n, sizeof hdr, sizeof hdr); Unfortunately, msys doesn't support %z: == read zu (0x000zx) bytes (database header) I see two solutions: (1) #ifdefs in some manner -- e.g. incode, or a top-of-file defining the string to use for size_t arguments (decimal and hex) or (2) use a temporary variable of type unsigned long long, and assign the result of the sizeof() computation to that var, and then use %llu or %llx. Which approach do you think is better? -- Chuck
Re: [Patch] Add rebase-dump application to rebase package
On Aug 5 09:07, Charles Wilson wrote:
On 8/5/2011 7:31 AM, Corinna Vinschen wrote:
Your rebase-dump doesn't build cleanly on mingw64:
Here's my fix:
-printf (== read %u (0x%08x) bytes (database header)\n,
+printf (== read %zu (0x%08zx) bytes (database header)\n,
sizeof hdr, sizeof hdr);
Unfortunately, msys doesn't support %z:
== read zu (0x000zx) bytes (database header)
I see two solutions: (1) #ifdefs in some manner -- e.g. incode, or a
top-of-file defining the string to use for size_t arguments (decimal and
hex) or (2) use a temporary variable of type unsigned long long, and
assign the result of the sizeof() computation to that var, and then use
%llu or %llx.
Which approach do you think is better?
What about this:
Index: rebase-db.h
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/rebase-db.h,v
retrieving revision 1.2
diff -u -p -r1.2 rebase-db.h
--- rebase-db.h 3 Aug 2011 13:40:16 - 1.2
+++ rebase-db.h 5 Aug 2011 14:07:50 -
@@ -21,6 +21,13 @@
#include windows.h
#include stdio.h
+#if defined(__MSYS__)
+/* MSYS has no inttypes.h */
+# define PRIu64 llu
+# define PRIx64 llx
+#else
+# include inttypes.h
+#endif
#define roundup(x,y) x) + ((y) - 1)) / (y)) * (y))
#define roundup2(x,y) (((x) + (y) - 1) ~((y) - 1))
Index: rebase-dump.c
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/rebase-dump.c,v
retrieving revision 1.1
diff -u -p -r1.1 rebase-dump.c
--- rebase-dump.c 3 Aug 2011 13:40:16 - 1.1
+++ rebase-dump.c 5 Aug 2011 14:07:50 -
@@ -124,8 +124,8 @@ load_image_info ()
return -1;
}
if (verbose)
-printf (== read %u (0x%08x) bytes (database header)\n,
- sizeof hdr, sizeof hdr);
+printf (== read % PRIu64 (0x%08 PRIx64 ) bytes (database header)\n,
+ (unsigned long long) sizeof hdr, (unsigned long long) sizeof hdr);
/* Check the header. */
if (memcmp (hdr.magic, IMG_INFO_MAGIC, 4) != 0)
@@ -178,9 +178,9 @@ load_image_info ()
}
if (ret == 0 verbose)
{
- printf (== read %u (0x%08x) bytes (database w/o strings)\n,
- img_info_size * sizeof (img_info_t),
- img_info_size * sizeof (img_info_t));
+ printf (== read % PRIu64 (0x%08 PRIx64 ) bytes (database w/o
strings)\n,
+ (unsigned long long) img_info_size * sizeof (img_info_t),
+ (unsigned long long) img_info_size * sizeof (img_info_t));
}
/* Make sure all pointers are NULL (also dump db as read) */
if (ret == 0)
Index: rebase.c
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/rebase.c,v
retrieving revision 1.10
diff -u -p -r1.10 rebase.c
--- rebase.c29 Jul 2011 13:17:44 - 1.10
+++ rebase.c5 Aug 2011 14:07:50 -
@@ -36,12 +36,6 @@
#include locale.h
#include getopt.h
#include string.h
-#if defined(__MSYS__)
-/* MSYS has no inttypes.h */
-# define PRIx64 llx
-#else
-# include inttypes.h
-#endif
#include errno.h
#include imagehelper.h
#include rebase-db.h
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [Patch] Add rebase-dump application to rebase package
On Aug 5 10:17, Charles Wilson wrote: On 8/5/2011 10:08 AM, Corinna Vinschen wrote: On Aug 5 09:07, Charles Wilson wrote: Which approach do you think is better? What about this: Sure, that looks fine. Go ahead and check it in. (No point in waiting around for Jason right now, since he's AFK). Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: 256x256 px icons
On 4 August 2011 15:29, Corinna Vinschen wrote: On Aug 4 09:19, Charles Wilson wrote: On 8/4/2011 4:39 AM, Corinna Vinschen wrote: Sure! I would be more happy with the fatbuttlarry icon if it would be available in a nice 256x256 variation, though. That's really a big plus of Warren's version. Here (well, it's 237x258 but that's nothing that can't be fixed with little GIMP). Nice, thank you. Ditto. Where did you find that? There isn't a vector version of this, is there? I'm asking because that would allow to remove the shadow under the C without impacting the edge of the C which has a bit of a fade-out on it. I realised that I'd used the 24bpp version of cygicons-0.dll,9, which doesn't have the shadow, but only because it doesn't have an alpha channel. Do you know how to convert the green glow around the C to grey, by any chance? Here's what I did, in Paint.net. I very much suspect there are better ways. - Select the green arrow with the rectangular select tool. - Invert the selection, thereby selecting everything but the green arrow. - Go to Adjustments-Hue/Saturation: Turn the hue to -60 (yellow) and the saturation to 200 (maximum). OK. - Adjustments-Black and White. (The point of turning it bright yellow before the Black and White step is to make the resulting grey as light as possible.) Andy
Re: 256x256 px icons
On 8/5/2011 11:05 AM, Andy Koppe wrote: On 4 August 2011 15:29, Corinna Vinschen wrote: On Aug 4 09:19, Charles Wilson wrote: Here (well, it's 237x258 but that's nothing that can't be fixed with little GIMP). Nice, thank you. Ditto. Where did you find that? It's at the same place I got the original windows icon: http://kde-look.org/content/show.php?content=36393 It's the 'Fedora' download. There isn't a vector version of this, is there? Not that I could see. There's contact info for fatbuttlarry at the link, but it's several years old, so no telling if it is still accurate, or if fbl would respond, or if he still HAS any original vector artwork, or if he'd be willing to share it... (The pentajock link on the page above is dead, so that doesn't bode well) -- Chuck
[Patch/rebase] Update docs
FYI, I went ahead and committed the following updates to NEWS and README. Also, took the opportunity to correct some typos and such in ChangeLog. patch gzip'ed because qmail hates embedded email addresses. -- Chuck update-doc.patch.gz Description: GNU Zip compressed data
Re: 256x256 px icons
On 8/3/2011 11:49 PM, Andy Koppe wrote: Warren's has the advantage of a 256 version and that it's more tweakable assuming he provides the vector version it's presumably based on. Sorry, there is currently no vector version. Effects like bevels and shadows are raster effects. However, based on this: https://secure.wikimedia.org/wikipedia/en/wiki/SVG_filter_effects it does look like SVG's been extended with the raster effects needed to recreate my beveled icon. I am installing Inkscape now and will try to do that later, perhaps today, perhaps not. In the meanwhile, here's my new beveled Cygwin logo: http://etr-usa.com/cygwin/logo/beveled-noshadow.psd Changes from the original: - removed the big drop shadow (outer glow still present) - softened lighting on the wedge - dropped outer C stroke from white to a light gray - rebuilt as 1024 px square, not counting the outer glow, for finer editing control This should open in any version of Photoshop going back to the 90s. (v6 and up, I'm guessing.) While I realize not everyone will have even that, I'm providing it because it's based on easy-to-edit procedural effects, rather than flattened raster effects. However, I have made a fully rasterized, layered version compatible with Gimp for those without even Photoshop 6.0: http://etr-usa.com/cygwin/logo/beveled-noshadow-rasterized.xcf I also made a 256 px .ico, for those who just want to see it in action: http://etr-usa.com/cygwin/logo/beveled-noshadow.ico
Re: 256x256 px icons
On 8/4/2011 12:16 PM, Corinna Vinschen wrote: On Aug 4 13:24, Charles Wilson wrote: On 8/4/2011 10:29 AM, Corinna Vinschen wrote: Nice, thank you. Do you know how to convert the green glow around the C to grey, by any chance? Not...exactly. I think you should be able to use the magic wand selection tool (with appropriate options), and then apply a desaturate or color shift filter to the selected region. But, that's only a guess. I tried that for about 45 minutes. Don't ask to see any results :( In Gimp, you can say Colors Hue-Saturation, then click the radio button next to the green color chip to restrict the adjustment to the greens. Dropping Saturation should then give you the result you want. Avoid the Tragic Wand. It is almost never the right tool for the job. There are whole books on better selection methods: http://www.amazon.com/dp/0321441206/ http://www.amazon.com/dp/0735712794/ http://www.amazon.com/dp/0321808231/ Yes, they're all to do with Photoshop, but the principles are the same. In the case of Hue-Saturation, Gimp/PS is computing a mask for you automatically when you restrict it to a color range. When not dealing with simple logo art, you often have to resort to the more advanced techniques in the books I've recommended above.
Re: 256x256 px icons
On Aug 5 10:13, Warren Young wrote: On 8/5/2011 9:05 AM, Andy Koppe wrote: Do you know how to convert the green glow around the C to grey, by any chance? Here's what I did, in Paint.net. I very much suspect there are better ways. The right way is to use Levels. Ctrl-L in Photoshop and Paint.NET, Colors Levels in Gimp. In this case, I'd drag down the white point of the input levels to push things toward white, while leaving the dark parts of the image where they are, more or less. You could also try moving the gamma slider, either alone, or in combination with the above to keep the blacks where you want them. I don't understand this. If I do that, the black C and especially the highlights in the C are getting whiter and chunky, while the green frame gets chunky but stays green. So I'm puzzled. If I do that and then desaturize, what have I won, except that the highlights in the C are chunkier? Where's the trick? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: 256x256 px icons
On 8/5/2011 11:50 AM, Corinna Vinschen wrote: You could also try moving the gamma slider, either alone, or in combination with the above to keep the blacks where you want them. I don't understand this. If I do that, the black C and especially the highlights in the C are getting whiter and chunky, This is due to not having a layered document. The levels move is affecting everything, not just the glow. Lacking a layered document so you can modify the glow in isolation, you're back to needing a good selection to start with. Riffing off the Hue-Saturation tip from the other message, you could take essentially the same path but move the lightness slider in addition to the saturation. Between this and Andy's select wedge then invert selection you should get a good result.
Re: 256x256 px icons
On 5 August 2011 18:35, Warren Young wrote: On 8/3/2011 11:49 PM, Andy Koppe wrote: Warren's has the advantage of a 256 version and that it's more tweakable assuming he provides the vector version it's presumably based on. Sorry, there is currently no vector version. Effects like bevels and shadows are raster effects. However, based on this: https://secure.wikimedia.org/wikipedia/en/wiki/SVG_filter_effects it does look like SVG's been extended with the raster effects needed to recreate my beveled icon. I am installing Inkscape now and will try to do that later, perhaps today, perhaps not. Don't worry too much about that. The below sounds like the Photoshop version should be entirely sufficient. In the meanwhile, here's my new beveled Cygwin logo: http://etr-usa.com/cygwin/logo/beveled-noshadow.psd Changes from the original: - removed the big drop shadow (outer glow still present) - softened lighting on the wedge - dropped outer C stroke from white to a light gray - rebuilt as 1024 px square, not counting the outer glow, for finer editing control This should open in any version of Photoshop going back to the 90s. (v6 and up, I'm guessing.) While I realize not everyone will have even that, I'm providing it because it's based on easy-to-edit procedural effects, rather than flattened raster effects. However, I have made a fully rasterized, layered version compatible with Gimp for those without even Photoshop 6.0: http://etr-usa.com/cygwin/logo/beveled-noshadow-rasterized.xcf I also made a 256 px .ico, for those who just want to see it in action: http://etr-usa.com/cygwin/logo/beveled-noshadow.ico I like this a lot. Thanks very much for responding so positively to my whinging. Andy
Re: 256x256 px icons
On 5 August 2011 16:57, Charles Wilson wrote: On 8/5/2011 11:05 AM, Andy Koppe wrote: On 4 August 2011 15:29, Corinna Vinschen wrote: On Aug 4 09:19, Charles Wilson wrote: Here (well, it's 237x258 but that's nothing that can't be fixed with little GIMP). Nice, thank you. Ditto. Where did you find that? It's at the same place I got the original windows icon: http://kde-look.org/content/show.php?content=36393 It's the 'Fedora' download. There isn't a vector version of this, is there? Not that I could see. There's contact info for fatbuttlarry at the link, but it's several years old, so no telling if it is still accurate, or if fbl would respond, or if he still HAS any original vector artwork, or if he'd be willing to share it... I sent a request to the email address given there. At least it hasn't yet come back as undeliverable ... Thanks, Andy
Re: 256x256 px icons
On 8/5/2011 1:08 PM, Andy Koppe wrote: I like this a lot. Thanks very much for responding so positively to my whinging. Let me know if you need to see any other changes. I think a large part of the problem is tl;dr, and the resultant talking past each other. I know it's true for me. I've been taking a passive role since you and Corinna took my ball and ran with it, but don't take that to mean you can't ask me for changes. The main thing I need is concrete requests, such as those that lead to the present changes. I will get back to your comments about the semitransparent Konsole icon edge later. I don't see a fade-out here, no doubt because there's precious little standardization in vector art, SVG notwithstanding. That's one of the reasons I decided to install Inkscape instead of continuing to base my work on SVG art imported into Illustrator then re-exported. I'd bet AI is a lot more powerful, but if it impedes communication... Besides, PS fanboy though I am, AI fanboy I am not. :)
Re: SETUP: default to mintty
On 8/5/2011 2:04 PM, Andy Koppe wrote: Which leaves the question how the icon with the 256x256 became so big. I'd used a Cygwin build of 'icotool' from 'icoutils' for that, icotool's --help is confusing. The magic incantation is: $ icotool -c -o cygwin-term.ico -r cygwin-term.png where cygwin-term.png is the 256 px Vista icon. -r is the trick. You then append the PNG files for the smaller sizes to the list to have them translated to BMP style standard icons within the aggregate .ico. allows to embed PNGs directly, instead storing them in whatever less efficient bitmap format .ICOs have used before. .ico is originally based on BMP, which is a trivial uncompressed file format, basically a small header containing obvious things like width, height, color depth, pixel format and such, followed by raw pixel data. So, a 32 bit RGBA 256x256 .bmp or .ico will be 262,144 bytes plus header overhead. (I get 270,398 bytes here.) Your 300K+ file probably got a bit bigger due to having more icon sizes bundled in. How do you create icons including a 256x256 version? I use the ICO file plugin for Photoshop from Telegraphics, the same people that put out icobundl. You get a dialog on saving the icon, asking if you want a standard or Vista PNG .ico; I say Vista for the 256 px one, and standard for the smaller four sizes. Then, I use icobundl to take the resulting 5 .ico files and assemble them. I can do final compression and assembly if you need me to, but I think the icotool incantation will fix your problem.
Re: SETUP: default to mintty
On 8/5/2011 4:04 PM, Andy Koppe wrote: How do you create icons including a 256x256 version? I haven't managed to get the 'icobundl' utility that Warren linked to to do it. I used gimp...see this: http://gimp-tutorials.net/How-to-make-an-icon-from-a-picture (scroll down to the end for the bit about multires ico files) -- Chuck
Re: [patch/rebase] peflags.c: Use official file structures, make 64 bit capable
On 8/5/2011 8:51 AM, Corinna Vinschen wrote: On Aug 5 13:17, Corinna Vinschen wrote: the below patch cleans up peflags so that it uses the official Windows types to access the COFF and PE flags via a memory map, rather than seek/read, seek/write to some undocumented byte offsets. This patch also makes peflags capable to read and change 64 bit files. Reading and writing other header info (namely stacksize) follows later. Patch builds and is tested on Cygwin and x86_64-mingw64. Ok to apply? Second service. I left in everything I only added for debugging a problem I had with my the native mmap implementation. For some reason the data was never written back to the file. Turned out I had used flags instead of prot in the conditionals. That was already fixed in the previous patch, but the debug stuff was really supposed to go away. Here we go, ChangeLog is unchanged... Looks good, builds cleanly and works correctly on mingw(32) and msys. Go ahead. -- Chuck
src/winsup/w32api ChangeLog include/winnt.h
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-08-05 07:02:27 Modified files: winsup/w32api : ChangeLog winsup/w32api/include: winnt.h Log message: * include/winnt.h (IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE, IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY, IMAGE_DLLCHARACTERISTICS_NX_COMPAT): Fix typo in definitions. (IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE, IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY, IMAGE_DLL_CHARACTERISTICS_NX_COMPAT): Keep broken definitions for backward compatibility. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=srcr1=1.1085r2=1.1086 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winnt.h.diff?cvsroot=srcr1=1.136r2=1.137
Re: enabling /largeaddressaware for cygwin in windows 7 64-bit
On Aug 4 18:17, Charles Wilson wrote: On 8/4/2011 2:17 PM, Corinna Vinschen wrote: On Aug 4 13:37, Charles Wilson wrote: Obviously, the OP would need to pass these 'thru' the gfortran compiler using -Wl,--stack,RESERVE or -Wl,--stack,RESERVE,COMMIT (may not work; there's a problem with both ld and gcc using ',' as a delimiter) Wouldn't that be an option for peflags? It's just some info in the file header... Oh, sure, peflags COULD be extended to twiddle any of the PE header values, although I'm not sure that's something you'd want to do to every .exe on your system (i.e. not peflagsall). PTC... Will do :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: {octave,octave-devel,octave-doc}-3.4.2-1
New versions 3.4.2-1 of octave, octave-devel, octave-doc are available in the Cygwin distribution: CHANGES This is a upstream bug fix release of 3.4.x For all the main changes http://www.gnu.org/software/octave/NEWS-3.4.html DESCRIPTION The GNU Octave language for numerical computations Octave is a (mostly Matlab (R) compatible) high-level language, primarily intended for numerical computations. It provides a convenient command-line interface for solving linear and nonlinear problems numerically. HOMEPAGE http://www.gnu.org/software/octave/ KNOWN BUGS 1) on cygwin-1.7.9 the plotting function is working very bad. This is due to a cygwin bug and is not a octave bug. Any cygwin snapshots after 2011-06-01 solve the issues, so the next cygwin-1.7.10 will definetly remove the bug. 2) Only on cygwin version printing plots from fltk cause segfault. Never succeeded, for lack of time and competence, to identify the root cause : octave, fltk, cygwin ? To reproduce: run octave and at prompt - graphics_toolkit (fltk) x=1:10; plot(x,x) print(fltk.png,-dpng) - the plot is built and printed as file but octave crashes. Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: octave-forge-20110730-1
New version of octave-forge-20110730-1 for cygwin is available in the Cygwin distribution: This release is the bundle of upstream version for octave 3.4.x series Upstream decided to split all the package as standalone, but I prefer to maintain the previous bundle structure. I can not manage the workload of 55 to 80 small packages. CHANGES Packaged available up to 30-Jul-2011, in sync with octave-3.4.2-1. DESCRIPTION The octave-forge project contains contributed functions for GNU Octave which are not in the main distribution. HOMEPAGE http://octave.sourceforge.net Full documentation and FAQ are available at: http://octave.sourceforge.net/docs.html Original source of individual packages http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/ Regards Marco Atzeri *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mc-4.7.5.3-1
29.07.2011 14:22, Marco atzeri пишет: Version 4.7.5.3-1 of Midnight Commander has been uploaded for cygwin CHANGES This is an new upstream release. Nice! CYGWIN CHANGES The closure of the subshell is now handled. Very good!! There are many frustration from user because previous Cygwin package version can not kill background shell (which accessed by C-o). But I have issue. 'setup.ini' does not contain entry for new version. So can not be installed through setup.exe. Then I change 'setup.ini' to: version: 4.7.5.3-1 install: release/mc/mc-4.7.5.3-1.tar.bz2 1581910 249bd9605be1bbcc8306ee3ab11b208e [prev] version: 4.6.1-2 install: release/mc/mc-4.6.1-2.tar.bz2 496091 319bd9a93a1649c63a6094adec4da616 source: release/mc/mc-4.6.1-2-src.tar.bz2 3954074 a63c4c686d07f2fa28e92a14fbe22edc setup.exe purpose upgrade to new version. Please fix to allow user access to new version. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mc-4.7.5.3-1
On 8/5/2011 9:34 AM, Oleksandr Gavenko wrote: 29.07.2011 14:22, Marco atzeri пишет: Version 4.7.5.3-1 of Midnight Commander has been uploaded for cygwin CHANGES This is an new upstream release. Nice! CYGWIN CHANGES The closure of the subshell is now handled. Very good!! There are many frustration from user because previous Cygwin package version can not kill background shell (which accessed by C-o). But I have issue. 'setup.ini' does not contain entry for new version. So can not be installed through setup.exe. Then I change 'setup.ini' to: version: 4.7.5.3-1 install: release/mc/mc-4.7.5.3-1.tar.bz2 1581910 249bd9605be1bbcc8306ee3ab11b208e [prev] version: 4.6.1-2 install: release/mc/mc-4.6.1-2.tar.bz2 496091 319bd9a93a1649c63a6094adec4da616 source: release/mc/mc-4.6.1-2-src.tar.bz2 3954074 a63c4c686d07f2fa28e92a14fbe22edc setup.exe purpose upgrade to new version. Please fix to allow user access to new version. you have likely a proxy/cache problem. The setup.ini reports 4.7.5.3-1 as current version Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mc-4.7.5.3-1
05.08.2011 10:41, Marco atzeri пишет: On 8/5/2011 9:34 AM, Oleksandr Gavenko wrote: But I have issue. 'setup.ini' does not contain entry for new version. So can not be installed through setup.exe. Then I change 'setup.ini' to: version: 4.7.5.3-1 install: release/mc/mc-4.7.5.3-1.tar.bz2 1581910 249bd9605be1bbcc8306ee3ab11b208e [prev] version: 4.6.1-2 install: release/mc/mc-4.6.1-2.tar.bz2 496091 319bd9a93a1649c63a6094adec4da616 source: release/mc/mc-4.6.1-2-src.tar.bz2 3954074 a63c4c686d07f2fa28e92a14fbe22edc setup.exe purpose upgrade to new version. you have likely a proxy/cache problem. The setup.ini reports 4.7.5.3-1 as current version I use rsync://mirrors.kernel.org/mirrors/sourceware setup.bz2 have updated contend. But setup.ini outdated! If I run setup.exe on local copy of repo setup uses setup.ini. I rsync with --delete. Why mirrors provide outdated files? Or I am something missing? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mc-4.7.5.3-1
On 8/5/2011 10:53 AM, Oleksandr Gavenko wrote: 05.08.2011 10:41, Marco atzeri пишет: On 8/5/2011 9:34 AM, Oleksandr Gavenko wrote: But I have issue. 'setup.ini' does not contain entry for new version. So can not be installed through setup.exe. Then I change 'setup.ini' to: version: 4.7.5.3-1 install: release/mc/mc-4.7.5.3-1.tar.bz2 1581910 249bd9605be1bbcc8306ee3ab11b208e [prev] version: 4.6.1-2 install: release/mc/mc-4.6.1-2.tar.bz2 496091 319bd9a93a1649c63a6094adec4da616 source: release/mc/mc-4.6.1-2-src.tar.bz2 3954074 a63c4c686d07f2fa28e92a14fbe22edc setup.exe purpose upgrade to new version. you have likely a proxy/cache problem. The setup.ini reports 4.7.5.3-1 as current version I use rsync://mirrors.kernel.org/mirrors/sourceware setup.bz2 have updated contend. But setup.ini outdated! If I run setup.exe on local copy of repo setup uses setup.ini. I rsync with --delete. Why mirrors provide outdated files? Or I am something missing? http://mirrors.kernel.org/sourceware/cygwin/setup.ini looks fine have you catched the mirror during the sync with the primary ? Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mc-4.7.5.3-1
05.08.2011 12:13, Marco atzeri пишет: On 8/5/2011 10:53 AM, Oleksandr Gavenko wrote: Or I am something missing? http://mirrors.kernel.org/sourceware/cygwin/setup.ini looks fine have you catched the mirror during the sync with the primary ? Finally I found error from myself. I fix in: mirror=rsync://mirrors.kernel.org/mirrors/sourceware rsync -va --delete --no-g --no-o --no-p \ --exclude='*-src.tar.bz2' \ --include='/release/***' --include='/setup.bz2*' \ --exclude='*' \ $mirror/cygwin/ $destdir/cygwin/ 21 | tee -a $log pattern to setup: --include='/release/***' --include='/setup.*' \ I am not expert of rsync but --delete preserve setup.ini if my first script. Why? Thanks for pointing and sorry for noise in this list. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: binutils-2.21.53-1
Hello, On Sun, Jul 31, 2011 at 02:22:51PM -0400, Christopher Faylor wrote: I've made a new version of binutils available for installation. This is a refresh against the current CVS. Compared to the previous one (binutils-2.20.51-2), the /usr/include/bfd.h (and fellows) is missing. I need bfd.h in order to compile cygwin-snapshot-20110803-1/winsup/utils/dumper.cc Where can i find it, if not in binutils? Thank for your support, Denis Excoffier. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
gdb-7.3.50-1 can't read debug info for gcc-4.5.0-1 (exp)?
Hi all, It seems that the latest release of gdb doesn't quite get debug info right when reading apps compiled with the experimental gcc-4.5 package. It's a lot closer than the old gdb was able to get, but reported line numbers are usually off by 3-5 lines and breakpoints are similarly affected. Is there some obvious reason I shouldn't expect this to work, and have other people seen similar problems? If the answers are no and no I'll start trying to isolate a small test case, and meanwhile I'm building a gdb from scratch which I'll report back on. Thanks! Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC version 4.3 on Cygwin ?
On 01/08/2011 10:31 PM, Jan Chludzinski wrote: Because our gcc maintainer went missing. We hope Dave is ok, as we have had no word from him. However, in the meantime, we've had another person (Yaakov) volunteer to pick up the slack; the recent release of an updated GMP package were requested by the new volunteer to facilitate the upcoming release of gcc-$newer. Be patient. I'm thankful that Cygwin exists and is the great product it is! BUT, I just have an issue with GCC 4.3. I compiled some terse numerical (~1500 lines worth) and got one set of answers (using g++) and I got another set of answers using MinGW with 4.5. The MinGW results were what I expect - the same as I got using SuSE 11.4 with g++ 4.6. Also, the values I get using VC++ 2010. Haven't had time to wade through the ~1500 lines of Runge-Kutta code to find the needle-in-the-haystack. FYI, I also encountered a gcc-4.3 miscompilation yesterday (an assertion not firing even though gdb's view of the world said it should have both before and after the fact). Fortunately, the experimental 4.5 gcc package seems to fix it. Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb-7.3.50-1 can't read debug info for gcc-4.5.0-1 (exp)?
On 05/08/2011 7:58 AM, Ryan Johnson wrote: It seems that the latest release of gdb doesn't quite get debug info right when reading apps compiled with the experimental gcc-4.5 package. It's a lot closer than the old gdb was able to get, but reported line numbers are usually off by 3-5 lines and breakpoints are similarly affected. Is there some obvious reason I shouldn't expect this to work, and have other people seen similar problems? If the answers are no and no I'll start trying to isolate a small test case, and meanwhile I'm building a gdb from scratch which I'll report back on. Huh. Seems to have been a fluke... now that I've built a gdb-7.3 from scratch, both it and the cygwin version work equally flawlessly. The only things that have changed are that I rebased my system because the gdb build was spawning fork failures left and right, and I recompiled the binary (maybe with different flags? the flags I used before were in an emacs session which I had to close to rebase). I don't know why the former would affect anything, and I'll remain skeptical of the latter unless I stumble across another magic combo of bad compiler flags (I wasn't doing anything crazy or unusual in that area). Sorry for cluttering up the list with this. Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
20110803 snapshot fixes XEmacs subprocess problem
Attempting to run subprocesses from Cygwin-compiled xemacs under 1.7.9-1 on Win 7 64-bit was failing with Process sh background write attempted from control tty (SIGTTOU) Full details at [1]. This has been fixed by the most recent (20110803) snapshot. Not sure which snap actually introduced the fix, but thanks! ht [1] http://tracker.xemacs.org/XEmacs/its/issue768 -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Portable shell code between Cygwin and Linux
Greetings, Sebastien Vauban! Must be alias vpnup='exec sudo openvpn --config $HOME/config/client.vpn --writepid /tmp/openvpn.pid ' that's where his problem began, IMO. That's interesting. I thought this was completely equivalent (~ or $HOME), and preferred the shorter version. For bash, that's true. But for POSIX shell, or any other random shell - I doubt that much. Anyway, if you want to write portable script, use POSIX shell syntax. Yes, you'd lack some shortcuts, but the end result will be that your script is more likely to work on random system, than not. -- WBR, Andrey Repin (anrdae...@freemail.ru) 05.08.2011, 19:56 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mintty --log overwrites existing logfile in place
On 4 August 2011 10:57, Christian Franke wrote:
The mintty --log option is very useful but opens logfile without O_TRUNC
or O_APPEND:
D'oh!
mintty-1.0.1/child.c:
// Open log file if any
if (*cfg.log) {
log_fd = open(cfg.log, O_WRONLY | O_CREAT, 0600);
if (log_fd 0)
error(open log file);
}
Then it is sometimes difficult to determine where the new log output
ends :-)
I would suggest to add O_APPEND.
I'll ponder that. The original intention was O_TRUNC.
Thanks,
Andy
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
emacs and large-address awareness under recent snapshots
Starting with the 2011-07-21 snapshot, emacs doesn't work well with the large-address-awareness flag set (under 64-bit Win7). As soon as emacs is started, a *Warning* buffer is created with the following message: Emergency (alloc): Warning: past 95% of memory limit To reproduce, install emacs and do the following: $ peflags --bigaddr=1 /usr/bin/emacs-nox.exe $ emacs-nox.exe -Q Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: {octave,octave-devel,octave-doc}-3.4.2-1
New versions 3.4.2-1 of octave, octave-devel, octave-doc are available in the Cygwin distribution: CHANGES This is a upstream bug fix release of 3.4.x For all the main changes http://www.gnu.org/software/octave/NEWS-3.4.html DESCRIPTION The GNU Octave language for numerical computations Octave is a (mostly Matlab (R) compatible) high-level language, primarily intended for numerical computations. It provides a convenient command-line interface for solving linear and nonlinear problems numerically. HOMEPAGE http://www.gnu.org/software/octave/ KNOWN BUGS 1) on cygwin-1.7.9 the plotting function is working very bad. This is due to a cygwin bug and is not a octave bug. Any cygwin snapshots after 2011-06-01 solve the issues, so the next cygwin-1.7.10 will definetly remove the bug. 2) Only on cygwin version printing plots from fltk cause segfault. Never succeeded, for lack of time and competence, to identify the root cause : octave, fltk, cygwin ? To reproduce: run octave and at prompt - graphics_toolkit (fltk) x=1:10; plot(x,x) print(fltk.png,-dpng) - the plot is built and printed as file but octave crashes. Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@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.
