You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(5) |
Feb
(5) |
Mar
(7) |
Apr
(18) |
May
(2) |
Jun
(12) |
Jul
(6) |
Aug
(12) |
Sep
(24) |
Oct
(10) |
Nov
(5) |
Dec
(3) |
2002 |
Jan
(2) |
Feb
(5) |
Mar
(94) |
Apr
(89) |
May
(31) |
Jun
(27) |
Jul
(3) |
Aug
(3) |
Sep
(4) |
Oct
(3) |
Nov
(1) |
Dec
(18) |
2003 |
Jan
(10) |
Feb
(33) |
Mar
(19) |
Apr
(9) |
May
(1) |
Jun
(1) |
Jul
(3) |
Aug
(19) |
Sep
(8) |
Oct
(21) |
Nov
(83) |
Dec
(134) |
2004 |
Jan
(35) |
Feb
(5) |
Mar
|
Apr
(9) |
May
(4) |
Jun
(22) |
Jul
(13) |
Aug
(3) |
Sep
(3) |
Oct
(2) |
Nov
(7) |
Dec
(1) |
2005 |
Jan
(31) |
Feb
(11) |
Mar
(1) |
Apr
|
May
(2) |
Jun
(14) |
Jul
(5) |
Aug
(12) |
Sep
(3) |
Oct
|
Nov
(13) |
Dec
(19) |
2006 |
Jan
|
Feb
|
Mar
(3) |
Apr
(8) |
May
(17) |
Jun
(7) |
Jul
(8) |
Aug
(31) |
Sep
(28) |
Oct
(36) |
Nov
(141) |
Dec
(51) |
2007 |
Jan
(73) |
Feb
(30) |
Mar
(21) |
Apr
(7) |
May
(1) |
Jun
(14) |
Jul
(43) |
Aug
(10) |
Sep
(18) |
Oct
(23) |
Nov
(15) |
Dec
(4) |
2008 |
Jan
(33) |
Feb
(29) |
Mar
(14) |
Apr
(10) |
May
(21) |
Jun
(23) |
Jul
(59) |
Aug
(79) |
Sep
(36) |
Oct
(8) |
Nov
(258) |
Dec
(313) |
2009 |
Jan
(261) |
Feb
(211) |
Mar
(119) |
Apr
(142) |
May
(209) |
Jun
(39) |
Jul
(52) |
Aug
(88) |
Sep
(91) |
Oct
(65) |
Nov
(44) |
Dec
(251) |
2010 |
Jan
(48) |
Feb
(31) |
Mar
(128) |
Apr
(19) |
May
(43) |
Jun
(16) |
Jul
(6) |
Aug
(36) |
Sep
(34) |
Oct
(32) |
Nov
(16) |
Dec
(22) |
2011 |
Jan
(2) |
Feb
(16) |
Mar
(7) |
Apr
(7) |
May
(39) |
Jun
(109) |
Jul
(48) |
Aug
(34) |
Sep
(78) |
Oct
(10) |
Nov
(15) |
Dec
(9) |
2012 |
Jan
(24) |
Feb
(38) |
Mar
(27) |
Apr
|
May
|
Jun
(4) |
Jul
(10) |
Aug
(6) |
Sep
(19) |
Oct
(4) |
Nov
(3) |
Dec
|
2013 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(2) |
May
(4) |
Jun
(11) |
Jul
(22) |
Aug
(4) |
Sep
(1) |
Oct
(31) |
Nov
(15) |
Dec
|
2014 |
Jan
(2) |
Feb
(6) |
Mar
(6) |
Apr
(40) |
May
(30) |
Jun
(35) |
Jul
(5) |
Aug
(21) |
Sep
(6) |
Oct
(5) |
Nov
(22) |
Dec
(91) |
2015 |
Jan
(38) |
Feb
(9) |
Mar
(7) |
Apr
(20) |
May
(4) |
Jun
(6) |
Jul
(3) |
Aug
(15) |
Sep
(4) |
Oct
(3) |
Nov
(5) |
Dec
|
2016 |
Jan
(34) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Karl K. <ka...@kl...> - 2016-01-27 00:43:08
|
Step 1 complete: The tree is imported. I matched all but about a half dozen SF contributor names to github names. The first post-import commit is to add a .gitignore file. git clone https://github.com/crosswire/xiphos.git Step 2 should be locking the SF SVN tree...but I have just found that I have to lock individual files. (/yak/...) I may see about that. It won't take much, just a "find -type f | while read f ; do svn lock .../$f ; done" but OH COME ON. And it doesn't take wildcards. /sigh /I'll be getting to bug report inhalation soon. |
From: Karl K. <ka...@kl...> - 2016-01-25 15:23:38
|
Hi, folks. Something that has been asked of me for quite a while is to move Xiphos development off SourceForge (and its use of SVN, and its political problems) to GitHub. This move is now under way. This has several implications for readers of the developers' list. 1. If you have been, are, or would like to be a contributor to the code or anything else maintained under source control, you will need to sign up for a github.com account, if you don't already have one. If you already do, or when you create one, please send me a note /privately/ (not on this list) to let me know what that account name is. There are 2 reasons for telling me: One, so that I can add you to team crosswire/xiphos on github.com, and two, so that when I do the code import from SourceForge into GitHub, your past commits to the SF code base can be properly "credited" at GitHub. 2. The GitHub repo will be imported from SF once I have collected enough GitHub names from you. (So please get to it reasonably promptly. It won't take you more than a minute or two.) At the moment, the repo is empty. 3. Once the import is done, the SVN tree at SF will be permanently locked. 4. The SF-based mailing lists will be shut down, in favor of new mailing lists xiphos-devel and xiphos-users @crosswire.org. When Troy gets around to creating these, I will mass-add everyone currently in the SF lists to the crosswire.org lists and send an announcement, just before mass-deleting everyone from the SF lists and shutting them down. 5. Bug reports and feature requests will be inhaled from SF into GitHub. Unfortunately, there appears to be no way to preserve the originator of these, so a dummy account will be created to facilitate this, since I don't want my own ID to be attached to every one. In GitHub terms, there are "bugs" and "enhancements," the latter being how we will distinguish SF's idea of a feature request. 6. I have yet to figure out the release procedure on GitHub -- I'll be experimenting with BibleSync first -- but just be aware that GitHub does provide this these days. 7. I am a relative newbie to git. I started using git 2 years ago when I began work on BibleSync (https://github.com/karlkleinpaste/biblesync), but there has been no activity there in a year because BibleSync has been stable, so I haven't even been getting practice. I will make mistakes. Please be patient with me. All told, the 4 essentials we need are source control, bug tracking, file releases, and mailing lists. GitHub provides the first 3 of these, and the new mailing lists at crosswire.org provides the last. --karl |
From: David H. <df...@gm...> - 2016-01-17 16:25:01
|
SMP = Supplementary Multilingual Plane David On Saturday, 16 January 2016, Karl Kleinpaste <ka...@kl...> wrote: > On 01/16/2016 03:38 PM, David Haslam wrote: > > Does the language name for Chinese also contain ideograms from the SMP? > > I don't know what that means. > Search the languages file in an editor for "Chinese" to learn what you > want, or > grep -i -A2 -B1 Chinese /usr/share/xiphos/languages > -- Best regards, David F. Haslam |
From: Karl K. <ka...@kl...> - 2016-01-16 20:48:31
|
On 01/16/2016 03:38 PM, David Haslam wrote: > Does the language name for Chinese also contain ideograms from the SMP? I don't know what that means. Search the languages file in an editor for "Chinese" to learn what you want, or grep -i -A2 -B1 Chinese /usr/share/xiphos/languages |
From: David H. <df...@gm...> - 2016-01-16 20:38:07
|
Does the language name for Chinese also contain ideograms from the SMP? On Friday, 15 January 2016, Karl Kleinpaste <ka...@kl...> wrote: > On 01/14/2016 10:09 AM, David Haslam wrote: > > Where does Gothic get placed? > > Having just experimented with putting the (original?) Gothic name back in > the languages file, previously commented out, it lands between Korean and > Chinese. > -- Best regards, David F. Haslam |
From: Karl K. <ka...@kl...> - 2016-01-15 15:15:46
|
On 01/14/2016 10:09 AM, David Haslam wrote: > Where does Gothic get placed? Having just experimented with putting the (original?) Gothic name back in the languages file, previously commented out, it lands between Korean and Chinese. |
From: Karl K. <ka...@kl...> - 2016-01-14 15:49:22
|
On 01/14/2016 10:09 AM, David Haslam wrote: > Where does Gothic get placed? At the moment, Gothic is just a Latin-script name in the languages file, so it lands ordinarily among the Gs. |
From: David H. <df...@gm...> - 2016-01-14 15:09:17
|
Well done. btw. Where does Gothic get placed? At rock bottom? It was the only name using codepoints in the SMP. David On Thursday, 14 January 2016, Karl Kleinpaste <ka...@kl...> wrote: > FYI to package builders: The ICU-driven fix now requires that icu-i18n be > made a build requirement. The Fedora .spec (for Greg) will need > "Build-Requires: libicu-devel" and Ubuntu packaging will need to gain a > similar directive. > > I'm still hoping to do something about 4.0.5 in the next couple weeks. > -- Best regards, David F. Haslam |
From: Karl K. <ka...@kl...> - 2016-01-14 03:50:34
|
FYI to package builders: The ICU-driven fix now requires that icu-i18n be made a build requirement. The Fedora .spec (for Greg) will need "Build-Requires: libicu-devel" and Ubuntu packaging will need to gain a similar directive. I'm still hoping to do something about 4.0.5 in the next couple weeks. |
From: Karl K. <ka...@kl...> - 2016-01-13 21:25:21
|
With a pointer from DM on sword-devel, I found a solution using ICU and a fix has been committed. Now all the Latin alphabet languages sort first, then Greek, then assorted Cyrillics, Hebrew, various Arabic scripts, and finally all the Asian scripts, ending with Korean, Chinese, and Japanese. Čeština is where it belongs in both Linux and Windows. |
From: Karl K. <ka...@kl...> - 2016-01-09 21:50:00
|
On 01/09/2016 02:49 PM, Rod Reynolds wrote: > BUG! Xiphos is about to crash due to a "STRDUP" error. > Please report this error to the Xiphos team with: > ../src/gnome2/main_menu.c:654 "sword://%s/%s" Interesting. Haven't seen one of those since dirt was new. What version of Xiphos, and what OS platform (Windows or Linux, and version)? The line number doesn't match current source. (If I was as smart as I'd like to think I am, I would have arranged for those bug warnings tell me version numbers as they happen...) --karl |
From: Isaac D. <ib...@gm...> - 2016-01-09 21:33:32
|
On Sat, Jan 09, 2016 at 11:36:52AM -0500, Karl Kleinpaste wrote: > On 01/09/2016 10:01 AM, Peter von Kaehne wrote: > > Why does the terminal startup of xiphos report on openjdk present/absent? > Mine doesn't. Mine reports: > > Vector smash protection is enabled. > ** (xiphos:10621): CRITICAL **: murrine_style_draw_box_gap: > assertion 'height >= -1' failed > > The murrine complaint is something from my window decorator, emerald; > it's done that since the last geological epoch and I have no idea why, > but it affects nothing. "Vector smash" comes out of libflashplayer, > which I didn't realize was linked. > > On my system, the string "openjdk" appears only in libbluray.so.1.9.0. > I can't guess why that's part of the linkage on yours. The murrine complaint is probably something about the GTK theme. libflashplayer and openjdk are probably getting loaded via browser plugins. God bless, Isaac Dunham |
From: Rod R. <rey...@ya...> - 2016-01-09 19:49:54
|
Message: BUG! Xiphos is about to crash due to a "STRDUP" error.Please report this error to the Xiphos team with: ../src/gnome2/main_menu.c:654 "sword://%s/%s" |
From: David H. <df...@gm...> - 2016-01-09 17:02:50
|
- Sorting a set of UTF-8 encoded strings as strings of unsigned bytes yields the same order as sorting the corresponding Unicode strings lexicographically <file:///wiki/Lexicographical_order> by codepoint. On Saturday, 9 January 2016, Karl Kleinpaste <ka...@kl...> wrote: > Unfortunately, that approaches the problem from exactly the wrong > direction. I have UTF-8 strings that need to be sorted as UTF-8 strings > to display in a UTF-8-enabled application, not converted to UTF-16 so that > the (broken) sort comparator is accommodated. There seems to be no UTF-8 > equivalent offered. But I do appreciate the efforts to help find a > solution. > -- Best regards, David F. Haslam |
From: Karl K. <ka...@kl...> - 2016-01-09 16:37:03
|
On 01/09/2016 10:01 AM, Peter von Kaehne wrote: > Why does the terminal startup of xiphos report on openjdk present/absent? Mine doesn't. Mine reports: Vector smash protection is enabled. ** (xiphos:10621): CRITICAL **: murrine_style_draw_box_gap: assertion 'height >= -1' failed The murrine complaint is something from my window decorator, emerald; it's done that since the last geological epoch and I have no idea why, but it affects nothing. "Vector smash" comes out of libflashplayer, which I didn't realize was linked. On my system, the string "openjdk" appears only in libbluray.so.1.9.0. I can't guess why that's part of the linkage on yours. |
From: Peter v. K. <re...@gm...> - 2016-01-09 15:02:06
|
Question out of curiosity: Why does the terminal startup of xiphos report on openjdk present/absent? Peter |
From: Karl K. <ka...@kl...> - 2016-01-09 02:20:18
|
Unfortunately, that approaches the problem from exactly the wrong direction. I have UTF-8 stringsthat need to be sorted as UTF-8 strings to display in a UTF-8-enabled application, not converted to UTF-16 so that the (broken) sort comparator is accommodated. There seems to be no UTF-8 equivalent offered. But I do appreciate the efforts to help find a solution. |
From: Earnie <ea...@us...> - 2016-01-08 18:51:47
|
On 1/8/2016 8:24 AM, Karl Kleinpaste wrote: > On 01/07/2016 03:21 PM, Earnie wrote: >> Does enabling macros UNICODE and _UNICODE on the compiler command line help? > Regrettably, no. > I found this https://msdn.microsoft.com/en-us/library/cc248979.aspx; don't know if it has anything useful. -- Earnie |
From: Karl K. <ka...@kl...> - 2016-01-08 13:24:12
|
On 01/07/2016 03:21 PM, Earnie wrote: > Does enabling macros UNICODE and _UNICODE on the compiler command line help? Regrettably, no. |
From: Earnie <ea...@us...> - 2016-01-07 20:21:33
|
On 1/7/2016 7:38 AM, Karl Kleinpaste wrote: > On second thought, you may be right, I hadn't noticed the UTF-16 version > at first. > > So strcoll(3) in Win32 is using a UTF-16 comparison, whereas everything > else we do everywhere else is UTF-8...except of course for the glib > filesystem interface, which converts pathnames to UTF-16 on Windows' behalf. > > I am so screwed. At least strcmp(3) didn't actually mangle the sort, it > just got it wrong for non-ASCII, whereas strcoll(3) is actually ruining > it. I may have to conditionalize this with #ifdef WIN32 to use strcmp > and leave strcoll to sane systems, unless I can find some other way to > stare at this sideways. Does enabling macros UNICODE and _UNICODE on the compiler command line help? -- Earnie |
From: Karl K. <ka...@kl...> - 2016-01-07 12:38:40
|
On second thought, you may be right, I hadn't noticed the UTF-16 version at first. So strcoll(3) in Win32 is using a UTF-16 comparison, whereas everything else we do everywhere else is UTF-8...except of course for the glib filesystem interface, which converts pathnames to UTF-16 on Windows' behalf. I am so screwed. At least strcmp(3) didn't actually mangle the sort, it just got it wrong for non-ASCII, whereas strcoll(3) is actually ruining it. I may have to conditionalize this with #ifdef WIN32 to use strcmp and leave strcoll to sane systems, unless I can find some other way to stare at this sideways. |
From: Karl K. <ka...@kl...> - 2016-01-07 12:30:58
|
On 01/07/2016 04:44 AM, David Haslam wrote: > It's treating it as ANSI instead of UTF-8. The first character > of Čeština becomes Ä I don't think so. Č is 0xC4 0x8C; Ä is 0xC3 0x84. |
From: David H. <df...@gm...> - 2016-01-07 09:45:04
|
Hi Karl, It's treating it as ANSI instead of UTF-8 The first character of Čeština becomes Ä Best regards, David On Thursday, 7 January 2016, Karl Kleinpaste <ka...@kl...> wrote: > I have a problem. I hadn't bothered initially to build the sort fix for > Win32 because I figured the change from strcmp(3) to strcoll(3) was > sufficiently straightforward. But I just did a few minutes ago and I don't > like the result at all. See the attached image (and ignore the > font-failure boxes, it's a stupid Win7 thing). Bear in mind that this > change was directly because Čeština did not appear among the Cs as it > should. In Linux, strcoll(3) had the right effect for en_US, but in > Win32...well, this is a mess. Can anyone explain why Čeština appears in > the middle of the As instead of the Cs? Also, Hebrew (עברית) sorts to the > very top. Clues, anyone? > -- Best regards, David F. Haslam |
From: Karl K. <ka...@kl...> - 2016-01-07 02:50:40
|
On 01/06/2016 09:47 PM, Henry wrote: > I'll check the Hebrew tomorrow. But is this just on the win32 platform? Yes. On Linux, the sort looks OK. It's just Win32 where it seems ... actually unsorted, or perhaps I should say, de-sorted. |
From: Henry <de...@gm...> - 2016-01-07 02:47:20
|
I'll check the Hebrew tomorrow. But is this just on the win32 platform? On 8:14PM, Wed, Jan 6, 2016 Karl Kleinpaste <ka...@kl...> wrote: > I have a problem. I hadn't bothered initially to build the sort fix for > Win32 because I figured the change from strcmp(3) to strcoll(3) was > sufficiently straightforward. But I just did a few minutes ago and I don't > like the result at all. See the attached image (and ignore the > font-failure boxes, it's a stupid Win7 thing). Bear in mind that this > change was directly because Čeština did not appear among the Cs as it > should. In Linux, strcoll(3) had the right effect for en_US, but in > Win32...well, this is a mess. Can anyone explain why Čeština appears in > the middle of the As instead of the Cs? Also, Hebrew (עברית) sorts to the > very top. Clues, anyone? > > ------------------------------------------------------------------------------ > _______________________________________________ > GnomeSword-developers mailing list > Gno...@li... > https://lists.sourceforge.net/lists/listinfo/gnomesword-developers > |