Hi Jeff, Thanks for looking at the logs you have found what I thought you would, race conditions, of course in the perfect world we would have perfect performance so that some of these did not occur, but as with all things programming, if it can go wrong it is only a matter of time before it does.
Get me a link to the build and I will have a good go with it, I will still consider the move up to better hardware but in the short term that is not going to happen and it gives us an opportunity to resolve some of these types of issues, what I will do is clear down my Xcode logs once installed then give it a hammering over the next couple of days. Whilst this has been frustrating to say the least, I am really happy with the support I am getting and I am sure we will get to the bottom of things. ATB Alex On 28 Sep 2012, at 15:20, Jeff Stedfast <[email protected]> wrote: > Hi Alex, > > It's worth investigating. I can make no guarantees that your current hardware > is the cause of the xcode syncing problem, of course, but it's possible. > Upgrading your hardware certainly wouldn't hurt. A year ago when I was doing > a lot of work on the Xcode syncing stuff, I was finding that 4GB of RAM for > running 2 copies of MonoDevelop (debugging MonoDevelop inside MonoDevelop) > and Xcode side-by-side was a bit on the slow side and once I upgraded my RAM, > things ran a lot faster. 8GB of RAM and an SSD should improve things a lot > for you. > > That said, I did find one error in the log files you sent me yesterday > indicating a race condition that caused an NRE during one of the last syncs > in your most recent MonoDevelop session. I'm not 100% sure that it is the > cause of the failure to sync, but it might be. The problem is that I'm not > sure how the race was happening (the only way I can see how it could have > happened is if our AppleSdkSettings object emitted a Changed event mid-sync, > but I'm not sure how that could happen). That was the only code-path that > didn't do the proper locking before modifying some internal state variables > used by the syncing process. I've added the proper locking for an upcoming > MonoDevelop 3.0.4.8 release (I can provide a pre-release download for you as > soon as I get to the office). Maybe you can test it out for a few days and > see if it seems to solve the issue for you. > > Hope that helps, > > Jeff > > On Fri, Sep 28, 2012 at 3:54 AM, Alex White <[email protected]> wrote: > Hi Jeff, > > My issues could come down to the performance of my MacBook it is pretty old a > dual core, 4gb of ram, how much better does monodevelop run on a quad core, I > see my CPU max'ed out for many minutes at a time when compiling is happening, > memory seems to be ok so I am guessing there is not excessive paging of > memory, so it comes down to CPU and a bit of hdd. > > my current MacBook is:- > > Model Name: MacBook Pro > Model Identifier: MacBookPro3,1 > Processor Name: Intel Core 2 Duo > Processor Speed: 2.2 GHz > Number of Processors: 1 > Total Number of Cores: 2 > L2 Cache: 4 MB > Memory: 4 GB > Bus Speed: 800 MHz > > I am contemplating a quad core 15" with a solid state hdd with 8gb of ram, I > need to reduce the compile round trip times significantly if I can, is it > worth investigating this route? > > > ATB > > Alex > > > On 27 Sep 2012, at 17:05, Jeff Stedfast <[email protected]> wrote: > >> Hi Alex, >> >> On Thu, Sep 27, 2012 at 7:24 AM, Alex White <[email protected]> wrote: >> Hi Jeff, >> >> thanks for the reply, >> >> This problems has been occurring on and off for months, but in the last week >> 100% of the Xcode updates are no making their way into MonoDevelop it has >> forced me to recode my project to be xib free, it does not help that this >> happened right in the middle of a load of work with beta testers, but an xib >> free app should be better in the long run. I have had so many crashes that >> always report, some in MonoDevelop and some in Xcode, I have also noted that >> there are times where the sync'ing back to MonoDevelop has crashed both >> MonoDevelop and XCode at the same time, both needing to be forced to quit >> which does not make sense to me as the sync'ing from what I can see is not >> done via processes but file watching if you see my logic. >> >> There's some IPC (via AppleScripting) between MonoDevelop and Xcode as well, >> during the syncing process, so this might explain that. >> >> >> I will in future use Xcode to only prototype screen layouts then creating >> the views programatically. >> >> Not only do I have to create them from scratch but I cannot use the original >> names as this throws up so many errors that I cannot fix, I have so many >> views now with 2's or 3's on the end of them. Also a side issue is renaming >> of objects in Xcode I have never got this to work properly and be reflected >> back in MonoDevelop but that is another issue, but having many objects that >> have the wrong name is not good. >> >> Where are the timeouts?, I will have a play with them if they are available >> to me. >> >> Unfortunately, they are not available for users to tweak (they are currently >> hard-coded in MonoDevelop). MonoDevelop's XcodeSync log file would help me >> figure out if it is related to the timeouts at all, or if it is something >> else. >> >> >> I will do some further testing before I go down the route of logging a bug. >> >> If you can get your hands on the appropriate XcodeSync log file in the >> MonoDevelop log directory, that might be enough. I added some fairly verbose >> debugging WriteLines in MonoDevelop's syncing logic in order to make it >> easier for me to debug these kinds of issues. >> >> You should be able to find them in >> /Users/<name>/Library/Logs/MonoDevelop-3.0/Xcode*.log >> >> Hope that helps, >> >> Jeff > >
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
