Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(371) |
Oct
(167) |
Nov
(412) |
Dec
(208) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(378) |
Feb
(302) |
Mar
(269) |
Apr
(296) |
May
(306) |
Jun
(381) |
Jul
(346) |
Aug
(315) |
Sep
(195) |
Oct
(216) |
Nov
(280) |
Dec
(227) |
2002 |
Jan
(309) |
Feb
(333) |
Mar
(328) |
Apr
(407) |
May
(517) |
Jun
(519) |
Jul
(400) |
Aug
(580) |
Sep
(1273) |
Oct
(984) |
Nov
(683) |
Dec
(538) |
2003 |
Jan
(578) |
Feb
(454) |
Mar
(312) |
Apr
(366) |
May
(505) |
Jun
(431) |
Jul
(415) |
Aug
(374) |
Sep
(470) |
Oct
(578) |
Nov
(372) |
Dec
(309) |
2004 |
Jan
(308) |
Feb
(247) |
Mar
(372) |
Apr
(413) |
May
(333) |
Jun
(323) |
Jul
(269) |
Aug
(239) |
Sep
(469) |
Oct
(383) |
Nov
(400) |
Dec
(332) |
2005 |
Jan
(411) |
Feb
(363) |
Mar
(346) |
Apr
(316) |
May
(275) |
Jun
(248) |
Jul
(396) |
Aug
(396) |
Sep
(279) |
Oct
(340) |
Nov
(319) |
Dec
(218) |
2006 |
Jan
(317) |
Feb
(263) |
Mar
(304) |
Apr
(296) |
May
(209) |
Jun
(349) |
Jul
(246) |
Aug
(198) |
Sep
(174) |
Oct
(138) |
Nov
(201) |
Dec
(270) |
2007 |
Jan
(223) |
Feb
(182) |
Mar
(350) |
Apr
(350) |
May
(259) |
Jun
(221) |
Jul
(299) |
Aug
(465) |
Sep
(356) |
Oct
(265) |
Nov
(417) |
Dec
(225) |
2008 |
Jan
(421) |
Feb
(327) |
Mar
(219) |
Apr
(389) |
May
(375) |
Jun
(262) |
Jul
(215) |
Aug
(289) |
Sep
(257) |
Oct
(383) |
Nov
(237) |
Dec
(209) |
2009 |
Jan
(232) |
Feb
(327) |
Mar
(306) |
Apr
(251) |
May
(146) |
Jun
(247) |
Jul
(302) |
Aug
(252) |
Sep
(263) |
Oct
(376) |
Nov
(270) |
Dec
(244) |
2010 |
Jan
(225) |
Feb
(184) |
Mar
(300) |
Apr
(290) |
May
(275) |
Jun
(535) |
Jul
(192) |
Aug
(237) |
Sep
(304) |
Oct
(142) |
Nov
(384) |
Dec
(186) |
2011 |
Jan
(305) |
Feb
(337) |
Mar
(331) |
Apr
(318) |
May
(306) |
Jun
(299) |
Jul
(205) |
Aug
(271) |
Sep
(232) |
Oct
(179) |
Nov
(252) |
Dec
(216) |
2012 |
Jan
(195) |
Feb
(268) |
Mar
(142) |
Apr
(226) |
May
(203) |
Jun
(132) |
Jul
(211) |
Aug
(429) |
Sep
(289) |
Oct
(291) |
Nov
(182) |
Dec
(188) |
2013 |
Jan
(205) |
Feb
(259) |
Mar
(224) |
Apr
(125) |
May
(295) |
Jun
(181) |
Jul
(209) |
Aug
(167) |
Sep
(330) |
Oct
(212) |
Nov
(95) |
Dec
(114) |
2014 |
Jan
(40) |
Feb
(63) |
Mar
(62) |
Apr
(65) |
May
(82) |
Jun
(105) |
Jul
(56) |
Aug
(175) |
Sep
(79) |
Oct
(49) |
Nov
(51) |
Dec
(47) |
2015 |
Jan
(26) |
Feb
(69) |
Mar
(82) |
Apr
(55) |
May
(35) |
Jun
(57) |
Jul
(54) |
Aug
(56) |
Sep
(25) |
Oct
(21) |
Nov
(8) |
Dec
(27) |
2016 |
Jan
(49) |
Feb
(44) |
Mar
(132) |
Apr
(39) |
May
(39) |
Jun
(49) |
Jul
(70) |
Aug
(43) |
Sep
(69) |
Oct
(79) |
Nov
(65) |
Dec
(32) |
2017 |
Jan
(99) |
Feb
(88) |
Mar
(42) |
Apr
(47) |
May
(56) |
Jun
|
Jul
(79) |
Aug
(9) |
Sep
(29) |
Oct
(4) |
Nov
|
Dec
(12) |
2018 |
Jan
(45) |
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
1
(7) |
2
(4) |
3
(7) |
4
(8) |
5
|
6
(5) |
7
(23) |
8
(25) |
9
(6) |
10
(4) |
11
(4) |
12
(12) |
13
(6) |
14
(18) |
15
(12) |
16
(4) |
17
(6) |
18
(6) |
19
(1) |
20
(3) |
21
(10) |
22
(5) |
23
(2) |
24
(4) |
25
(4) |
26
(5) |
27
|
28
(6) |
29
(4) |
30
(5) |
31
(6) |
|
|
From: Eli Zaretskii <eliz@gn...> - 2013-10-04 19:30:31
|
> Date: Fri, 04 Oct 2013 22:21:41 +0300 > From: Eli Zaretskii <eliz@...> > > > Date: Fri, 4 Oct 2013 14:46:51 -0400 > > From: Earnie Boyd <earnie@...> > > > > > If you have problems with localized programs, just rename or remove > > > the *.po files that correspond to your locale, and Bob's your uncle. > > > Btw, could you elaborate on the problem? According to my reading of > > > MSDN, putchar is well equipped to handle multibyte characters, so I'm > > > not sure I understand the problem you have on Windows 7. > > > > MinGW is not yet well versed in MSBC differences in the header files. > > You'll get more milage out of defining UNICODE and _UNICODE and using > > the tchar.h functions; in this case _puttchar(). NOTE you must > > defined both UNICODE and _UNICODE and they must be defined before > > including any header. > > I presume you didn't meant that as a solution to problems with > localization and gettext. Actually, I don't see how _puttchar could be of any use in this situation at all: tchar.h macros are about using either multibyte characters or wide characters, they don't help at all when you need to manipulate multibyte character sequences, like walk a string one multibyte character at a time etc. |
From: Eli Zaretskii <eliz@gn...> - 2013-10-04 19:22:03
|
> Date: Fri, 4 Oct 2013 14:46:51 -0400 > From: Earnie Boyd <earnie@...> > > > If you have problems with localized programs, just rename or remove > > the *.po files that correspond to your locale, and Bob's your uncle. > > Btw, could you elaborate on the problem? According to my reading of > > MSDN, putchar is well equipped to handle multibyte characters, so I'm > > not sure I understand the problem you have on Windows 7. > > MinGW is not yet well versed in MSBC differences in the header files. > You'll get more milage out of defining UNICODE and _UNICODE and using > the tchar.h functions; in this case _puttchar(). NOTE you must > defined both UNICODE and _UNICODE and they must be defined before > including any header. I presume you didn't meant that as a solution to problems with localization and gettext. |
From: Earnie Boyd <earnie@us...> - 2013-10-04 18:48:39
|
On Fri, Oct 4, 2013 at 2:46 PM, Earnie Boyd wrote: > On Fri, Oct 4, 2013 at 10:05 AM, Eli Zaretskii wrote: >>> Date: Fri, 4 Oct 2013 21:22:42 +0800 >>> From: Yongwei Wu >>> >>> I think you missed my point. Being a Chinese and a programmer, I have >>> no problems making Chinese work. The biggest problem now is that >>> putchar may NOT be used successfully for multibyte characters with the >>> msvcrt.dll shipped with Windows 7. Because of this, GCC did NOT work >>> well in Chinese locales. The putchar problem is a runtime-specific >>> problem, as Windows XP did not have this problem, and test executables >>> generated by MSVC 7.1 and 11 on Windows 7 do not have this problem >>> either (they do not use msvcrt.dll). >>> >>> Luckily the latest MinGW GCC 4.8 seems not localized and thus no >>> longer suffers from the problem itself. Executables built by it still >>> do, if they use putchar for multibyte characters.... >> >> If you have problems with localized programs, just rename or remove >> the *.po files that correspond to your locale, and Bob's your uncle. >> Btw, could you elaborate on the problem? According to my reading of >> MSDN, putchar is well equipped to handle multibyte characters, so I'm >> not sure I understand the problem you have on Windows 7. > > MinGW is not yet well versed in MSBC differences in the header files. s/MSBC/MBCS > You'll get more milage out of defining UNICODE and _UNICODE and using > the tchar.h functions; in this case _puttchar(). NOTE you must > defined both UNICODE and _UNICODE and they must be defined before > including any header. > > -- > Earnie > -- https://sites.google.com/site/earnieboyd -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Earnie Boyd <earnie@us...> - 2013-10-04 18:47:05
|
On Fri, Oct 4, 2013 at 10:05 AM, Eli Zaretskii wrote: >> Date: Fri, 4 Oct 2013 21:22:42 +0800 >> From: Yongwei Wu >> >> I think you missed my point. Being a Chinese and a programmer, I have >> no problems making Chinese work. The biggest problem now is that >> putchar may NOT be used successfully for multibyte characters with the >> msvcrt.dll shipped with Windows 7. Because of this, GCC did NOT work >> well in Chinese locales. The putchar problem is a runtime-specific >> problem, as Windows XP did not have this problem, and test executables >> generated by MSVC 7.1 and 11 on Windows 7 do not have this problem >> either (they do not use msvcrt.dll). >> >> Luckily the latest MinGW GCC 4.8 seems not localized and thus no >> longer suffers from the problem itself. Executables built by it still >> do, if they use putchar for multibyte characters.... > > If you have problems with localized programs, just rename or remove > the *.po files that correspond to your locale, and Bob's your uncle. > Btw, could you elaborate on the problem? According to my reading of > MSDN, putchar is well equipped to handle multibyte characters, so I'm > not sure I understand the problem you have on Windows 7. MinGW is not yet well versed in MSBC differences in the header files. You'll get more milage out of defining UNICODE and _UNICODE and using the tchar.h functions; in this case _puttchar(). NOTE you must defined both UNICODE and _UNICODE and they must be defined before including any header. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Robert Martin <robertltux@gm...> - 2013-10-04 16:32:46
|
okay i found out the problem when i installed mingw it did not install the lib header files (posix threads and such). Now comes the fun of compiling BLENDER (and then figuring out how to do a patch and a custom compile). On Fri, Oct 4, 2013 at 8:53 AM, Robert Martin <robertltux@...> wrote: > On Thu, Oct 3, 2013 at 4:42 PM, Earnie Boyd > <earnie@...> wrote: >> -3 doesn't correct the problem you're referencing but the /dev/%yada% >> wasn't the description of the previous issue. The OP states he is >> using Cygwin, maybe Cygwin is translating the i:\ missing a drive >> issue differently. What I need the OP to answer is if he has I:\ >> mapped to a non-existent drive. > > Okay i need to clear a few things up > > 1 i have cygwin installed but im not trying to use both at the same > time (where are the mappings found??) > > 2 in my config i have HD1 split into C D and E (its an HP mini) F is a > install disk (for and part of my HTC thunderbolt) I would be the main > drive of the Thunderbolt (when its connected and in drive mode) > > > im trying to get the error for you (i have my TB in drive mode now) > but it seems to be working. > > it there some sort of config file i can use to tell it to NOT look at > the I drive?? > > > -- > Robert L Martin -- Robert L Martin |
From: Eli Zaretskii <eliz@gn...> - 2013-10-04 14:06:13
|
> Date: Fri, 4 Oct 2013 21:22:42 +0800 > From: Yongwei Wu <wuyongwei@...> > > I think you missed my point. Being a Chinese and a programmer, I have > no problems making Chinese work. The biggest problem now is that > putchar may NOT be used successfully for multibyte characters with the > msvcrt.dll shipped with Windows 7. Because of this, GCC did NOT work > well in Chinese locales. The putchar problem is a runtime-specific > problem, as Windows XP did not have this problem, and test executables > generated by MSVC 7.1 and 11 on Windows 7 do not have this problem > either (they do not use msvcrt.dll). > > Luckily the latest MinGW GCC 4.8 seems not localized and thus no > longer suffers from the problem itself. Executables built by it still > do, if they use putchar for multibyte characters.... If you have problems with localized programs, just rename or remove the *.po files that correspond to your locale, and Bob's your uncle. Btw, could you elaborate on the problem? According to my reading of MSDN, putchar is well equipped to handle multibyte characters, so I'm not sure I understand the problem you have on Windows 7. |
From: Yongwei Wu <wuyongwei@gm...> - 2013-10-04 13:22:50
|
Hi Robert, On Wednesday, 2 October 2013, Robert Hartmann wrote: > > > > I feel bad for my Chinese friends, and wish they all used Windows XP > > or knew how to set LANG=en. > > > > I am not familiar with the GCC source, and do not know how easy it is > > to make a fix. Apparently, one of the following should be possible: > > > > * Remove any use of setlocale(LC_ALL, "") or setlocale(LC_CTYPE, ""). > > * Add a setlocale(LC_CTYPE, "C") after setlocale(LC_ALL, ""). (BTW, > > this was actually a patch for Vim on Windows, to fix a related but > > different locale issue about multibyte characters.) > > * Use printf or puts, but NOT putchar/putc/fputc. (With the last fix, > > I would still have the same problem, but most Chinese users would be > > more lucky.) > > > > Any comments, gurus? > > > > Oh, my GCC version is: > > > > Using built-in specs. > > COLLECT_GCC=gcc > > COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe > > Target: mingw32 > > Configured with: ../gcc-4.5.2/configure > > --enable-languages=c,c++,ada,fortran,objc,obj-c++ > > --disable-sjlj-exceptions --with-dwarf2 --enable-shared > > --enable-libgomp --disable-win32-registry --enablWell, just some thoughts. > > 1) All CodePages supported by Windows are listed in the "Go Global Developer > Center" [1] You see here: UTF-8 is not supported as codepage for > input/output in CMD.exe . > > 2) If you want to print international characters to Windows console, than > you have these options: > > a) Write a unicode-version of your program. > That means define both symbols UNICODE and _UNICODE > and use the w*-functions (wprintf, std::wcout, etc) > and use _wsetlocale. > (It exists a Unicode-Layer for Win9x,ME [2], [3]) > > > b) Write a multibyte-version of your program. > That means define define the symbol _MBCS > and use the "normal" singlebytecharacter functions (printf and friends) > and use setlocale followed by the call _setmbcp(_MB_CP_LOCALE); [4] > > > c) Write a singlebyte-version of your program, > that means you neigther define symbols (UNICODE and _UNICODE) nor _MBCS. > Use the "normal" singlebytecharacter functions (printf and friends) > and use setlocale. But you can't create any valid output for a > DoubleByteCharachterString in this program. > > d) Use TCHAR and t*-function with correct defined symbols. > > 3) On systems where OEM-Codepage (OCP) and ANSI-Codepage (ACP) differ the > console-output of hardcoded strings depends on the source-code fileencoding. > If your editor saves with ACP, than you must convert the string to OCP > first, and after that you can print to console. > > 4) Asume that your program change user's current OEM-codepage to your wanted > OEM-Codepage than it depends on users console-font if he didn't get your > expected output. > > > > 5) To be perfect, I think your program must > 1: define correct symbols in sourcecode. > 2: load a corresponding console-font > 3: change console's current OEM-Codepage i.e. to 936 > 4: print output. > (5: scan keyboard input: well inside a german localized Windows version, > I couldn't find any posibility to insert chinese symbols into console via > keyboard at all) > > > Best regards, > Robert Hartmann (germany) I think you missed my point. Being a Chinese and a programmer, I have no problems making Chinese work. The biggest problem now is that putchar may NOT be used successfully for multibyte characters with the msvcrt.dll shipped with Windows 7. Because of this, GCC did NOT work well in Chinese locales. The putchar problem is a runtime-specific problem, as Windows XP did not have this problem, and test executables generated by MSVC 7.1 and 11 on Windows 7 do not have this problem either (they do not use msvcrt.dll). Luckily the latest MinGW GCC 4.8 seems not localized and thus no longer suffers from the problem itself. Executables built by it still do, if they use putchar for multibyte characters.... Best regards, Yongwei |
From: Robert Martin <robertltux@gm...> - 2013-10-04 12:53:51
|
On Thu, Oct 3, 2013 at 4:42 PM, Earnie Boyd <earnie@...> wrote: > -3 doesn't correct the problem you're referencing but the /dev/%yada% > wasn't the description of the previous issue. The OP states he is > using Cygwin, maybe Cygwin is translating the i:\ missing a drive > issue differently. What I need the OP to answer is if he has I:\ > mapped to a non-existent drive. Okay i need to clear a few things up 1 i have cygwin installed but im not trying to use both at the same time (where are the mappings found??) 2 in my config i have HD1 split into C D and E (its an HP mini) F is a install disk (for and part of my HTC thunderbolt) I would be the main drive of the Thunderbolt (when its connected and in drive mode) im trying to get the error for you (i have my TB in drive mode now) but it seems to be working. it there some sort of config file i can use to tell it to NOT look at the I drive?? -- Robert L Martin |