From: Charles S. <bas...@ch...> - 2012-07-05 03:47:08
|
The problem, as it were, actually lies with the original source file — it uses CRLF line endings. There are a couple of reasons we shouldn’t be doing that: 1. This isn’t a Windows source file — it’s Mac/Unix, and it should be using LF line endings, not CRLF. 2. CRLF line endings make ‘git apply’ light up like a Christmas tree — git seems to consider CRLF to be an error, and when it’s spewing a whitespace error for every single line in the entire file, the signal/noise ratio makes it effectively impossible to properly check the patch for legitimate errors. Is there any particular reason this file is using CRLF? Charles On Jul 4, 2012, at 8:38 PM, Alexei Svitkine wrote: > There seems to be a problem with your patch - it's deleting all lines in clip_macosx64.mm and re-adding them - even when the lines didn't change (like the comment at the top of the file). Perhaps an issue with different line-break characters? > > Please send a patch that doesn't do that... > > -Alexei > > On Wed, Jul 4, 2012 at 9:35 PM, Alexei Svitkine <ale...@gm...> wrote: > Cool! > > Changing clip_macosx64.mm to require 10.6+ is fine as long as we abandon the idea to eventually having 32-bit use that code too (since we want to keep supporting Tiger and friends). Which I'm okay with, but it does mean that the two implementations may diverge in the features they support. > > -Alexei > > > On Wed, Jul 4, 2012 at 8:53 PM, Robert Munafo <mr...@gm...> wrote: > On 7/4/12, Charles Srstka <bas...@ch...> wrote: > > On Jul 4, 2012, at 5:21 PM, Robert Munafo wrote: > >> Isn't this change going to affect 32-bit builds? You do not mention > >> doing any test for 32-bit at compile time, and you'd need to do that. > > > > Right now, there are two versions of the clipboard code — one source file > > that gets included for 32-bit builds, and one that gets included for 64-bit > > builds. All the changes in that patch were to the 64-bit source file only, > > and thus shouldn’t have any effect one way or another on 32-bit builds, so > > really the only thing that should break is trying to run the 64-bit version > > on Leopard (does anyone actually try to do that?). > > Oh, okay, great! I think it's totally okay for users of old OS's like > Tiger to be using the 32-bit version of SheepShaver. (I did > benchmarks, and there is less than a 1% difference in speed.) Leopard > is kinda old by today's standards too, and I think most Leopard users > would go to Snow Leopard. But Tiger to Leopard is a bigger leap, > because more stuff got moved or changed. > > -- > Robert Munafo -- mrob.com > Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 - > mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |