1-0.95
pedro@microboard:~$ /usr/bin/python3 Python 3.3.2+ (default, Feb 28 2014, 00:52:16) [GCC 4.8.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 1-0.95 0.050044 >>> How to get 0.05 as result? bc has scale=2 . Has Python some similar feature? -- https://mail.python.org/mailman/listinfo/python-list
Re: Lines on a tkinter.Canvas
- Original Message - > From: Gregory Ewing > To: python-list@python.org > Cc: > Sent: Thursday, June 12, 2014 8:38 AM > Subject: Re: Lines on a tkinter.Canvas > > Pedro Izecksohn wrote: >> The Canvas' method create_line turns on at least 2 pixels. But I want > to turn >> on many single pixels on a Canvas. > > You could try using a 1x1 rectangle instead. > > However, be aware that either of these will use quite a > lot of memory per pixel. If you are drawing a very large > number of pixels, this could cause performance problems. > In that case, you might want to use a different approach, > such as creating an image and telling the canvas to display > the image. Thank you Greg. Your second approach works and the script became: #!/usr/bin/python3 import tkinter as tk BITMAP = ''' #define im_width 1 #define im_height 1 static char im_bits[] = { 0xff }; ''' class Point (): def __init__ (self, x, y): self.x = x self.y = y class Board (tk.Frame): def __init__ (self, bg, dimensions): tk.Frame.__init__ (self, tk.Tk()) self.pack() self.canvas = tk.Canvas (self, bd = 0, bg = bg, width = dimensions.x, height = dimensions.y) self.canvas.pack (side = "top") self.objects_drawn = [] def drawLine (self, pa, pb, color): self.canvas.create_line (pa.x, pa.y, pb.x, pb.y, fill = color) def drawPoint (self, p, color): bitmap = tk.BitmapImage (data=BITMAP, foreground = color) self.objects_drawn.append (bitmap) self.canvas.create_image (p.x, p.y, image = bitmap) dimensions = Point (500, 500) board = Board ('black', dimensions) color = 'red' p = Point (0, 250) while (p.x < dimensions.x): board.drawPoint (p, color) p.x += 1 pa = Point (0, 350) pb = Point (499, 350) board.drawLine (pa, pb, color) board.mainloop() -- https://mail.python.org/mailman/listinfo/python-list
Re: Lines on a tkinter.Canvas
- Original Message - > From: Gregory Ewing > To: python-list@python.org > Sent: Thursday, June 12, 2014 8:38 AM > Subject: Re: Lines on a tkinter.Canvas > > Pedro Izecksohn wrote: >> The Canvas' method create_line turns on at least 2 pixels. But I want > to turn >> on many single pixels on a Canvas. > > You could try using a 1x1 rectangle instead. pedro@microboard:~/programming/python/tk/canvas$ diff old/testing.001.py testing.py 19c19 < self.canvas.create_line (p.x, p.y, p.x, p.y, fill = color) --- > self.canvas.create_rectangle (p.x, p.y, p.x, p.y, fill = color) The result that I got is: The line drawn by it is not shown. > However, be aware that either of these will use quite a > lot of memory per pixel. If you are drawing a very large > number of pixels, this could cause performance problems. > In that case, you might want to use a different approach, > such as creating an image and telling the canvas to display > the image. I did not try this yet. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lines on a tkinter.Canvas
As Peter Otten did not see the same result that I saw, I prepared an image that shows the result on my notebook: http://izecksohn.com/pedro/python/canvas/tk_window.xcf For those that might not know: xcf is the Gimp's file format. - Original Message - > From: Peter Otten > To: python-list@python.org > Sent: Thursday, June 12, 2014 4:02 AM > Subject: Re: Lines on a tkinter.Canvas > > Pedro Izecksohn wrote: > >> The code available from: >> http://izecksohn.com/pedro/python/canvas/testing.py >> draws 2 horizontal lines on a Canvas. Why the 2 lines differ on thickness >> and length? >> >> The Canvas' method create_line turns on at least 2 pixels. But I want > to >> turn on many single pixels on a Canvas. How should I do this? Canvas has >> no method create_pixel or create_point. > >> #!/usr/bin/python3 >> >> import tkinter as tk >> >> class Point (): >> def __init__ (self, x, y): >> self.x = x >> self.y = y >> >> class Board (tk.Frame): >> def __init__ (self, bg, dimensions): >> tk.Frame.__init__ (self, tk.Tk()) >> self.pack() >> self.canvas = tk.Canvas (self, bd = 0, bg = bg, width = dimensions.x, > height = dimensions.y) >> self.canvas.pack (side = "top") >> def drawLine (self, pa, pb, color): >> self.canvas.create_line (pa.x, pa.y, pb.x, pb.y, fill = color) >> def drawPoint (self, p, color): >> self.canvas.create_line (p.x, p.y, p.x, p.y, fill = color) >> >> dimensions = Point (500, 500) >> board = Board ('black', dimensions) >> color = 'red' >> p = Point (0, 250) >> while (p.x < dimensions.x): >> board.drawPoint (p, color) >> p.x += 1 >> pa = Point (0, 350) >> pb = Point (499, 350) >> board.drawLine (pa, pb, color) >> board.mainloop() > > I just tried your script, and over here the line drawn with > >> def drawLine (self, pa, pb, color): >> self.canvas.create_line (pa.x, pa.y, pb.x, pb.y, fill = color) > > has a width of 1 pixel and does not include the end point. Therefore the > "line" drawn with > >> def drawPoint (self, p, color): >> self.canvas.create_line (p.x, p.y, p.x, p.y, fill = color) > > does not show up at all. You could try to specify the line width explicitly: > > def drawPoint (self, p, color): > self.canvas.create_line (p.x, p.y, p.x+1, p.y, fill=color, width=1) > > If that doesn't work (or there's too much overhead) use pillow to > prepare an > image and show that. > > Another random idea: if you have a high resolution display your OS might > blow up everything. In that case there would be no fix on the application > level. > -- https://mail.python.org/mailman/listinfo/python-list
Lines on a tkinter.Canvas
The code available from: http://izecksohn.com/pedro/python/canvas/testing.py draws 2 horizontal lines on a Canvas. Why the 2 lines differ on thickness and length? The Canvas' method create_line turns on at least 2 pixels. But I want to turn on many single pixels on a Canvas. How should I do this? Canvas has no method create_pixel or create_point. -- https://mail.python.org/mailman/listinfo/python-list
Proposal of an API to deal with fingerprints on Python
Today I wrote the following API. It was not implemented on C yet. Do you have any comment? Could you help me to implement it? http://www.izecksohn.com/pedro/python/fingerprint/fingerprint.001.py -- https://mail.python.org/mailman/listinfo/python-list
pickle.dump (obj, conn)
Shouldn't pickle.dump (obj, conn) raise an Exception if conn is a TCP connection that was closed by the remote host? -- https://mail.python.org/mailman/listinfo/python-list
Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
ChangeLog entry: 2010-08-19 Pedro Izecksohn * endian.h [_BSD_SOURCE || ! _POSIX_SOURCE] (htobe16, htobe32) (htobe64, be16toh, be32toh, be64toh, htole16, htole32, htole64) (le16toh, le32toh, le64toh): Macros defined. I modified endian.h again: *** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010 --- /usr/include/endian.h Thu Aug 19 19:03:20 2010 *** *** 36,40 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif - #endif /*_ENDIAN_H_*/ --- 36,86 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif + #if defined _BSD_SOURCE || ! defined _POSIX_SOURCE + + #include + + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #define htobe16(x) bswap_16(x) + #define htobe32(x) bswap_32(x) + #define htobe64(x) bswap_64(x) + + #define be16toh(x) bswap_16(x) + #define be32toh(x) bswap_32(x) + #define be64toh(x) bswap_64(x) + + #define htole16(x) (x) + #define htole32(x) (x) + #define htole64(x) (x) + + #define le16toh(x) (x) + #define le32toh(x) (x) + #define le64toh(x) (x) + + #endif /*__BYTE_ORDER == __LITTLE_ENDIAN*/ + + #if __BYTE_ORDER == __BIG_ENDIAN + + #define htobe16(x) (x) + #define htobe32(x) (x) + #define htobe64(x) (x) + + #define be16toh(x) (x) + #define be32toh(x) (x) + #define be64toh(x) (x) + + #define htole16(x) bswap_16(x) + #define htole32(x) bswap_32(x) + #define htole64(x) bswap_64(x) + + #define le16toh(x) bswap_16(x) + #define le32toh(x) bswap_32(x) + #define le64toh(x) bswap_64(x) + + #endif /*__BYTE_ORDER == __BIG_ENDIAN*/ + + #endif /*_BSD_SOURCE*/ + + #endif /*_ENDIAN_H_*/ -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- Corinna Vinschen wrote: > > For this patch, given that it is just a bunch of rather obvious > defines, I don't think we have to treat the patch as significant. I do not think that these macros are obvious. I think that I was there when these macros were first implemented at 1987: I talked with the programmer who was paid by the Correios to port everything from the mainframe to the Apple II. I was a stenchy kid with his father, that asked the employee what he was doing. When I asked about other possibilities of endianness, the programmer answered about the PDP. The programmer explained about BSD being a flavor of Unix. That talk changed my life. > However, please don't use _BSD_SOURCE. The newlib/Cygwin headers are > not set up like the Linux headers and the big bunch of definitions from > /usr/include/features.h are not available so far. The _BSD_SOURCE > define is not honored or set anywhere right now. > > What you can do is to use _POSIX_SOURCE. So, if you're going to use > #ifndef _POSIX_SOURCE instead, and if you're creating a ChangeLog entry > in the correct ChangeLog entry format (see the ChangeLog file), then > I guess we can check it in. Would you agree with: #if defined _BSD_SOURCE || ! defined _POSIX_SOURCE ? -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
As this thread went nowhere, I searched for the BSD code: http://svn.freebsd.org/viewvc/base/stable/8/sys/sys/endian.h?revision=199583&view=markup It uses x to represent the variable as I did; but it also casts the variable. I think that casting is not desirable because I like to see warnings. -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- I wrote: >> The x glyph represents the different ways to represent the same number: >> ... >> I thought to use (i) of integer, but its glyph does not remember the >> proverb about Rome. --- Corinna Vinschen asked: > You mean "What have the Romans ever done for us?" "All roads lead to Rome." Answering the question asked by Eric Blake: Why do you need these macros? Binary endianness conversion is faster than ASCII conversion. -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
> Umm - did you copy straight from glibc's endian.h? That's a no-no; > cygwin generally doesn't want to borrow LGPL sources to avoid any > licensing questions (borrowing from BSD is okay, on the other hand). > You would have to implement things from scratch from a documentation > page, or copy from a less-questionable source, rather than using glibc's > implementation. > > I'm stopping right here, so I don't risk tainting myself. How about you > instead describe which macros you are missing, so someone can do a > clean-room implementation of those macros. After sleep I remembered the error that I posted first, that proves that I did not copy from glibc: + #ifdef _BSD_SOURCE + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #include If I would have copied from glibc this out-of-order code would be as it must be. And regarding the many (x) I can explain them: I could use any acceptable character, but I chose x for 2 reasons: 1) I, and probably most of you, learned equations at school using x and y, to draw the points along the axes; 2) The x glyph represents the different ways to represent the same number: As a child, I once asked an Unix sysadmin that used a real TTY: "-You are telling me that are two different ways to order the 4 bytes of a number. But I can imagine many more ways to represent the same number. For example: 1324 or 1423. ?" I thought to use (i) of integer, but its glyph does not remember the proverb about Rome. -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- Eric Blake wrote: > > Umm - did you copy straight from glibc's endian.h? That's a no-no; > cygwin generally doesn't want to borrow LGPL sources to avoid any > licensing questions (borrowing from BSD is okay, on the other hand). > You would have to implement things from scratch from a documentation > page, or copy from a less-questionable source, rather than using glibc's > implementation. > > I'm stopping right here, so I don't risk tainting myself. How about you > instead describe which macros you are missing, so someone can do a > clean-room implementation of those macros. I did not copy my code from glibc's endian.h: I wrote my code yesterday, while on Windows Vista for 32 bits using joe on Cygwin and notepad. Now I'm using Ubuntu for x86-64. I'm also surprised that glibc's code is similar to mine: glibc's folks wrote: #ifdef __USE_BSD /* Conversion interfaces. */ # include I wrote: #ifdef _BSD_SOURCE #include The man 3 page, from Linux and from the web, does not tell about __USE_BSD. The next line is equal, probably because the glibc's guy who wrote it also was using x86-32. If I would be using Ubuntu for x86-64 yesterday I would have written the opposite. #if __BYTE_ORDER == __LITTLE_ENDIAN If you want, to swap the order of my macros is very easy. Then glibc continues, interleaving be with le, and a pair of hto with another pair of toh: # define htobe16(x) __bswap_16 (x) # define htole16(x) (x) # define be16toh(x) __bswap_16 (x) # define le16toh(x) (x) It is very different from what I wrote. I interleaved the types: #define htobe16(x) bswap_16(x) #define htobe32(x) bswap_32(x) #define htobe64(x) bswap_64(x) To use bswap to implement hto and toh macros is the most intelligent approach. Fortunately, glibc's __bswap_16 differs from Cygwin's bswap_16. Also: glibc's style is different from mine: They use a space between the # and the define. After writing this message I'm proud that I'm as smart as the glibc's coder. I need the 64 bits macros only. I wrote the other macros for completeness. In my project, that can not be disclosed now, I use the arpa/inet.h macros for the smaller types. -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- I wrote: > Defines macros for to convert the endianness of 16, 32 and 64 bits > integer types. > > diff -c /usr/include/endian.orig.h /usr/include/endian.h My previous diff is wrong. The right one follows: *** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010 --- /usr/include/endian.h Thu Aug 12 21:28:01 2010 *** *** 36,40 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif - #endif /*_ENDIAN_H_*/ --- 36,83 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif + #ifdef _BSD_SOURCE + + #include + + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #define htobe16(x) bswap_16(x) + #define htobe32(x) bswap_32(x) + #define htobe64(x) bswap_64(x) + + #define be16toh(x) bswap_16(x) + #define be32toh(x) bswap_32(x) + #define be64toh(x) bswap_64(x) + + #define htole16(x) (x) + #define htole32(x) (x) + #define htole64(x) (x) + + #define le16toh(x) (x) + #define le32toh(x) (x) + #define le64toh(x) (x) + + #else /* __BYTE_ORDER == __BIG_ENDIAN */ + + #define htobe16(x) (x) + #define htobe32(x) (x) + #define htobe64(x) (x) + + #define be16toh(x) (x) + #define be32toh(x) (x) + #define be64toh(x) (x) + + #define htole16(x) bswap_16(x) + #define htole32(x) bswap_32(x) + #define htole64(x) bswap_64(x) + + #define le16toh(x) bswap_16(x) + #define le32toh(x) bswap_32(x) + #define le64toh(x) bswap_64(x) + + #endif + #endif /*_BSD_SOURCE*/ + + #endif /*_ENDIAN_H_*/ -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- Eric Blake wrote: > Christopher Faylor wrote: >> I wrote: >>> I hope this list accepts attachments. >> >> It does but the list mind-reading gizmo is on the fritz. > > Translation - a ChangeLog entry justifying your changes, a diff in > unified or context format (-u or -c) rather than the default ed format, > and attaching the patch inline with a text/plain MIME type instead of > base64 encoded, are all necessary before anyone is likely to act on your > proposed patch. Defines macros for to convert the endianness of 16, 32 and 64 bits integer types. diff -c /usr/include/endian.orig.h /usr/include/endian.h *** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010 --- /usr/include/endian.h Thu Aug 12 19:40:20 2010 *** *** 36,40 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif - #endif /*_ENDIAN_H_*/ --- 36,82 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif + #ifdef _BSD_SOURCE + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #include + + #define htobe16(x) bswap_16(x) + #define htobe32(x) bswap_32(x) + #define htobe64(x) bswap_64(x) + + #define be16toh(x) bswap_16(x) + #define be32toh(x) bswap_32(x) + #define be64toh(x) bswap_64(x) + + #define htole16(x) (x) + #define htole32(x) (x) + #define htole64(x) (x) + + #define le16toh(x) (x) + #define le32toh(x) (x) + #define le64toh(x) (x) + + #else /* __BYTE_ORDER == __BIG_ENDIAN */ + + #define htobe16(x) (x) + #define htobe32(x) (x) + #define htobe64(x) (x) + + #define be16toh(x) (x) + #define be32toh(x) (x) + #define be64toh(x) (x) + + #define htole16(x) bswap_16(x) + #define htole32(x) bswap_32(x) + #define htole64(x) bswap_64(x) + + #define le16toh(x) bswap_16(x) + #define le32toh(x) bswap_32(x) + #define le64toh(x) bswap_64(x) + + #endif + #endif /*_BSD_SOURCE*/ + + #endif /*_ENDIAN_H_*/ -- 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
diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
I hope this list accepts attachments. endian.h.diff Description: Binary data -- 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: FTW_PHYS
--- Larry Hall wrote: > > Type "mount" and hit return. Does that answer your question? > Just a little harmless redirection. $ mount C:/cygwin-1.7/bin on /usr/bin type ntfs (binary,auto) C:/cygwin-1.7/lib on /usr/lib type ntfs (binary,auto) C:/cygwin-1.7 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) --- Nellis, Kenneth wrote: > > But FTW_PHYS only inhibits symbolic links from being > followed. You have no symbolic links in those paths, > so FTW_PHYS is irrelevant to your problem. You two answered my question. Now I know that I need to check st_dev and st_ino . -- 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
FTW_PHYS
I wrote a small C++ application: http://www.izecksohn.com/pedro/c++/biggest/ that exhibits an unwanted behavior on Cygwin: ./biggest.exe -m -n -1 -d / > Cygwin\ files head Cygwin\ files 822 /lib/gcc/i686-pc-cygwin/4.3.4/cc1plus.exe 822 /usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1plus.exe 7667214 /lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe 7667214 /usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe 7527198 /lib/gcc/i686-pc-cygwin/4.3.4/libstdc++.a 7527198 /usr/lib/gcc/i686-pc-cygwin/4.3.4/libstdc++.a But biggest.c++ uses FTW_PHYS in flags to call nftw. So, why the duplicated entries shown above? P.S.: I know that I promised to contribute some code and I did not. My project took another way. -- 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: [users] Re: Ping Cor] Re: odt table bug?
--- NoOp wrote: > On 03/14/2010 08:58 AM, Cor Nouws wrote: >> Cor Nouws wrote (14-03-10 16:48) >>> NoOp wrote (13-03-10 03:34) >>>> Cor, can you test this with your 3.1x version? I'm sick (bad cold) and >>>> can't seem to locate my old 3.1x downloads at the moment. >>> >>> The document from 03/08/2010 12:25 PM, Pedro Izecksohn , TableVI-3.odt, >>> opens the same in OpenOffice.org 3.2.0 and 3.1.1 on Ubuntu 9.10. both >>> with the same table in it. >>> So I see no problems. >> >> So I had a quick look at the thread ;-) >> >> when saving the .odt as .doc and opening again: >> >> 3.1.1 (Sun build) preserves the table >> 3.2.0 (Sun build) has no table >> DEV300_m72 has no table >> (m74 is the last one, have not installed that) >> >> Also opening the .doc created in 3.1.1 in 3.2.0 and m72 has the table. >> So the problem is on saving as .doc. >> >> Best regards, >> Cor > > Thanks Cor for testing. > > Gary None of you uses a debug binary with all the assertions turned on? I uninstalled the go-oo and moved its RPMs to another partition and I'll go to Ubuntu repository to look for the debug version. - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
Re: [users] Re: odt table bug?
--- NoOp wrote: > Jean-Baptiste Faure wrote: >> >> I do not understand well if the table in the original text document has >> been copied from Calc or not. >> In fact there is already a bug report for tables copied from Calc to >> Writer. Please have a look at issue 108978 : >> http://www.openoffice.org/issues/show_bug.cgi?id=108978 >> > > That could be the issue & will have a closer look - thanks. I believe > the OP mentioned that the original table might have been created in > Excel. Unfortunately, Pedro has been messing with this doc for a long > time. I recall awhile back that I mentioned to him that it might have > been easier just to rewrite the entire thing. I rewrote this table for the public document. But to discard the buggy table would be to miss a chance to debug OOo. The FHS document is a permanent source of bugs, as the doctor uses 4 different computers and a cell phone to write it, plus this notebook where I convert it to the different formats and FTP. -- What makes you more sad than to not understand the universe? What makes you more happy than to find the source of a segmentation fault? - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
Re: [users] Re: odt table bug?
>> I wrote: >> >> Today the doctor told me that it is possible that he produced the >> table in Excel. --- NoOp wrote: > > Still looks to be a bug. I even tried a copy & paste to a new document > with the same results. > > As mentioned, OOo 3.1.1 Ubuntu/Novell/go-oo version preserves the table > (albeit with some formating errors), but OOo 3.2.0 (standard version) > does not. Were I you I'd file a bug report. > Also, try it with a go-oo version: > http://go-oo.org/ > and see if you get the same results. You can then use that information > to include in your bug report. Now I tried with Go-oo 3.2.0 build 9483 for x86_64.rpm on Ubuntu and the table was not preserved in the .doc . What should I write in the bug report? Could you report this bug for me? I'm tired. - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
Re: [users] odt table bug?
--- I wrote: > --- Franz Wein wrote: >> I don't believe that this is a table, that was produced with WRITER. > > The doctor that produced this table produces the statistics using > Calc, but the original document was imported from Microsoft Word some > years ago. This odt was produced by Writer, as I copied it from the > big file to a new file. If the file is bad, Writer should refuse it or > offer to fix it. Today the doctor told me that it is possible that he produced the table in Excel. - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
Re: [users] odt table bug?
--- Franz Wein wrote: > I don't believe that this is a table, that was produced with WRITER. The doctor that produced this table produces the statistics using Calc, but the original document was imported from Microsoft Word some years ago. This odt was produced by Writer, as I copied it from the big file to a new file. If the file is bad, Writer should refuse it or offer to fix it. - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
[users] odt table bug?
The file referenced below if saved as .doc (97/2000/XP) does not generate the table it contains: http://www.izecksohn.com/pedro/ooobug/TableVI-3.odt - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
Re: [users] scalc feature request
>> []calc does not understand any Date pasted as DDMMAA even though it is >> able to represent =TODAY() using this format. > > As so often, Paste Special is your friend. Instead of using ordinary Paste: > o Go to Edit | Paste Special... (or right-click | Paste Special... or > Ctrl+Shift+V). > o In the Paste Special dialogue, select "Unformatted text". > o In the Text Import dialogue, click in the relevant column to select it. > o For "Column type", select "Date (DMY)". > > I trust this helps. This would help if I would paste a column at once. But my specific case is that I need to paste date by date, that is cell by cell, as each date comes from a different html shown by some browser, which may be Firefox or IE. - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
[users] scalc feature request
scalc does not understand any Date pasted as DDMMAA even though it is able to represent =TODAY() using this format. Often I need to paste dates as Text and calculate days by head. - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
Re: SIGINT default behavior
I, Pedro Izecksohn wrote: > Robert Pendell wrote: >> >> I was unable to reproduce this bug on 1.7. Compiled using GCC 4.3.4 >> on 1.7.0-62. Gave exit code 130 every time. I used your test case to >> do the test. > > May be I did not express myself well: > > When ctrl c is pressed, it always give exit code 130. The > inconsistencies are ferror (stdin) and perror behaviors. What I understand as a bug is: fgets should not return after SIG_DFL caught SIGINT. -- 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: SIGINT default behavior
Robert Pendell wrote: > > I was unable to reproduce this bug on 1.7. Compiled using GCC 4.3.4 > on 1.7.0-62. Gave exit code 130 every time. I used your test case to > do the test. May be I did not express myself well: When ctrl c is pressed, it always give exit code 130. The inconsistencies are ferror (stdin) and perror behaviors. I'll not be on Cygwin before noon. -- 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: SIGINT default behavior
Larry Hall wrote: > I, Pedro Izecksohn, wrote: >> >> The default behavior is not always the same. I also got: >> ferror (stdin): >> and >> ferror (stdin): Interrupted system call >> and the expected behavior of just the exit code 130. >> > > Try Cygwin 1.7 <http://cygwin.com/#beta-test>. $ cat /proc/version CYGWIN_NT-6.0 1.7.0(0.214/5/3) 2009-10-03 14:33 The beta version gives the same inconsistent results. -- 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
SIGINT default behavior
r...@turion ~/programming/c/sigint $ cat test.c #include #include int main () { printf ("Press Control c\n"); char buffer [3]; char *fgets_returned = fgets (buffer, sizeof buffer, stdin); if (!fgets_returned) { if (ferror (stdin)) { perror ("ferror (stdin)"); return EXIT_FAILURE; } if (feof (stdin)) printf ("EOF\n"); return EXIT_SUCCESS; } printf ("You did not press Control c .\n"); return EXIT_SUCCESS; } r...@turion ~/programming/c/sigint $ gcc -Wall test.c -o test_cygwin.exe r...@turion ~/programming/c/sigint $ ./test_cygwin.exe Press Control c ferror (stdin) r...@turion ~/programming/c/sigint $ cat /proc/version CYGWIN_NT-6.0 1.5.25(0.156/4/2) 2008-06-12 19:34 The default behavior is not always the same. I also got: ferror (stdin): and ferror (stdin): Interrupted system call and the expected behavior of just the exit code 130. -- 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: bug in mbrtowc?
To initialize wchar_t wc=(wchar_t)0; may also help. On Tue, Jul 28, 2009 at 6:56 AM, Andy Koppe wrote: > 2009/7/28 Pedro Izecksohn: >> The bug is in O.P.'s code as &s is not being passed to mbrtowc. > > From http://www.opengroup.org/onlinepubs/009695399/functions/mbrtowc.html: > "If ps is a null pointer, the mbrtowc() function shall use its own > internal mbstate_t object, which shall be initialized at program > start-up to the initial conversion state." > > The test also fails when passing &s instead. (I'd accidentally left in > the local mb_state.) > > 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
Re: bug in mbrtowc?
The bug is in O.P.'s code as &s is not being passed to mbrtowc. I'm on Ubuntu. I do not have Cygwin here. I should consume some calories before trying to debug anything. On Tue, Jul 28, 2009 at 6:14 AM, Corinna Vinschen wrote: > On Jul 27 22:56, Andy Koppe wrote: >> I've encountered what looks like a bug in mbrtowc's handling of UTF-8. >> Here's an example: >> >> #include >> #include >> #include >> #include >> >> int main(void) { >> wchar_t wc; >> size_t ret; >> mbstate_t s = { 0 }; >> puts(setlocale(LC_CTYPE, "en_GB.UTF-8")); >> printf("%i\n", mbrtowc(&wc, "\xe2", 1, 0)); >> printf("%i\n", mbrtowc(&wc, "\x94", 1, 0)); >> printf("%i\n", mbrtowc(&wc, "\x84", 1, 0)); >> printf("%x\n", wc); >> return 0; >> } >> >> The sequence E2 94 84 should translate to U+2514. Instead, the second >> and third calls to mbrtowc report encoding errors. It does work >> correctly if the three bytes are passed to mbrtowc() in one go: >> >> printf("%i\n", mbrtowc(&wc, "\xe2\x94\x84", 3, 0)); > > That's a bug in the newlib function __utf8_mbtowc. I'm really surprised > that this bug has never been reported before since it's in the code for > years, probably since it has been introduced in 2002. > > I'll follow up on the newlib list. > > > Thanks for the report and especially thanks for the testcase, > Corinna -- 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: bug in mbrtowc?
From the "Linux Programmer’s Manual" (release 3.15 of the Linux man-pages): "If the n bytes starting at s do not contain a complete multibyte character, mbrtowc() returns (size_t) -2." On Mon, Jul 27, 2009 at 6:56 PM, Andy Koppe wrote: > I've encountered what looks like a bug in mbrtowc's handling of UTF-8. > Here's an example: > > #include > #include > #include > #include > > int main(void) { > wchar_t wc; > size_t ret; > mbstate_t s = { 0 }; > puts(setlocale(LC_CTYPE, "en_GB.UTF-8")); > printf("%i\n", mbrtowc(&wc, "\xe2", 1, 0)); > printf("%i\n", mbrtowc(&wc, "\x94", 1, 0)); > printf("%i\n", mbrtowc(&wc, "\x84", 1, 0)); > printf("%x\n", wc); > return 0; > } > > The sequence E2 94 84 should translate to U+2514. Instead, the second > and third calls to mbrtowc report encoding errors. It does work > correctly if the three bytes are passed to mbrtowc() in one go: > > printf("%i\n", mbrtowc(&wc, "\xe2\x94\x84", 3, 0)); > > 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
build/i686-pc-cygwin/winsup make check
Just to point out (as probably I'll solve it myself later): $ tail make_check_outerr make[1]: Entering directory `/opt/build/i686-pc-cygwin/winsup/cygwin' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/cygwin' make[1]: Entering directory `/opt/build/i686-pc-cygwin/winsup/testsuite' gcc -L/opt/build/i686-pc-cygwin/winsup -L/opt/build/i686-pc-cygwin/winsup/testsu ite -L/opt/build/i686-pc-cygwin/winsup/w32api/lib -isystem /opt/src/winsup/inclu de -isystem /opt/src/winsup/testsuite/include -isystem /opt/src/winsup/w32api/in clude -B/opt/build/i686-pc-cygwin/newlib/ -isystem /opt/build/i686-pc-cygwin/new lib/targ-include -isystem /opt/src/newlib/libc/include-I/usr/lib/gcc/i686-pc -cygwin/4.3.2/include -mno-cygwin -I/opt/src/winsup/w32api/include -o cygrun.o -c /opt/src/winsup/testsuite/cygrun.c gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler. make[1]: *** [cygrun.o] Error 1 make[1]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/testsuite' make: *** [check] Error 2 -- 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: Any solution to this build problem?
--- Jacob Jacobson wrote: > Perhaps this went unnoticed. Reposting it. I am still having > problems building cygwin dll. Has anyone seen this error? > >> > Getting close here. Apparently gets to the linking phase. Please help >> > with error below. >> > >> > [build$:618] (../src/configure --prefix=/c/home/wrk/cygwin/install -v; >> > make) >>> >>& make.out >> > [build$:619] tail make.out >> > >> > /c/home/wrk/cygwin/build/i686-pc-cygwin/winsup/cygwin/../../../../src/winsup/cygwin/lib/pseudo-reloc.c:33: >> > undefined reference to `___RUNTIME_PSEUDO_RELOC_LIST_END__' >> > collect2: ld returned 1 exit status >> > >> > make[3]: *** [cygwin0.dll] Error 1 >> > make[3]: Leaving directory >> > `/c/home/wrk/cygwin/build/i686-pc-cygwin/winsup/cygwin' >> > make[2]: *** [cygwin] Error 1 >> > make[2]: Leaving directory >> > `/c/home/wrk/cygwin/build/i686-pc-cygwin/winsup' >> > make[1]: *** [all-target-winsup] Error 2 >> > make[1]: Leaving directory `/c/home/wrk/cygwin/build' >> > make: *** [all] Error 2 >> > [build$:620] Try to remove the build directory to configure and make again from the beginning. -- 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: Cygwin Build Error
Jacob Jacobson wrote: > > Getting close here. Apparently gets to the linking phase. Please help > with error below. > > > [build$:618] (../src/configure --prefix=/c/home/wrk/cygwin/install -v; make) >>& make.out > [build$:619] tail make.out > /c/home/wrk/cygwin/build/i686-pc-cygwin/winsup/cygwin/../../../../src/winsup/cygwin/lib/pseudo-reloc.c:33: > undefined reference to `___RUNTIME_PSEUDO_RELOC_LIST_END__' > collect2: ld returned 1 exit status > > make[3]: *** [cygwin0.dll] Error 1 > make[3]: Leaving directory > `/c/home/wrk/cygwin/build/i686-pc-cygwin/winsup/cygwin' > make[2]: *** [cygwin] Error 1 > make[2]: Leaving directory `/c/home/wrk/cygwin/build/i686-pc-cygwin/winsup' > make[1]: *** [all-target-winsup] Error 2 > make[1]: Leaving directory `/c/home/wrk/cygwin/build' > make: *** [all] Error 2 > [build$:620] I did not have this problem. I had a problem similar, but different, to the one described at: http://www.cygwin.com/ml/cygwin/2008-07/msg00148.html -- 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: Cygwin Build Error
--- Christopher Faylor wrote: > Just remove the mingw directory. --- I, Pedro, posted: > $ tail make.out > /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup > -L/opt/build/ > i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib > -isys > tem /opt/src/winsup/include -isystem /opt/src/winsup/cygwin/include -isystem > /op > t/src/winsup/w32api/include -B/opt/build/i686-pc-cygwin/newlib/ -isystem > /opt/bu > ild/i686-pc-cygwin/newlib/targ-include -isystem /opt/src/newlib/libc/include > -I/opt/src/winsup -c -o ./bloda.o -g -O2 -fno-exceptions -fno-rtti > -DHAVE_DECL_G > ETOPT=0 -mno-cygwin -I/opt/src/winsup/w32api/include > /opt/src/winsup/utils/blod > a.cc > /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup > -L/opt/build/ > i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib > -isys > tem /opt/src/winsup/include -isystem /opt/src/winsup/cygwin/include -isystem > /op > t/src/winsup/w32api/include -B/opt/build/i686-pc-cygwin/newlib/ -isystem > /opt/bu > ild/i686-pc-cygwin/newlib/targ-include -isystem /opt/src/newlib/libc/include > -I/opt/src/winsup -c -o ./path.o -g -O2 -fno-exceptions -fno-rtti > -DHAVE_DECL_GE > TOPT=0 -mno-cygwin -I/opt/src/winsup/w32api/include > /opt/src/winsup/utils/path. > cc > /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup > -L/opt/build/ > i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib > -isys > tem /opt/src/winsup/include -isystem /opt/src/winsup/cygwin/include -isystem > /op > t/src/winsup/w32api/include -B/opt/build/i686-pc-cygwin/newlib/ -isystem > /opt/bu > ild/i686-pc-cygwin/newlib/targ-include -isystem /opt/src/newlib/libc/include > -I/opt/src/winsup -c -o ./dump_setup.o -g -O2 -fno-exceptions -fno-rtti > -DHAVE_D > ECL_GETOPT=0 -mno-cygwin -I/opt/src/winsup/w32api/include > /opt/src/winsup/utils > /dump_setup.cc > make[3]: *** No rule to make target > `/opt/build/i686-pc-cygwin/winsup/mingw/Make > file', needed by `/opt/build/i686-pc-cygwin/winsup/mingw/libmingw32.a'. Stop. > make[3]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/utils' > make[2]: *** [utils] Error 1 > make[2]: Leaving directory `/opt/build/i686-pc-cygwin/winsup' > make[1]: *** [all-target-winsup] Error 2 > make[1]: Leaving directory `/opt/build' > make: *** [all] Error 2 The solution: $ diff src/winsup/utils/Makefile.in~ src/winsup/utils/Makefile.in 108c108,109 < all: Makefile $(CYGWIN_BINS) $(MINGW_BINS) --- > #all: Makefile $(CYGWIN_BINS) $(MINGW_BINS) > all: Makefile $(CYGWIN_BINS) And the next problem: $ tail make.out xmlto html -o faq -m /opt/src/winsup/doc/cygwin.dsl /opt/src/winsup/doc/faq.xml Writing faq-nochunks.html for article(faq-nochunks) sed -i 's;;;g' faq/faq-nochunks.html xmlto --extension -v pdf -o cygwin-ug-net/ -m /opt/src/winsup/doc/cygwin.dsl cyg win-ug-net.sgml Format script: /usr/share/xmlto/format/docbook/pdf I don't know how to convert docbook into pdf. make[3]: [cygwin-ug-net/cygwin-ug-net.pdf] Error 1 (ignored) make[3]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/doc' make[2]: Leaving directory `/opt/build/i686-pc-cygwin/winsup' make[1]: Leaving directory `/opt/build' I need to log off now. -- 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: Cygwin Build Error
--- Christopher Faylor wrote: > Just remove the mingw directory. $ tail make.out /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup -L/opt/build/ i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib -isys tem /opt/src/winsup/include -isystem /opt/src/winsup/cygwin/include -isystem /op t/src/winsup/w32api/include -B/opt/build/i686-pc-cygwin/newlib/ -isystem /opt/bu ild/i686-pc-cygwin/newlib/targ-include -isystem /opt/src/newlib/libc/include -I/opt/src/winsup -c -o ./bloda.o -g -O2 -fno-exceptions -fno-rtti -DHAVE_DECL_G ETOPT=0 -mno-cygwin -I/opt/src/winsup/w32api/include /opt/src/winsup/utils/blod a.cc /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup -L/opt/build/ i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib -isys tem /opt/src/winsup/include -isystem /opt/src/winsup/cygwin/include -isystem /op t/src/winsup/w32api/include -B/opt/build/i686-pc-cygwin/newlib/ -isystem /opt/bu ild/i686-pc-cygwin/newlib/targ-include -isystem /opt/src/newlib/libc/include -I/opt/src/winsup -c -o ./path.o -g -O2 -fno-exceptions -fno-rtti -DHAVE_DECL_GE TOPT=0 -mno-cygwin -I/opt/src/winsup/w32api/include /opt/src/winsup/utils/path. cc /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup -L/opt/build/ i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib -isys tem /opt/src/winsup/include -isystem /opt/src/winsup/cygwin/include -isystem /op t/src/winsup/w32api/include -B/opt/build/i686-pc-cygwin/newlib/ -isystem /opt/bu ild/i686-pc-cygwin/newlib/targ-include -isystem /opt/src/newlib/libc/include -I/opt/src/winsup -c -o ./dump_setup.o -g -O2 -fno-exceptions -fno-rtti -DHAVE_D ECL_GETOPT=0 -mno-cygwin -I/opt/src/winsup/w32api/include /opt/src/winsup/utils /dump_setup.cc make[3]: *** No rule to make target `/opt/build/i686-pc-cygwin/winsup/mingw/Make file', needed by `/opt/build/i686-pc-cygwin/winsup/mingw/libmingw32.a'. Stop. make[3]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/utils' make[2]: *** [utils] Error 1 make[2]: Leaving directory `/opt/build/i686-pc-cygwin/winsup' make[1]: *** [all-target-winsup] Error 2 make[1]: Leaving directory `/opt/build' make: *** [all] Error 2 -- 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: "setrlimit(RLIMIT_CPU) isn't implemented in Cygwin.", Corinna Vinschen
I'm, slowly, implementing it. I plan to post the papers tomorrow, after my implementation work fine. -- 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: "setrlimit(RLIMIT_CPU) isn't implemented in Cygwin.", Corinna Vinschen
--- I asked: >>> Will it be implemented in Cygwin someday? --- Dave Korn replied: >> Otherwise, http://cygwin.com/acronyms#SHTDI and >> http://cygwin.com/acronyms#PTC apply here. I imagine it should be possible >> to >> use a windows job object to implement it. --- Corinna Vinschen replied: > There are no plans to implement it in the near future. Are contributors asked to sign any paper? If I contribute it, will my name appear in the .cc file? Must my e-mail appear with my name? -- 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
"setrlimit(RLIMIT_CPU) isn't implemented in Cygwin.", Corinna Vinschen
Will it be implemented in Cygwin someday? -- 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: 1.7.0 sem_open
--- I wrote: >>> For me, using the unpatched version, (not the CVS version), the >>> persistence works some times only. At other times the semaphore >>> disappears with the Control c. It is not reproducible. I'm sorry from wasting your time. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0 sem_open
>> The persistence of the semaphore also works for you? >> >> For me, using the unpatched version, (not the CVS version), the >> persistence works some times only. At other times the semaphore >> disappears with the Control c. > > The semaphore is backed by a file on disk. If you don't call > sem_unlink one way or the other, the semaphore persists. Nice to say, but why it is not always this way? I should create an example to run my code some times and always kill it until that the semaphore does not persist. It is a nice task for tonight. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0 sem_open
Corinna Vinschen read my mind. > What is semtool? semtool - A utility for tinkering with semaphores USAGE: semtool (c)reate (l)ock (u)nlock (d)elete (m)ode It comes in some package available through the Cygwin's installer. I do not understand how to use it. >> I wrote an example that works on Jaunty on x86-64 but not on Cygwin: >> http://www.izecksohn.com/pedro/c/semaphores/semaphores.tar.gz > > Works for me. The persistence of the semaphore also works for you? For me, using the unpatched version, (not the CVS version), the persistence works some times only. At other times the semaphore disappears with the Control c. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.7.0 sem_open
Does the function sem_open work for anyone using Cygwin 1.7.0 ? How to use semtool ? I wrote an example that works on Jaunty on x86-64 but not on Cygwin: http://www.izecksohn.com/pedro/c/semaphores/semaphores.tar.gz Also: gcc4 does not understand the option "-lrt" so it must be removed. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[Bug 9441] Re: the locate pointer option breaks other keybindings
But I'd like to use Ctrl+t to open gnome-terminal and 'Locate pointer' impedes it. -- the locate pointer option breaks other keybindings https://bugs.launchpad.net/bugs/9441 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a direct subscriber. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 9441] Re: the locate pointer option breaks other keybindings
But I'd like to use Ctrl+t to open gnome-terminal and 'Locate pointer' impedes it. -- the locate pointer option breaks other keybindings https://bugs.launchpad.net/bugs/9441 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 9441] Re: the locate pointer option breaks other keybindings
This bug seems fixed here, on Jaunty on amd64. -- the locate pointer option breaks other keybindings https://bugs.launchpad.net/bugs/9441 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 9441] Re: the locate pointer option breaks other keybindings
This bug seems fixed here, on Jaunty on amd64. -- the locate pointer option breaks other keybindings https://bugs.launchpad.net/bugs/9441 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a direct subscriber. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 322672] Re: To hold "Both Ctrl keys together" does not change the keyboard's layout
And what I wrote before: "This bug only occurs when the ctrl key is used to show the mouse." does not apply to Jaunty, as they seem unrelated. ** Summary changed: - "Both Ctrl keys together" do not change the keyboard's layout + To hold "Both Ctrl keys together" does not change the keyboard's layout -- To hold "Both Ctrl keys together" does not change the keyboard's layout https://bugs.launchpad.net/bugs/322672 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 322672] Re: To hold "Both Ctrl keys together" does not change the keyboard's layout
And what I wrote before: "This bug only occurs when the ctrl key is used to show the mouse." does not apply to Jaunty, as they seem unrelated. ** Summary changed: - "Both Ctrl keys together" do not change the keyboard's layout + To hold "Both Ctrl keys together" does not change the keyboard's layout -- To hold "Both Ctrl keys together" does not change the keyboard's layout https://bugs.launchpad.net/bugs/322672 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 322672] Re: "Both Ctrl keys together" do not change the keyboard's layout
You did not understand what I wanted to say. On Jaunty: To hold both control keys together does not lock Gnome any more, but it also does not change the keyboard's layout. If I'd be the main gnome-control-center developer I'd remove this option, since it does not work. This bug has 3 stages: 1) Causes some Gnome functions to stop working. 2) Does not interfere with other Gnome functions but does not work as expected. 3) Works fine. Jaunty advanced this bug from stage 1 to stage 2. ** Changed in: xorg (Ubuntu) Status: Fix Released => In Progress -- "Both Ctrl keys together" do not change the keyboard's layout https://bugs.launchpad.net/bugs/322672 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 322672] Re: "Both Ctrl keys together" do not change the keyboard's layout
You did not understand what I wanted to say. On Jaunty: To hold both control keys together does not lock Gnome any more, but it also does not change the keyboard's layout. If I'd be the main gnome-control-center developer I'd remove this option, since it does not work. This bug has 3 stages: 1) Causes some Gnome functions to stop working. 2) Does not interfere with other Gnome functions but does not work as expected. 3) Works fine. Jaunty advanced this bug from stage 1 to stage 2. ** Changed in: xorg (Ubuntu) Status: Fix Released => In Progress -- "Both Ctrl keys together" do not change the keyboard's layout https://bugs.launchpad.net/bugs/322672 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 275562] Re: Global shortcut keys of form [any single key] broken by "Show position of [mouse] pointer when the Control key is pressed".
It happens with: Package: gnome-control-center Architecture: amd64 Version: 1:2.26.0-0ubuntu3 -- Global shortcut keys of form [any single key] broken by "Show position of [mouse] pointer when the Control key is pressed". https://bugs.launchpad.net/bugs/275562 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 275562] Re: Global shortcut keys of form [any single key] broken by "Show position of [mouse] pointer when the Control key is pressed".
It happens with: Package: gnome-control-center Architecture: amd64 Version: 1:2.26.0-0ubuntu3 -- Global shortcut keys of form [any single key] broken by "Show position of [mouse] pointer when the Control key is pressed". https://bugs.launchpad.net/bugs/275562 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-control-center in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 275562] Re: Global shortcut keys of form [any single key] broken by "Show position of [mouse] pointer when the Control key is pressed".
** Changed in: gnome-control-center (Ubuntu) Status: New => Confirmed -- Global shortcut keys of form [any single key] broken by "Show position of [mouse] pointer when the Control key is pressed". https://bugs.launchpad.net/bugs/275562 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 275562] Re: Global shortcut keys of form [any single key] broken by "Show position of [mouse] pointer when the Control key is pressed".
** Changed in: gnome-control-center (Ubuntu) Status: New => Confirmed -- Global shortcut keys of form [any single key] broken by "Show position of [mouse] pointer when the Control key is pressed". https://bugs.launchpad.net/bugs/275562 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-control-center in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 322672] Re: "Both Ctrl keys together" do not change the keyboard's layout
** Summary changed: - gconf.xml keyboard freeze when both Ctrl keys used + "Both Ctrl keys together" do not change the keyboard's layout ** Description changed: - I'm talking about ~/.gconf/desktop/gnome/peripherals/mouse/%gconf.xml + Package: gnome-control-center + Architecture: amd64 + Version: 1:2.26.0-0ubuntu3 - The time that takes to lock the keyboard by pressing both control keys - together varies. - - First I thought this bug was connected to Layout switching, but then I - disabled that option to use both ctrl keys together to change layout. - Now I'm changing layout by the gnome-keyboard-applet. - - My keyboard is a (notebook) generic 101 keys. The layout chosen does not - interfere with this bug. - - Both ctrl keys work fine to show the mouse when pressed separately. + In gnome-keyboard-properties. ** Package changed: xorg-server (Ubuntu) => gnome-control-center (Ubuntu) ** Changed in: gnome-control-center (Ubuntu) Status: Invalid => New -- "Both Ctrl keys together" do not change the keyboard's layout https://bugs.launchpad.net/bugs/322672 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 322672] Re: "Both Ctrl keys together" do not change the keyboard's layout
** Summary changed: - gconf.xml keyboard freeze when both Ctrl keys used + "Both Ctrl keys together" do not change the keyboard's layout ** Description changed: - I'm talking about ~/.gconf/desktop/gnome/peripherals/mouse/%gconf.xml + Package: gnome-control-center + Architecture: amd64 + Version: 1:2.26.0-0ubuntu3 - The time that takes to lock the keyboard by pressing both control keys - together varies. - - First I thought this bug was connected to Layout switching, but then I - disabled that option to use both ctrl keys together to change layout. - Now I'm changing layout by the gnome-keyboard-applet. - - My keyboard is a (notebook) generic 101 keys. The layout chosen does not - interfere with this bug. - - Both ctrl keys work fine to show the mouse when pressed separately. + In gnome-keyboard-properties. ** Package changed: xorg-server (Ubuntu) => gnome-control-center (Ubuntu) ** Changed in: gnome-control-center (Ubuntu) Status: Invalid => New -- "Both Ctrl keys together" do not change the keyboard's layout https://bugs.launchpad.net/bugs/322672 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-control-center in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 322672] Re: gconf.xml keyboard freeze when both Ctrl keys used
I just upgraded to gnome-control-center version 1:2.26.0-0ubuntu3 for amd64. It seems that gnome-keyboard-properties "Both Ctrl keys together" to change layout is not working, but the other options (left and or right control key) are working fine. Could someone confirm this and post a new bug? -- gconf.xml keyboard freeze when both Ctrl keys used https://bugs.launchpad.net/bugs/322672 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[c-prog] Re: system's protection against buffer overflow
> I found that static data is executable on some platform. I was wrong. There is no reason for a constant string not be executable. It were not testing a writable static piece of memory.
[c-prog] system's protection against buffer overflow
Source code in: http://www.izecksohn.com/pedro/c/bo/bo.tar.gz Should static data be executable? I found that static data is executable on some platform.
Re: [users] Save as .doc (97/2000/XP) with OOO300m15
Mike Dawe wrote: > Also one or some of the embedded .wmf graphics are damaged. See page 82, > "Scheme IX-1: Healthy eye without Migraines". In your (unmodified) file > this graphic is not present. In the (Word 95) converted document, there > is a place holder with dimensions of the missing graphic at this point. > It is just not visible in your file until it is converted. > > Looking at your unmodified file under a plain text editor, I suspect > (but could be wrong) that the above page 82 graphic is > corrupted at that point. I may see this graphic on OOO310_m4_LinuxX86-64. It is not corrupted. Also the table's bug that Brian Barker pointed is not present on this version. - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
Re: [users] Re: Save as .doc (97/2000/XP) with OOO300m15
I'll try to isolate the bug before filing it. The document I showed is not a bug, it is a monster. - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
Re: [users] Re: Save as .doc (97/2000/XP) with OOO300m15
Jean-Baptiste Faure wrote: > You are probably right : cws hb19 which contains the fix for #98465 is > integrated in OOO310m4. Could some of you provide a link for an executable (.exe or .deb) newer version where this bug is fixed? - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
Re: [users] Save as .doc (97/2000/XP) with OOO300m15
Brian Barker wrote: > The Microsoft Word Viewer complains about the structure of a table, so the > .doc file is already faulty, it seems, before any attempt to reopen it in > OpenOffice. The problem appears to be in Table VI-3. If I delete this or > even keep the table but delete its contents- or even some of it - it will > save as .doc and reopen OK (in my m15 under Windows XP). I'll leave you to > discover what is irregular about the structure or content of this table. Brian Barker found the exact place of the problem. Without this table OpenOffice expended much time to open the .doc, but it finally succeeded, (at least on Vista). - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
[users] Save as .doc (97/2000/XP) with OOO300m15
Could you save http://www.izecksohn.com/pedro/fhs60s12.odt as .doc (97/2000/XP) with OOO300m15, close it and open it again? I tried it on Windows and on Linux (Ubuntu, but heavily modified): When opening the generated .doc with OpenOffice the execution enters in an infinite loop. The corrupted files may be downloaded from: http://www.izecksohn.com/pedro/fhs60s12.windows.doc http://www.izecksohn.com/pedro/fhs60s12.linux.doc - To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
Re: No package 'xcb-xlib' found
On 2/24/09, Simon Thum wrote: > Pedro Izecksohn wrote: >> Where it may be found? > Nowhere, AFAIK. > You may want to know this: http://bugs.gentoo.org/show_bug.cgi?id=158476 Let see if I understood it right: I'm trying to configure libX11-1.1.5 , so I can not use libxcb-1.2 ? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
No package 'xcb-xlib' found
Where it may be found? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libX11-6.2.1 and pkg-config 0.23
It came from http://xlibs.freedesktop.org/release/ BTW: What is the logic behind xlibs version numbers? On 2/19/09, Dan Nicholson wrote: > On Thu, Feb 19, 2009 at 10:45 AM, Pedro Izecksohn > wrote: >> Who will fix it up there? Who has git write permission? >> >> How none saw this before me? The original developers did not try >> configure? > > Oh, I just looked in git and it's already been fixed for a while. It > should be in libX11-1.1.5. Where did libX11-6.2.1 come from? > > -- > Dan > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libX11-6.2.1 and pkg-config 0.23
Who will fix it up there? Who has git write permission? How none saw this before me? The original developers did not try configure? This bugs affects thousands advanced users. On 2/19/09, Dan Nicholson wrote: > On Thu, Feb 19, 2009 at 12:21 AM, Pedro Izecksohn > wrote: >> In libX11-6.2.1: >> >> The configure piece below is wrong, (or pkg-config is buggy) because >> >> pkg-config --cflags xproto >> >> prints a line-feed only and keysymdef.h exists in my system and it is in >> the right place. >> >> I'm using pkg-config --version 0.23 >> >> # >> # Find keysymdef.h >> # >> KEYSYMDEF="" >> for flag in $XPROTO_CFLAGS; do >>echo checking arg "$flag" >>case "$KEYSYMDEF" in >>"") >>case "$flag" in >>-I*) >>dir="`echo "$flag" | sed 's/^-I//'`" >>file="$dir/X11/keysymdef.h" >>echo looking for "$file" >>if test -f "$file"; then >>KEYSYMDEF="$file" >>fi >>;; >>esac >>;; >>esac >> done >> case "$KEYSYMDEF" in >> "") >>{ { echo "$as_me:$LINENO: error: \"Cannot find keysymdef.h\"" >&5 >> echo "$as_me: error: \"Cannot find keysymdef.h\"" >&2;} >> { (exit 1); exit 1; }; } >>;; >> esac > > Yeah, this seems wrong. What it should do is: > > includex11dir=`$PKG_CONFIG --variable=includex11dir xproto` > KEYSYMDEF="$includex11dir/keysymdef.h" > test -f "$KEYSYMDEF" || AC_MSG_ERROR([Cannot find keysymdef.h in > $includex11dir]) > > Or something like that. > > -- > Dan > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
libX11-6.2.1 and pkg-config 0.23
In libX11-6.2.1: The configure piece below is wrong, (or pkg-config is buggy) because pkg-config --cflags xproto prints a line-feed only and keysymdef.h exists in my system and it is in the right place. I'm using pkg-config --version 0.23 # # Find keysymdef.h # KEYSYMDEF="" for flag in $XPROTO_CFLAGS; do echo checking arg "$flag" case "$KEYSYMDEF" in "") case "$flag" in -I*) dir="`echo "$flag" | sed 's/^-I//'`" file="$dir/X11/keysymdef.h" echo looking for "$file" if test -f "$file"; then KEYSYMDEF="$file" fi ;; esac ;; esac done case "$KEYSYMDEF" in "") { { echo "$as_me:$LINENO: error: \"Cannot find keysymdef.h\"" >&5 echo "$as_me: error: \"Cannot find keysymdef.h\"" >&2;} { (exit 1); exit 1; }; } ;; esac The following is /usr/lib/pkgconfig/xproto.pc prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include includex11dir=${prefix}/include/X11 Name: Xproto Description: Xproto headers Version: 7.0.13 Cflags: -I${includedir} ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[Bug 322672] Re: gconf.xml keyboard freeze when both Ctrl keys used
This bug only occurs when the ctrl key is used to show the mouse. -- gconf.xml keyboard freeze when both Ctrl keys used https://bugs.launchpad.net/bugs/322672 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: I'm a newcomer to Fedora 10 Live CD
Let me add some details and suggest something: X -configure created xorg.conf.new with: Driver "nouveau" VendorName "nVidia Corporation" BoardName "GeForce 7150M" The board name is wrong, but it works fine. Some init script could execute X -configure before trying to start X. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: I'm a newcomer to Fedora 10 Live CD
--- Jim Cornette wrote: > > Issuing xdriver=vesa as a kernel parameter on boot should allow the vesa > driver to be loaded when you boot. Though I am not toying around with the > Live CD, the X server should work the same as traditional installs. cat /proc/cmdline initrd=initrd0.img root=CDLABEL=F10-x86_64-Live rootfstype=iso9660 ro liveimg xdriver=vesa BOOT_IMAGE=vmlinuz0 It did not work. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: I'm a newcomer to Fedora 10 Live CD
> I'm not familiar with running the live CD So you should not answer. > You may need to run with the vesa driver. A proper xorg.conf was missing. I needed to create one with: X -configure Then I used it with: X -config /root/xorg.conf.new export DISPLAY=:0.0 gnome-session and now I'm root inside Firefox. Could someone fix the appropriate script? -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
I'm a newcomer to Fedora 10 Live CD
startx prints to stderr and exits: xauth: creating new authority file /root/.serverauth.4241 X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.18-92.1.10.el5 x86_64 Current Operating System: Linux localhost.localdomain 2.6.27.5-117.fc10.x86_64 #1 SMP Tue Nov 18 11:58:53 EST 2008 x86_64 Build Date: 16 November 2008 08:28:40PM Build ID: xorg-x11-server 1.5.3-5.fc10 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Dec 24 22:49:24 2008 (EE) Unable to locate/open config file New driver is "nv" (==) Using default built-in configuration (30 lines) (EE) open /dev/fb0: No such file or directory (EE) No devices detected. Fatal server error: no screens found giving up. xinit: No such file or directory (errno 2): unable to connect to X server xinit: No such process (errno 3): Server error. This computer is a HP Pavilion dv2000. The video board is NVIDIA MCP67M. The screen resolution is 1280x800. It is a generic PnP Monitor. I'm not too worried, as I downloaded the CD to install on another different computer. I was just trying to preview it. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: [c-prog] How OOP affect performance
--- Jos Timanta Tarigan asked: > i want those vertices become objects in triangles. Interesting new concept :) > here is my question: is calling vertices[i].move() will take less time than > calling triangle[i].vertices[k].move() ? well i know it will but is it that > significant? I never saw any conscious vertex that know how it should move ;) Every indirection takes time. How much time is that significant? How much time each indirection take? It depends on if the content of triangle[i] is cached or not. Are you paulista?
Re: [c-prog] Re: Exception handling
--- kocmotex wrote: > ... the inability of academia to shift gears. After all, if > some of the other free C compilers were taught, such as Pelles C, > lcc-win32, Dev-C, etc, the academia might have to re-write some of > their arcane quiries, such as triple pre-or-postfix notation, viz. > +++y, c---, et al. > svegda, Could you expand about this topic? I wrote a small application to illustrate this topic, but I have no idea on how Turbo C would compile it: #include #include int main (int argc, char **argv) { if (argc<3) { fprintf (stderr, "Usage: problem number number\nWhere number is a decimal integer.\n"); return EXIT_FAILURE; } int a = atoi (argv[1]); printf ("The first argument was %d.\n", a); int b = atoi (argv[2]); int c = a---b; printf ("%d = %d---%d\n", c, a, b); c = a+++b; printf ("%d = %d+++%d\n", c, a, b); return 0; } I must go to sleep now.
Re: [c-prog] How OOP affect performance
--- Jos Timanta Tarigan asked: > > im currently trying to convert a code from functional to OOP. but the program > is > performance sensitive kind of program. is it that significant to change from > functional to OOP? how it will affect the programs performance(time and > memory)? > is it that much different from calling a function compared to a function from > another object? Does functional here means procedural? The answer to this question is language dependent: Are you planning to do OOP using plain C? Or do you plan to use C++ or Java? Write a little performance tester and measure it yourself.
Res: [c-prog] Re: integer promotions
--- peternilsson42 wrote: >>> Maybe you need -Wsign-conversion >> >> gcc -Wall -Wsign-conversion problem.c -o problem >> cc1: error: unrecognized command line option "-Wsign-conversion" > > Time you updated then... > > % gcc --version > gcc.exe (GCC) 4.3.2 Thank you.
Re: Res: [c-prog] Re: integer promotions
--- Thomas Hruska wrote: > Try compiling your code as C++ and see if there > is a difference. C++ compilers tend to generate a lot more warnings as > the language is, generally-speaking, more strict. [EMAIL PROTECTED] ~/programming/c++/problem $ ls -la total 10 drwxr-xr-x+ 2 root None 4096 Nov 27 22:47 . drwxr-xr-x+ 11 root None 4096 Nov 27 22:35 .. -rw-r--r-- 1 root None 69 Nov 27 22:37 Makefile -rw-r--r-- 1 root None 261 Nov 27 22:46 problem.cpp [EMAIL PROTECTED] ~/programming/c++/problem $ cat problem.cpp #include #include using namespace std; int main (void) { unsigned short int a; unsigned long long int b, c; a = USHRT_MAX; b = (a*a); c = ((unsigned int)a*(unsigned int)a); cout << "Why " << hex << b << " != " << c << " ?\n"; return 0; } [EMAIL PROTECTED] ~/programming/c++/problem $ cat Makefile problem : problem.cpp g++ -Wall -Wconversion problem.cpp -o problem [EMAIL PROTECTED] ~/programming/c++/problem $ make g++ -Wall -Wconversion problem.cpp -o problem [EMAIL PROTECTED] ~/programming/c++/problem $ ./problem.exe Why fffe0001 != fffe0001 ?
Re: Res: [c-prog] Re: integer promotions
--- peternilsson42 wrote: > "-Wconversion Warn for implicit conversions that may alter >a value. ... " > > Integral promotions don't alter the value. > > Maybe you need -Wsign-conversion gcc -Wall -Wsign-conversion problem.c -o problem cc1: error: unrecognized command line option "-Wsign-conversion"
Re: Res: [c-prog] Re: integer promotions
--- Thomas Hruska wrote: > There would also have been warnings on the next line of code with the > compiler complaining about a "signed to unsigned conversion" or > something like that. That would have been the more useful clue to the > OP that a "weird conversion" was happening behind the scenes. Yeah, gcc -Wconversion does not warn about it. Nice comment. May I report this to the gcc maintainers?
Res: Res: Res: [c-prog] Re: integer promotions
--- I wrote: > If I could do just one modification to the standard, I'd add an overflow > macro, like errno. --- peternilsson42 replied: > The behaviour on integer overflow is undefined. Hence, > implementations already have the freedom to do precisely > that if they so choose. [That they don't is indicitative!] And what the absence of this feature indicates? Regarding my original problem: I simplified the problem, compiled to assembly and modified the assembly to get my desired result. It would be very simple to implement the right math, that is, to consider the result of the multiplication of two integers as a long long int, as shown below: [EMAIL PROTECTED] ~/programming/c/problem/simple $ cat problem.c #include #include int main (void) { int a = USHRT_MAX; long long int b; b = (a*a); printf ("%d * %d = %lld ?\n", a, a, b); return 0; } [EMAIL PROTECTED] ~/programming/c/problem/simple $ cat Makefile all : problem.exe problem.s : problem.c gcc -Wall -Wconversion -O0 problem.c -S problem.exe : problem.s gcc -Wall problem.s -o problem.exe [EMAIL PROTECTED] ~/programming/c/problem/simple $ cat problem.s .file "problem.c" .def___main;.scl2; .type 32; .endef .section .rdata,"dr" LC0: .ascii "%d * %d = %lld ?\12\0" .text .globl _main .def_main; .scl2; .type 32; .endef _main: pushl %ebp movl%esp, %ebp subl$56, %esp andl$-16, %esp movl$0, %eax addl$15, %eax addl$15, %eax shrl$4, %eax sall$4, %eax movl%eax, -20(%ebp) movl-20(%ebp), %eax call__alloca call___main movl$65535, -4(%ebp) movl-4(%ebp), %eax imull -4(%ebp), %eax cltd movl%eax, -16(%ebp) movl%edx, -12(%ebp) movl-16(%ebp), %eax movl-12(%ebp), %edx movl%eax, 12(%esp) movl%edx, 16(%esp) movl-4(%ebp), %eax movl%eax, 8(%esp) movl-4(%ebp), %eax movl%eax, 4(%esp) movl$LC0, (%esp) call_printf movl$0, %eax leave ret .def_printf;.scl3; .type 32; .endef [EMAIL PROTECTED] ~/programming/c/problem/simple $ cat pedro.diff 23a24 > movl$0, %edx 26d26 < cltd [EMAIL PROTECTED] ~/programming/c/problem/simple $ cat pedro.s .file "problem.c" .def___main;.scl2; .type 32; .endef .section .rdata,"dr" LC0: .ascii "%d * %d = %lld ?\12\0" .text .globl _main .def_main; .scl2; .type 32; .endef _main: pushl %ebp movl%esp, %ebp subl$56, %esp andl$-16, %esp movl$0, %eax addl$15, %eax addl$15, %eax shrl$4, %eax sall$4, %eax movl%eax, -20(%ebp) movl-20(%ebp), %eax call__alloca call___main movl$65535, -4(%ebp) movl$0, %edx movl-4(%ebp), %eax imull -4(%ebp), %eax movl%eax, -16(%ebp) movl%edx, -12(%ebp) movl-16(%ebp), %eax movl-12(%ebp), %edx movl%eax, 12(%esp) movl%edx, 16(%esp) movl-4(%ebp), %eax movl%eax, 8(%esp) movl-4(%ebp), %eax movl%eax, 4(%esp) movl$LC0, (%esp) call_printf movl$0, %eax leave ret .def_printf;.scl3; .type 32; .endef [EMAIL PROTECTED] ~/programming/c/problem/simple $ ./problem.exe 65535 * 65535 = -131071 ? [EMAIL PROTECTED] ~/programming/c/problem/simple $ ./pedro.exe 65535 * 65535 = 4294836225 ?
Res: Res: [c-prog] Re: integer promotions
--- peternilsson42 wrote: > Ah, then you've probably been fooled by the cliché that > C is just portable assembler. If I could do just one modification to the standard, I'd add an overflow macro, like errno.
Res: Res: [c-prog] Re: integer promotions
--- I wrote: > It is mathematically obvious the Intel's approach. I thought it applied > wherever it is possible. Correction: I thought the mathematically obvious approach would be applied wherever possible.
Res: [c-prog] Re: integer promotions
--- peternilsson42 wrote: > So you made absolutely _no_ change to the semantics of > that assignment! I fixed the signal to make others happy. > You seem to be only interested in one class of machine. > why do you think that? Or, > do you think different values should be displayed? My previous reference was: "The three forms of the IMUL instruction are similar in that the length of the product is calculated to twice the length of the operands." (Intel 64 and IA-32 Architectures Software Developer's Manual, Instruction Set Reference A-M, Order Number 253666) Now I saw: "An example of undefined behavior is the behavior on integer overflow." (ISO/IEC 9899:1999 (E)) It is mathematically obvious the Intel's approach. I thought it applied wherever it is possible.
[c-prog] Re: integer promotions
For peternilsson42: I was not clear and you did not read message 68798. http://tech.groups.yahoo.com/group/c-prog/message/68798 To clarify: That code I compiled on two independent compilers. On both compilers: USHRT_MAX is 0x UINT_MAX is 0x ULLONG_MAX is 0x > For integers with a 'rank' less than int, if the range of > the integer type fits into the range of int, then that > type will promote to int, if it is promoted. If the > range won't fit into an int, it will be promoted to an > unsigned int. It shows that you read the standard. > Consider the test: (-1 < (unsigned short) 1) > > Whilst intuitively it should always be true, there are > many implementations where it is false! The unsigned short value 1 fits into an int and -1 is an int, so, according to the standard this test must be true. >>> a = -1; I changed this line in message 68798 to: a = USHRT_MAX; > Here's a table of what a will promote to, and the type of > a * a, dependant on the maximum values of unsigned short, > int and unsigned int: I'm sorry I was not sufficiently clear. > Unsigned integers do not get sign-extended when promoted > to wider unsigned integer types. Why? Because there is > no sign to extend! This is exactly how I thought before I saw two independent compilers producing the binaries that result that result. > First, you believe promotion works from the outside in. > In other words, the type of the variable you're assigning > to will influence the types and promotion of the expression > on the right hand side. They won't. It works from the > inside out. No. I used unsigned short int and unsigned long long int because the original calculation needs them, because the result of the original calculation may not fit inside an unsigned int. The original calculation is more complex than a multiplication of two integers. > Secondly, you've probably been confused by 'hex' output No. I used hexadecimal representation because these extreme values are best represented in hexadecimal. I hope that you answer my question, that is explicit in my other message. My personal opinion is that the two independent compilers I used are buggy, but I want another opinion before reporting this bug to two independent developers.
Res: [c-prog] String and Numbers
--- Mirza Abdullah Jan wrote: > > Hi > I have text file in this pattern > > Jila Tim 45 45 67 5 67 45 3 5 67 89 19823456 > Eva Clarare 42 1 8 43 52 76 1 8 90 43 19345678 > - > - > Kim Jomte 4 5 75 24 52 52 35 35 36 35 19745432 > > I want to get name of each player and total higest score palyer. the last > eight > digits are not required. > > Please guide me how to write code. As your teacher or look in your book about formatted input and the function fscanf.
Res: [c-prog] util class for general method
--- Jos Timanta Tarigan wrote: > im > planning to make a util.cpp file with some methods, and include the cpp file > in > every classes. but i wonder since i havent seen an included .cpp files(all > included are header files) You should not include .cpp files in other .cpp files, but you should instead include a .h header, compile both files separately and link them together. How to do this? It depends on your compiler and platform. It also depends on: Do you want your general library to be a shared library? Or do you want it to be packed with every executable? (Static or dynamic linkage?)
Res: [c-prog] Re: integer promotions
--- Thomas Hruska wrote: > BTW, you should have your compiler warnings turned up > so that you get a warning > for assigning a signed value to an unsigned variable. --- John Matthews asked: > And anyone know the gcc equivalent? > Gcc's -Wall 'all warnings' option doesn't include it. --- andrew clarke replied: > Maybe try: > > gcc -W -Wall The right answer is: gcc -Wconversion
[c-prog] Re: integer promotions
--- Thomas Hruska wrote: > The compiler is treating the resulting value as an unsigned integer > because that is exactly what you told it to do with typecasting. OK, I wrote a bad piece of code. Let me try to codify my problem again: #include #include int main (void) { unsigned short int a; unsigned long long int b, c; a = USHRT_MAX; b = (a*a); c = ((unsigned int)a*(unsigned int)a); printf ("Why %llx != %llx ?\n", b, c); return 0; } When I execute it I get: Why fffe0001 != fffe0001 ? b is wrong. Is this a compiler's bug?
[c-prog] Re: integer promotions
--- "Tyler Littlefield" wrote: > and you want... what exactly? I did not express myself well. Let me reformulate my question: --- "Paul Herring" wrote: > Here you're multiplying two shorts. What is the type of result of a multiplication of two unsigned short integers? In other words: Being: unsigned short int a, b; T result; //... result = (a*b); What should be the type T? When running my previous code the result is: Why fffe0001 != fffe0001 ? Is this result a compiler's bug?
[c-prog] integer promotions
If "The integer promotions preserve value including sign." #include int main (void) { unsigned short int a; unsigned long long int b, c; a = -1; b = (a*a); c = ((unsigned int)a*(unsigned int)a); printf ("Why %llx != %llx ?\n", b, c); return 0; }
Res: [c-prog] Re: programmingsites???
--- Nico Heinze <[EMAIL PROTECTED]> wrote: > > that a beginner will not be able to tell which sites are good and > which are bad. And what about those sites where much information is > good and only some (but pretty important things) are really bad and > wrong? Can a newbie tell the difference? Or even recognise this > difference, to begin with? Yes, if he has a working compiler and he tests his code for abnormal situations. The problem with the bad code referenced in this thread earlier is that that guy learned C++ from a book, skipped some pages, and has no working compiler to test his code before pressing the "Send" button. And a good book may be not useful if the guy uses a pre standard compiler.
Res: [c-prog] Re: programmingsites???
--- Thomas Hruska <[EMAIL PROTECTED]> wrote: > > Under that statement, we should all learn assembler, machine language, > and maybe even leap backwards a few decades and use punch cards. :) I totally agree. My first language was C64 Basic and my second language was Assembly. After I learned 80286 Assembly, object orientation was a punch in my face: I was taught not to mix code with data, just to learn otherwise afterwords. What is complicated in C++ is not the pointers subject, but pointers mixed with classes and namespaces. Java is sweet as it does not have explicit pointers. Plain C is sweet as it does not have classes nor namespaces. C++ is a hell.
Res: [c-prog] printing the address of a variable using cout
Even better: -- ~Rick <[EMAIL PROTECTED]> wrote: > > I am trying to print the address of a variable, not the contents of it. > > Using printf, I would say: > > printf("Allocated %ld bytes at %p\n", bsize+1, fbuf); > > but I want to use the C++ features using cout/cerr. I've tried the > following but get garbage: > > long intbsize= 1023; > char*fbuf; > fbuf = new char[bsize+1]; > if (fbuf) > { // Let the compiler work for you: cerr << "Allocated " << (bsize+1) << " bytes at " << (void*)fbuf << endl; > delete [] fbuf; > } > > I have searched but can only find ios flags for dec, hex, oct but not > for ptr. What is the "secret" here? > > ~Rick
Res: [c-prog] printing the address of a variable using cout
-- ~Rick <[EMAIL PROTECTED]> wrote: > > I am trying to print the address of a variable, not the contents of it. > > Using printf, I would say: > > printf("Allocated %ld bytes at %p\n", bsize+1, fbuf); > > but I want to use the C++ features using cout/cerr. I've tried the > following but get garbage: > > long intbsize= 1023; > char*fbuf; > fbuf = new char[bsize+1]; > if (fbuf) > { > cerr.flags(ios::dec); > cerr << "Allocated " << (bsize+1) << " bytes at "; > cerr.flags(ios::hex); > cerr << fbuf << endl; cerr << (void*)fbuf << endl; > delete [] fbuf; > } > > I have searched but can only find ios flags for dec, hex, oct but not > for ptr. What is the "secret" here? > > ~Rick
Res: [c-prog] Problem with Visual Studio C++ 6.0
-- nayeret43 wrote: > Hi, I tried to run this program: > > #include > main () > > { > int x=25; > float result; > > if (x!=0) > { > resul=1000/x; You forgot the last t of result. > cout << result; > > } > > } > The code above does not follow the standard and the compiler may claim about other problems.