You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(13) |
Nov
(42) |
Dec
(18) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(12) |
Feb
(2) |
Mar
(9) |
Apr
(3) |
May
(3) |
Jun
(5) |
Jul
(13) |
Aug
(10) |
Sep
(5) |
Oct
(39) |
Nov
(44) |
Dec
(59) |
2004 |
Jan
(15) |
Feb
(44) |
Mar
(163) |
Apr
(74) |
May
(19) |
Jun
(53) |
Jul
(110) |
Aug
(173) |
Sep
(157) |
Oct
(74) |
Nov
(243) |
Dec
(326) |
2005 |
Jan
(112) |
Feb
(274) |
Mar
(336) |
Apr
(547) |
May
(465) |
Jun
(226) |
Jul
(227) |
Aug
(348) |
Sep
(134) |
Oct
(229) |
Nov
(202) |
Dec
(127) |
2006 |
Jan
(56) |
Feb
(136) |
Mar
(113) |
Apr
(133) |
May
(149) |
Jun
(59) |
Jul
(31) |
Aug
(134) |
Sep
(47) |
Oct
(132) |
Nov
(92) |
Dec
(72) |
2007 |
Jan
(193) |
Feb
(258) |
Mar
(213) |
Apr
(103) |
May
(84) |
Jun
(27) |
Jul
(40) |
Aug
(59) |
Sep
(62) |
Oct
(64) |
Nov
(105) |
Dec
(148) |
2008 |
Jan
(262) |
Feb
(35) |
Mar
(44) |
Apr
(27) |
May
|
Jun
(37) |
Jul
(10) |
Aug
(29) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2009 |
Jan
(149) |
Feb
(53) |
Mar
(92) |
Apr
(69) |
May
(34) |
Jun
(51) |
Jul
(48) |
Aug
(44) |
Sep
(35) |
Oct
(25) |
Nov
(31) |
Dec
(14) |
2010 |
Jan
(13) |
Feb
(29) |
Mar
(2) |
Apr
(3) |
May
(9) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(4) |
Dec
|
2011 |
Jan
|
Feb
|
Mar
(7) |
Apr
(6) |
May
(2) |
Jun
(2) |
Jul
(7) |
Aug
(10) |
Sep
(5) |
Oct
(3) |
Nov
(2) |
Dec
(5) |
2012 |
Jan
(17) |
Feb
(3) |
Mar
(11) |
Apr
(6) |
May
(23) |
Jun
(13) |
Jul
(10) |
Aug
(13) |
Sep
(5) |
Oct
(14) |
Nov
(27) |
Dec
(12) |
2013 |
Jan
(44) |
Feb
(41) |
Mar
|
Apr
(8) |
May
(5) |
Jun
(31) |
Jul
|
Aug
(11) |
Sep
(1) |
Oct
|
Nov
(16) |
Dec
(34) |
2014 |
Jan
|
Feb
|
Mar
(90) |
Apr
(57) |
May
(10) |
Jun
(5) |
Jul
(12) |
Aug
(5) |
Sep
(8) |
Oct
|
Nov
|
Dec
(1) |
2015 |
Jan
|
Feb
(8) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
(10) |
Aug
(2) |
Sep
|
Oct
(30) |
Nov
|
Dec
|
2016 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
(21) |
May
|
Jun
(3) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
(5) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(10) |
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(20) |
Dec
|
2019 |
Jan
|
Feb
(4) |
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
2021 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2022 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Adam R.M. <ama...@me...> - 2003-10-31 13:25:07
|
On 31 Oct, 2003, at 04:39, Michael McCracken wrote: > One other thing I noticed, the code flags tabs as a 'bad' non-ascii > character, which they definitely aren't... I'll fix that once I get > XCode up and running... Oops! Sorry for breaking all that stuff, and thanks for working on my brain farts on accepting control characters. Yeah, there's probably a faster way of doing this; I was going for simple, but it will hurt on opening large files. What about tagging CVS with a Jaguar branch right now, so someone can easily check out a version that will build on Jag? > gee, panther mail is nice. Panther is nice. I just discovered Native targets yesterday in XCode; Fix and Continue is cool. Adam |
From: Michael M. <mic...@ma...> - 2003-10-31 10:39:24
|
One other thing I noticed, the code flags tabs as a 'bad' non-ascii character, which they definitely aren't... I'll fix that once I get XCode up and running... gee, panther mail is nice. -mike On Oct 30, 2003, at 8:09 PM, Michael McCracken wrote: > OK, so I've left the special cases in, to be revisited later for the > *correct* solution :) I've also had to change adam's patch so that it > won't flag \n as a "bad" non-ascii character. > > I think that we're actually doing this checking in a slow way, so for > one thing I've made it so we only create the "EnglishLetters" > character set once. There is probably a much faster way to do this, > including checking for set membership by checking if the string has > characters in an inverted set instead of using NSScanner and checking > lengths... however, I'm not going to optimize that unless it seems to > be getting really slow... > > That reminds me that one of the things we need to add as test data is > very large files. someone sent me a huge one a while back, I'll try to > chase down some permission to post it. > > my AIM was q606. > > -mike > > On Thursday, October 30, 2003, at 07:46 PM, James Howison wrote: > >> >> On Thursday, October 30, 2003, at 10:21 pm, Michael McCracken wrote: >> >>> hey, I'm going to release a quick pre-panther version tonight >>> because I want to install panther... >>> >>> since XCode lets you target earlier versions of the OS, I plan to >>> keep a Jaguar version around as much as possible, and I'm not as >>> worried about getting out a perfect update before switching over. >>> >>> What I'm going to do is put back in the special cases for the >>> newlines, and we can figure out a best solution for that later, >>> without worrying about abandoning jaguar users. >>> >>> any big objections? I'm hoping that this will be the start of a more >>> release-early release-often future for bibdesk... >> >> No big objections here. I haven't had time this week to get around >> to this I'm afraid. And don't want to put off your move to Panther >> just for this! >> >> Make sure we note that there is a potential serious data-loss issue >> if the file has been edited with another editor (and non-ascii chars >> introduced ... >> >> (remember the point of the patch wasn't newlines and pars but fixing >> the 'insert accents and loose all abstracts' problem) >> >> Also I haven't had a chance to digest Adam's comments about the >> non-ASCII chars introduced in a conversion ... perhaps bt_parse >> isn't the solution for this that I'd hoped. >> >> So other than be sure to include those caveats let's release, upgrade >> to Panther and move-on forward ... >> >> Cheers, >> James >> >> ps. what was that iChat ID again? I'm jameshowisonsyr >> >>> >>> -mike >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: SF.net Giveback Program. >>> Does SourceForge.net help you be more productive? Does it >>> help you create better code? SHARE THE LOVE, and help us help >>> YOU! Click Here: http://sourceforge.net/donate/ >>> _______________________________________________ >>> Bibdesk-develop mailing list >>> Bib...@li... >>> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop >>> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: SF.net Giveback Program. >> Does SourceForge.net help you be more productive? Does it >> help you create better code? SHARE THE LOVE, and help us help >> YOU! Click Here: http://sourceforge.net/donate/ >> _______________________________________________ >> Bibdesk-develop mailing list >> Bib...@li... >> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Bibdesk-develop mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop |
From: Michael M. <mic...@ma...> - 2003-10-31 04:09:19
|
OK, so I've left the special cases in, to be revisited later for the *correct* solution :) I've also had to change adam's patch so that it won't flag \n as a "bad" non-ascii character. I think that we're actually doing this checking in a slow way, so for one thing I've made it so we only create the "EnglishLetters" character set once. There is probably a much faster way to do this, including checking for set membership by checking if the string has characters in an inverted set instead of using NSScanner and checking lengths... however, I'm not going to optimize that unless it seems to be getting really slow... That reminds me that one of the things we need to add as test data is very large files. someone sent me a huge one a while back, I'll try to chase down some permission to post it. my AIM was q606. -mike On Thursday, October 30, 2003, at 07:46 PM, James Howison wrote: > > On Thursday, October 30, 2003, at 10:21 pm, Michael McCracken wrote: > >> hey, I'm going to release a quick pre-panther version tonight because >> I want to install panther... >> >> since XCode lets you target earlier versions of the OS, I plan to >> keep a Jaguar version around as much as possible, and I'm not as >> worried about getting out a perfect update before switching over. >> >> What I'm going to do is put back in the special cases for the >> newlines, and we can figure out a best solution for that later, >> without worrying about abandoning jaguar users. >> >> any big objections? I'm hoping that this will be the start of a more >> release-early release-often future for bibdesk... > > No big objections here. I haven't had time this week to get around to > this I'm afraid. And don't want to put off your move to Panther just > for this! > > Make sure we note that there is a potential serious data-loss issue if > the file has been edited with another editor (and non-ascii chars > introduced ... > > (remember the point of the patch wasn't newlines and pars but fixing > the 'insert accents and loose all abstracts' problem) > > Also I haven't had a chance to digest Adam's comments about the > non-ASCII chars introduced in a conversion ... perhaps bt_parse isn't > the solution for this that I'd hoped. > > So other than be sure to include those caveats let's release, upgrade > to Panther and move-on forward ... > > Cheers, > James > > ps. what was that iChat ID again? I'm jameshowisonsyr > >> >> -mike >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: SF.net Giveback Program. >> Does SourceForge.net help you be more productive? Does it >> help you create better code? SHARE THE LOVE, and help us help >> YOU! Click Here: http://sourceforge.net/donate/ >> _______________________________________________ >> Bibdesk-develop mailing list >> Bib...@li... >> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Bibdesk-develop mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop |
From: James H. <jho...@sy...> - 2003-10-31 03:47:04
|
On Thursday, October 30, 2003, at 10:21 pm, Michael McCracken wrote: > hey, I'm going to release a quick pre-panther version tonight because > I want to install panther... > > since XCode lets you target earlier versions of the OS, I plan to keep > a Jaguar version around as much as possible, and I'm not as worried > about getting out a perfect update before switching over. > > What I'm going to do is put back in the special cases for the > newlines, and we can figure out a best solution for that later, > without worrying about abandoning jaguar users. > > any big objections? I'm hoping that this will be the start of a more > release-early release-often future for bibdesk... No big objections here. I haven't had time this week to get around to this I'm afraid. And don't want to put off your move to Panther just for this! Make sure we note that there is a potential serious data-loss issue if the file has been edited with another editor (and non-ascii chars introduced ... (remember the point of the patch wasn't newlines and pars but fixing the 'insert accents and loose all abstracts' problem) Also I haven't had a chance to digest Adam's comments about the non-ASCII chars introduced in a conversion ... perhaps bt_parse isn't the solution for this that I'd hoped. So other than be sure to include those caveats let's release, upgrade to Panther and move-on forward ... Cheers, James ps. what was that iChat ID again? I'm jameshowisonsyr > > -mike > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Bibdesk-develop mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop > |
From: Michael M. <mic...@ma...> - 2003-10-31 03:21:24
|
hey, I'm going to release a quick pre-panther version tonight because I want to install panther... since XCode lets you target earlier versions of the OS, I plan to keep a Jaguar version around as much as possible, and I'm not as worried about getting out a perfect update before switching over. What I'm going to do is put back in the special cases for the newlines, and we can figure out a best solution for that later, without worrying about abandoning jaguar users. any big objections? I'm hoping that this will be the start of a more release-early release-often future for bibdesk... -mike |
From: Michael M. <mic...@ma...> - 2003-10-29 21:26:54
|
yeah, I messed up a commit - I think it's fixed in cvs now - am I wrong? On Wednesday, October 29, 2003, at 05:41 AM, Adam R.Maxwell wrote: > Mike, > > I'm not seeing the "Startup" preferences pane in a current CVS build. > The one that's showing under Startup in the BD->Preferences menu item > is actually for Autofile (which looks like a stellar idea). Something > connected wrong? > > Adam > > |
From: Michael M. <mic...@ma...> - 2003-10-29 21:25:18
|
Alright, sounds like a good idea - but you don't need to drop into sed, just use the NSMutableString call at http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ ObjC_classic/Classes/NSMutableString.html#//apple_ref/doc/uid/20000156/ BCIFDIAF it replaces occurrences of a string with another string... and you can check the range, too, to confine it within brackets. hmm, maybe it could be easier in another language. make up your own mind, I guess, although I'm thinking that it'd be faster if you can get it to work in C/ObjC. -mike On Wednesday, October 29, 2003, at 11:01 AM, James Howison wrote: > > On Wednesday, October 29, 2003, at 02:48 am, Michael McCracken wrote: > >> Hey James, how's this going? I'd like to throw out a last Jaguar >> version before I upgrade to Panther sometime this week... > > Yeah. that would be a good idea. > > Really the only thing I can think of is running a sed type script over > the incoming files which, inside the Annote, Abstract and RSS fields > replaces the \n with {\newline} and the \n\n with {\par}. And do this > before parsing with bt_parse. > > Before I implement this can anyone see any probs (have to be sure to > do it only inside those field, but that shouldn't be hard)? > > Thanks, > James > > >> >> Also, is everyone else using Panther already? > > I've held off but have the disks in hand > >> >> -mike >> >> On Saturday, October 25, 2003, at 06:13 PM, James Howison wrote: >> >>> >>> On Saturday, October 25, 2003, at 09:00 pm, Michael McCracken wrote: >>> >>>> I was just testing for the next release, and I noticed this problem >>>> - hopefully someone will have a fix for it... >>> >>> I'll roll up my sleeve on this one tomorrow. Hmmm. This happens in >>> the bt_parse library when it is read in. No wonder you had a >>> special case---might need to go back to that. >>> >>> Silly thing is that new lines like that in the Annote are only >>> useful for formatting the viewing in Bibdesk---if you ever use them >>> via Bibtex they get stripped out. >>> >>> Thanks for pointing it out. All files created by Bibdesk will have >>> these newlines in them, so we'd better not break that! >>> >>> James >>> >>>> the problem is that with the new patches, files that have something >>>> like this: >>>> >>>> @foo{.... >>>> >>>> Annote={this >>>> >>>> entry has >>>> newlines} >>>> ...} >>>> >>>> when this file is read by bibdesk, the newlines are stripped. if >>>> you add {\par} instead, then it'll work... unfortunately, this will >>>> break everyone's files that already have newlines in them. any >>>> ideas? I haven't looked at that part of the code very deeply, but I >>>> am hoping that we can just add something to respect newlines when >>>> de-texifying...? >>>> >>>> -mike >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.net email is sponsored by: The SF.net Donation Program. >>>> Do you like what SourceForge.net is doing for the Open >>>> Source Community? Make a contribution, and help us add new >>>> features and functionality. Click here: >>>> http://sourceforge.net/donate/ >>>> _______________________________________________ >>>> Bibdesk-develop mailing list >>>> Bib...@li... >>>> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop >>>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: The SF.net Donation Program. >>> Do you like what SourceForge.net is doing for the Open >>> Source Community? Make a contribution, and help us add new >>> features and functionality. Click here: >>> http://sourceforge.net/donate/ >>> _______________________________________________ >>> Bibdesk-develop mailing list >>> Bib...@li... >>> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: SF.net Giveback Program. >> Does SourceForge.net help you be more productive? Does it >> help you create better code? SHARE THE LOVE, and help us help >> YOU! Click Here: http://sourceforge.net/donate/ >> _______________________________________________ >> Bibdesk-develop mailing list >> Bib...@li... >> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Bibdesk-develop mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop |
From: James H. <jho...@sy...> - 2003-10-29 19:01:12
|
On Wednesday, October 29, 2003, at 02:48 am, Michael McCracken wrote: > Hey James, how's this going? I'd like to throw out a last Jaguar > version before I upgrade to Panther sometime this week... Yeah. that would be a good idea. Really the only thing I can think of is running a sed type script over the incoming files which, inside the Annote, Abstract and RSS fields replaces the \n with {\newline} and the \n\n with {\par}. And do this before parsing with bt_parse. Before I implement this can anyone see any probs (have to be sure to do it only inside those field, but that shouldn't be hard)? Thanks, James > > Also, is everyone else using Panther already? I've held off but have the disks in hand > > -mike > > On Saturday, October 25, 2003, at 06:13 PM, James Howison wrote: > >> >> On Saturday, October 25, 2003, at 09:00 pm, Michael McCracken wrote: >> >>> I was just testing for the next release, and I noticed this problem >>> - hopefully someone will have a fix for it... >> >> I'll roll up my sleeve on this one tomorrow. Hmmm. This happens in >> the bt_parse library when it is read in. No wonder you had a special >> case---might need to go back to that. >> >> Silly thing is that new lines like that in the Annote are only useful >> for formatting the viewing in Bibdesk---if you ever use them via >> Bibtex they get stripped out. >> >> Thanks for pointing it out. All files created by Bibdesk will have >> these newlines in them, so we'd better not break that! >> >> James >> >>> the problem is that with the new patches, files that have something >>> like this: >>> >>> @foo{.... >>> >>> Annote={this >>> >>> entry has >>> newlines} >>> ...} >>> >>> when this file is read by bibdesk, the newlines are stripped. if you >>> add {\par} instead, then it'll work... unfortunately, this will >>> break everyone's files that already have newlines in them. any >>> ideas? I haven't looked at that part of the code very deeply, but I >>> am hoping that we can just add something to respect newlines when >>> de-texifying...? >>> >>> -mike >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: The SF.net Donation Program. >>> Do you like what SourceForge.net is doing for the Open >>> Source Community? Make a contribution, and help us add new >>> features and functionality. Click here: >>> http://sourceforge.net/donate/ >>> _______________________________________________ >>> Bibdesk-develop mailing list >>> Bib...@li... >>> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop >>> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: The SF.net Donation Program. >> Do you like what SourceForge.net is doing for the Open >> Source Community? Make a contribution, and help us add new >> features and functionality. Click here: http://sourceforge.net/donate/ >> _______________________________________________ >> Bibdesk-develop mailing list >> Bib...@li... >> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Bibdesk-develop mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop > |
From: Adam R.M. <ama...@ws...> - 2003-10-29 17:35:20
|
Okay, I committed a patch for checking whether the .bib file opened by=20= the user has non-ascii characters in it (BibTeX can't read these, and=20 we make the problem worse by adding more with every save). At the=20 moment, it isn't very user-friendly, since I can't figure out how to=20 get the line number of the error and pass it to the warning panel. I=20 thought about writing some garbage and a " character into the string=20 (since it was bad anyway) so btparse would give an error (and the line=20= number), but that seems too evil. Any suggestions? Here's an invalid bibitem to see what this does: @article{auzerais1990, Author =3D {Fran=E7ois M. Auzerais and R. Jackson and W. B. = Russel and W.=20 F. Murphy}, Journal =3D {Journal of Fluid Mechanics}, Keywords =3D {settling, flocculation, constitutive}, Pages =3D {613-639}, Title =3D {The transient settling of stable and flocculated = dispersions}, Volume =3D {221}, Year =3D {1990}} later, Adam |
From: Adam R.M. <ama...@ws...> - 2003-10-29 13:41:13
|
Mike, I'm not seeing the "Startup" preferences pane in a current CVS build. The one that's showing under Startup in the BD->Preferences menu item is actually for Autofile (which looks like a stellar idea). Something connected wrong? Adam |
From: Adam R.M. <ama...@ws...> - 2003-10-29 13:36:21
|
On 29 Oct, 2003, at 01:48, Michael McCracken wrote: > Also, is everyone else using Panther already? I'm using Panther, and I can't see going back to Jag now. The new searchable documentation with XCode is especially nice, I think. Adam |
From: Michael M. <mic...@ma...> - 2003-10-29 07:48:47
|
Hey James, how's this going? I'd like to throw out a last Jaguar version before I upgrade to Panther sometime this week... Also, is everyone else using Panther already? -mike On Saturday, October 25, 2003, at 06:13 PM, James Howison wrote: > > On Saturday, October 25, 2003, at 09:00 pm, Michael McCracken wrote: > >> I was just testing for the next release, and I noticed this problem - >> hopefully someone will have a fix for it... > > I'll roll up my sleeve on this one tomorrow. Hmmm. This happens in > the bt_parse library when it is read in. No wonder you had a special > case---might need to go back to that. > > Silly thing is that new lines like that in the Annote are only useful > for formatting the viewing in Bibdesk---if you ever use them via > Bibtex they get stripped out. > > Thanks for pointing it out. All files created by Bibdesk will have > these newlines in them, so we'd better not break that! > > James > >> the problem is that with the new patches, files that have something >> like this: >> >> @foo{.... >> >> Annote={this >> >> entry has >> newlines} >> ...} >> >> when this file is read by bibdesk, the newlines are stripped. if you >> add {\par} instead, then it'll work... unfortunately, this will break >> everyone's files that already have newlines in them. any ideas? I >> haven't looked at that part of the code very deeply, but I am hoping >> that we can just add something to respect newlines when >> de-texifying...? >> >> -mike >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: The SF.net Donation Program. >> Do you like what SourceForge.net is doing for the Open >> Source Community? Make a contribution, and help us add new >> features and functionality. Click here: http://sourceforge.net/donate/ >> _______________________________________________ >> Bibdesk-develop mailing list >> Bib...@li... >> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > Bibdesk-develop mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop |
From: James H. <jho...@sy...> - 2003-10-26 01:18:04
|
On Saturday, October 25, 2003, at 09:00 pm, Michael McCracken wrote: > I was just testing for the next release, and I noticed this problem - > hopefully someone will have a fix for it... I'll roll up my sleeve on this one tomorrow. Hmmm. This happens in the bt_parse library when it is read in. No wonder you had a special case---might need to go back to that. Silly thing is that new lines like that in the Annote are only useful for formatting the viewing in Bibdesk---if you ever use them via Bibtex they get stripped out. Thanks for pointing it out. All files created by Bibdesk will have these newlines in them, so we'd better not break that! James > the problem is that with the new patches, files that have something > like this: > > @foo{.... > > Annote={this > > entry has > newlines} > ...} > > when this file is read by bibdesk, the newlines are stripped. if you > add {\par} instead, then it'll work... unfortunately, this will break > everyone's files that already have newlines in them. any ideas? I > haven't looked at that part of the code very deeply, but I am hoping > that we can just add something to respect newlines when > de-texifying...? > > -mike > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > Bibdesk-develop mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop > |
From: Michael M. <mic...@ma...> - 2003-10-26 01:06:51
|
I was just testing for the next release, and I noticed this problem - hopefully someone will have a fix for it... the problem is that with the new patches, files that have something like this: @foo{.... Annote={this entry has newlines} ...} when this file is read by bibdesk, the newlines are stripped. if you add {\par} instead, then it'll work... unfortunately, this will break everyone's files that already have newlines in them. any ideas? I haven't looked at that part of the code very deeply, but I am hoping that we can just add something to respect newlines when de-texifying...? -mike |
From: Adam R.M. <ama...@ws...> - 2003-10-24 10:34:59
|
I guess this question is mainly for Mike. What is the expected=20 behavior of BibDesk when it encounters a character that isn't part of=20 the CharacterConversion.plist? I had this Bibtex item, which looked=20 fine when I entered it: @article{auzerais1990, Author =3D {Fran=8Dois M. Auzerais and R. Jackson and W. B. = Russel and W.=20 F. Murphy}, Journal =3D {Journal of Fluid Mechanics}, Keywords =3D {settling, flocculation, constitutive}, Pages =3D {613-639}, Title =3D {The transient settling of stable and flocculated = dispersions}, Volume =3D {221}, Year =3D {1990}} where the =8D (TeX \c{c}) was changed to the following after saving = once: @article{auzerais1990, Author =3D {Fran=C3=A7ois M. Auzerais and R. Jackson and W. B. = Russel and W.=20 F. Murphy}, Journal =3D {Journal of Fluid Mechanics}, Keywords =3D {settling, flocculation, constitutive}, Pages =3D {613-639}, Title =3D {The transient settling of stable and flocculated = dispersions}, Volume =3D {221}, Year =3D {1990}} Saving the file in this state and reopening, the =C3=A7 has now become=20= =E2=88=9A=C3=9F. I found this after BibTeX ran out of memory on a = certain line=20 when processing my bibliography database; opening the .bib file with vi=20= showed a long string of characters in that line (the above citation). =20= Obviously I had opened and saved the file a few dozen times in that=20 state, and that string had grown each time. James' patch had no effect on this, BTW. The best workaround at this=20 point was to add the necessary strings to the=20 CharacterConversion.plist. Would there be any way to implement a check=20= to see if a non-ASCII character exists in CharacterConversion.plist=20 when saving a file? later, Adam= |
From: Michael M. <mic...@ma...> - 2003-10-24 04:26:40
|
Ok, I've added the patches from James, and tested out the emailing stuff a little more. I'm going to release the current repository soon as 0.83 - if anyone has any changes that they haven't checked in, speak now or hold your peace for a week or so... I still haven't committed the changes to the nibs, but I'll do that soon, then tag the repository as REL_0_83, so we know where we were at this release. I've also added James as a developer, because I thought he was already and I was wondering why he just sent in a patch. :) Thanks James! now you can check out a repository that you can commit from. -mike On Monday, October 20, 2003, at 10:50 PM, James Howison wrote: > > On Thursday, October 16, 2003, at 09:47 am, Adam R.Maxwell wrote: > >> Hi Mike, >> >> Can you set the Reply-to so that replies go to the mailing list by >> default? >> >> On Oct 15, 2003, at 19:54, Michael McCracken wrote: >> >>> Does anyone have any pending issues with releasing the current code >>> (plus the accented char loss patch) as .83? >> >> Nope. Release early, release often :). James' patch doesn't seem to >> have caused any problems for me in day-to-day use. > > Provided we remember the additional line patch that I posted to the > bug entry ... > >> >>> Another thing, since I like this feature so much: I've added "email >>> this pub" as a feature, but there's an issue to resolve - and I need >>> input. >> >> Use the Service->Send File, I think. It seems to me that any other >> way would require knowing an SMTP server (or embedding that >> functionality); between Apple's broken sendmail on 10.2 and earlier, >> as well as firewalls, it might just cause more problems. >> >> Re: your previous note on iChat, I finally signed up for AIM to try >> it out; my id is armax1976. >> >> later, >> Adam >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: SF.net Giveback Program. >> SourceForge.net hosts over 70,000 Open Source Projects. >> See the people who have HELPED US provide better services: >> Click here: http://sourceforge.net/supporters.php >> _______________________________________________ >> Bibdesk-develop mailing list >> Bib...@li... >> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win > $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > Bibdesk-develop mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop |
From: Bruce D'A. <bd...@fa...> - 2003-10-23 19:04:55
|
BTW, if anyone wants to experiment with bibtex, xml and xslt, I recommend downloading this: http://bibtexml.sf.net/bibtexml-pre.tar.gz There are xslt files for converting from bibtexml to both bibtex and html. You can run them like so if you have xsltproc installed (this if you're in the examples directory): xsltproc -o ../xslt/test.html ../xslt/bibtexml2html.xsl example.bibtex.xml Bruce |
From: Bruce D'A. <bd...@fa...> - 2003-10-23 03:22:19
|
On Tuesday, October 21, 2003, at 02:12 AM, James Howison wrote: > But I'm not sure that I'll be able to get into all this in build what > is just meant to be a proof-of-concept file manager after all. There's always BibTeXML of course: a straight XML representation of BibTeX. I guess my issues are bigger than BibDesk of course. I just think BibTeX is a bad way to store bibliographic metadata (it's fine as a bibliographic typesetting system though), and I don't believe GUI apps should rely on it for storage. Alas, Apple clearly doesn't yet "get" XML, and so support for it in Cocoa is not what it should be to enable easier support for it in applications. Bruce |
From: James H. <jho...@sy...> - 2003-10-22 01:21:09
|
Wow---remind me to have a chunk of time available to absorb great ideas next time I put something out there ;) Michael---thanks for the offer of walking me through some of the code. XMP is something I mentioned a while back, but I'm finding that the tools are not as available as I'd like. Perl is looking useful though. Not sure how to integrate that with the cocoa stuff. Really must roll the sleeves up. Adam wrote, > One thing I've done for file management is to standardize my > filenames with firstauthorYear.pdf, to make searching easier for > others in my group who have access to the files I've collected (I > like the bladerunner.pdf filename that J. Fluid Mech. gives me, but > it's unhelpful when I have a dozen bladerunner-n.pdf files). I'm lazy. I use surnameYearFirstworld.pdf because that is the default from citeseer and is their default labl as well. (which is a bit annoying if the year is wrong (one shouldn't have to change a label if some of the metadata changes---but we have to call it something, no?) Bruce---really appreciate your pointers on the nedw developments in citation-rdf-blog convergence. This stuff is awesome and definitely where we should take the rss side of bibdesk. rdf is definately the way to go for metadata (and happily works ideally with XMP for PDFs). But I'm not sure that I'll be able to get into all this in build what is just meant to be a proof-of-concept file manager after all. J On Wednesday, October 15, 2003, at 10:41 am, Bruce D'Arcus wrote: > resending without screenshot... > > On Wednesday, October 15, 2003, at 10:00 AM, Adam R.Maxwell wrote: > >> On Oct 15, 2003, at 08:35, Bruce D'Arcus wrote: >>> Beginnings of a bibtex2mods converter is at: >>> >>> http://www.scripps.edu/~cdputnam/bibutils3 >>> >> >> Is that the bib2xml program? >> <http://www.scripps.edu/~cdputnam/software/bibutils.html> has source >> code; the ELF binary won't do us any good :). This site looks >> interesting, also: <http://www.nongnu.org/bibulus/paper.html>. Too >> many fragments of good ideas out there. > > My link is for the next generation version of the tools on the link > you provide above. In other words, he's replacing his current xml-ish > "intermediate format" with MODS. So, his suite of tools will support > converting back-and-forth amongs endnote, bibtex, medline, ris, and > mods. Source is available for all of this, and I'm sure I can get a > binary build of the new alpha if people want to experiment. Let me > know. > > My big point is that bibtex is the absolute wrong way to encode > metadata in an era of rdf and xml. > > OK, first, click on this link: > > http://jena.hpl.hp.com:3030/blojsom-devt/blog/ > > Click on the xml view to see how bibtex data has been transformed to > RDF/XML.* Now, click on the edit link to see another view, and the > record card format for still another. > > Now, search the entries here: > > http://jena.hpl.hp.com:3030/blojsom-devt/semquery.html > > Now, to get even cooler, try this link: > > http://jena.hpl.hp.com:3030/blojsom-devt/semnav.html > > How cool is that?? (though seems a little buggy on Safari at least) > > Some similar ideas are in the new Syncato weblog system. It uses a > native xml db (based on Berkeley DB) as it's storage format, though > now can also deal with flat xml files. This stuff is way cool. > > http://www.syncato.org > > And below is a screenshot of a web interface I've been working on > that uses the eXist XML DB. It took me a few hours to modify the xslt > files to query and display my custom bibliographic schema (modeled on > MODS, but dumbed down). What I ultimately want to do is to be able to > mark up quote excerpts from books and articles, complete with page > numbers and keywords. I can then search for them based on whatever > criteria, and the metadata will always be tied to the quote itself. > Below the (128) is my manual marking of the pages, which is just dumb. > This is originally Endnote data though. very cool. > > [snip] > > Bruce > > * Converter at http://www.cs.vu.nl/~mcaklein/bib2rdf/ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > SourceForge.net hosts over 70,000 Open Source Projects. > See the people who have HELPED US provide better services: > Click here: http://sourceforge.net/supporters.php > _______________________________________________ > Bibdesk-develop mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop > |
From: Adam R.M. <ama...@ws...> - 2003-10-21 14:07:18
|
On Oct 21, 2003, at 00:50, James Howison wrote: > > On Thursday, October 16, 2003, at 09:47 am, Adam R.Maxwell wrote: > >> James' patch doesn't seem to have caused any problems for me in >> day-to-day use. > > Provided we remember the additional line patch that I posted to the > bug entry ... This is true. Did you ever get the BibTeX preview panel working? ISTR you were having problems with that. |
From: James H. <jho...@sy...> - 2003-10-21 08:25:07
|
On Thursday, October 16, 2003, at 09:47 am, Adam R.Maxwell wrote: > Hi Mike, > > Can you set the Reply-to so that replies go to the mailing list by > default? > > On Oct 15, 2003, at 19:54, Michael McCracken wrote: > >> Does anyone have any pending issues with releasing the current code >> (plus the accented char loss patch) as .83? > > Nope. Release early, release often :). James' patch doesn't seem to > have caused any problems for me in day-to-day use. Provided we remember the additional line patch that I posted to the bug entry ... > >> Another thing, since I like this feature so much: I've added "email >> this pub" as a feature, but there's an issue to resolve - and I need >> input. > > Use the Service->Send File, I think. It seems to me that any other > way would require knowing an SMTP server (or embedding that > functionality); between Apple's broken sendmail on 10.2 and earlier, > as well as firewalls, it might just cause more problems. > > Re: your previous note on iChat, I finally signed up for AIM to try it > out; my id is armax1976. > > later, > Adam > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > SourceForge.net hosts over 70,000 Open Source Projects. > See the people who have HELPED US provide better services: > Click here: http://sourceforge.net/supporters.php > _______________________________________________ > Bibdesk-develop mailing list > Bib...@li... > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop > |
From: Bruce D'A. <bd...@fa...> - 2003-10-18 03:56:14
|
On Wednesday, October 15, 2003, at 10:00 AM, Adam R.Maxwell wrote: > > On Oct 15, 2003, at 08:35, Bruce D'Arcus wrote: >> Beginnings of a bibtex2mods converter is at: >> >> http://www.scripps.edu/~cdputnam/bibutils3 >> > > Is that the bib2xml program? > <http://www.scripps.edu/~cdputnam/software/bibutils.html> has source > code; the ELF binary won't do us any good :). This site looks > interesting, also: <http://www.nongnu.org/bibulus/paper.html>. Too > many fragments of good ideas out there. Update on this: Chris has put up an OS X binary at: http://www.scripps.edu/~cdputnam/bibutils3/bib2xml_osx He's also posted one for his ris2mods converter, if anyone's interested. Bruce |
From: Adam R.M. <ama...@ws...> - 2003-10-16 13:48:43
|
Hi Mike, Can you set the Reply-to so that replies go to the mailing list by default? On Oct 15, 2003, at 19:54, Michael McCracken wrote: > Does anyone have any pending issues with releasing the current code > (plus the accented char loss patch) as .83? Nope. Release early, release often :). James' patch doesn't seem to have caused any problems for me in day-to-day use. > Another thing, since I like this feature so much: I've added "email > this pub" as a feature, but there's an issue to resolve - and I need > input. Use the Service->Send File, I think. It seems to me that any other way would require knowing an SMTP server (or embedding that functionality); between Apple's broken sendmail on 10.2 and earlier, as well as firewalls, it might just cause more problems. Re: your previous note on iChat, I finally signed up for AIM to try it out; my id is armax1976. later, Adam |
From: Alexandre E. <aen...@in...> - 2003-10-16 10:55:53
|
"Send File Service" first and, if time allows, direct send second. I particularly hate the fact that Mail.app only send one file per message but it really seems like the easiest way to implement the functionality. Then those who use Eudora, Entourage, GNUMail, GyazMail, or Mailsmith might want the same feature. Let them implement it... |
From: Michael M. <mic...@ma...> - 2003-10-16 04:46:09
|
Hey, so I think it's time to release a new version, since there have been some good bugfixes since the last serious release. Does anyone have any pending issues with releasing the current code (plus the accented char loss patch) as .83? Another thing, since I like this feature so much: I've added "email this pub" as a feature, but there's an issue to resolve - and I need input. there are two ways to do it : 1: attach it as a text attachment and send directly, requires adding some GUI to set up to & from & subject lines, which will have to be worse than the user's favorite email app's implementation... PROS: can send more than one pub, can add an automatic string to the text CONS: more work, reinventing email header interface 2: pop up a single pub in an email using Mail.app, uses "SEnd file" service, you can try this from Finder now to see what it'd be like. It just attaches the local-url file, and doesn't work with more than one file... PROS: easy, reliable CONS: only for Mail.app, one pub at a time opinions? -mike |