I tried the following code which works fine in the Windows CLR:
System.Diagnostics.Process.GetCurrentProcess().Threads.Count
... resulting in something > 0.
However under Mono on OS X or Linux it always results in 0
Is this a bug in Mono or do I need another approach because of platform differences?
Going straight to the source, it appears that it's not exactly a bug, but is instead completely unimplemented (note the [MonoTODO] attribute on this method).
Your best course of action would be to open a bug against Mono on Xamarin's bug tracker. It's probably not terribly hard to build this, and it seems like someone on the project may be ashamed enough that this isn't done that they'll fix it quickly.
If you need this to work in the meanwhile, I've got a branch on github that implements a fix for this. I'll work with the Mono folks to see whether/how they want to integrate it.
Update: It has been pulled into the master branch of Mono.
Related
I work from 2 different machines. One is Windows and the other is Linux. If I alternately work on the same project but switch between both OSes, will I eventually run into compiling errors? I ask because maybe there are standards supported by one but not by the other.
That question is a pretty broad one and it depends, strictly speaking, on your tool chain. If you were to use the same tool chain (e.g. GCC/MinGW or Clang), you'd be minimizing the chance for this class of errors. If you were to use Visual Studio on Windows and GCC or Clang on the Linux side, you'd run into more issues alone because some of the headers differ. So once your program leaves the realm of strict ANSI C (C89) you'll be on your own.
However, if you aren't careful you may run into a lot of other more profane errors, such as the compiler on Linux choking on the line endings if you didn't tell your editor on the Windows side to use these.
Ah, and also keep in mind that if you want to actually cross-compile, GCC may be the best choice and therefore the first part I mentioned in my answer becomes a moot point. GCC is a proven choice on both ends. And given your question it's unlikely that you are trying to write something like a kernel mode driver - which would be fundamentally different.
That may be only if your application use some specific API.
It is entirely possible to write code that works on both platforms, with no issues to compile the code. It is, however, not without some difficulties. Compilers allow you to use non-standard features in the compiler, and it's often hard to do more fancy user interfaces (even if it's still just text) because as soon as you start wanting to do more than "read a line of text as it is entered in a shell", it's into "non-standard" land.
If you do find yourself needing to do more than what the standard C library can do, make sure you isolate those parts of the code into a separate file (or a couple of files, one for Linux/Unix style systems and one for Windows systems).
Using the same compiler (gcc) would help avoiding problems with "compiler B doesn't compile code that works fine in compiler A".
But it's far from an absolute necessity - just make sure you compile the code on both platforms and with all of your "suppoerted" compilers often enough that you haven't dug a very deep hole that is hard to get out of before you discover that "it's not working on the other system". It certainly helps if you have (at least) a virtual machine running the other OS, so you can easily try both variants.
Ideally, you want to set up an automated system, such that when you change the code [and feel that the changes are "complete"], it automatically gets built on both platforms and all compilers you want to use. And if possible, also automatically tested!
I would also seriously consider using version control - that way, when something breaks on one or the other side, you can go back and look at what the code looked like before it stopped working, and (hopefully) find the reason it broke much quicker than "Hmm, I think it's the change I made to foo.c, lets take that out... No, not that one, ok how about the change here..." - at least with version control, you can say "Ok, so version 1234 doesn't work, let's try version 1220 - ok, that works. Now try 1228, still works - so change between 1229 and 1234 - try 1232, ah, it's broken..." No editing files and you can still go to any other version you like with very little difficulty. I have used Mercurial quite a bit, git a little bit, some subversion, and worked on a project in Perforce for a few years. All of these are good - personally, I think I prefer mercurial.
As a side-effect: Most version control systems also deal with filename and line endings in the saner way than doing this manually.
If you combine your version control system with a "automated build and test-system", such as Jenkins, you can get everything very automated. Jenkins is free and runs on both Windows and Linux, and you can use it to automatically build and test your code as and when you submit the code to the version control system.
It will not create a problem until you recompile the source code in the respective OS. If you wanna run your compiled file generated by windows(.exe or .obj), into linux or vice-versa then it will definitely create a problem and wont be possible. But you can move you source code (file with extension .c/.c++) into any of the os. And sometimes it also create problems with different header files, so take care of that also. Best practice is to use single OS for you entire project, avoid multiple os until it is extremely necessary.
I have updated my development system to the new MonoTouch (6.0.1) and now whenever I'm referencing zxing.Monotouch types I get MissingMethodException on the constructor.
System.MissingMethodException: Method not found: 'MyClass..ctor'.
It's been 3 days now...
Anyone got any idea? I'm even willing to give up zxing if that what it takes (even though it's a wonderful library).
Edit
When I include zxing.Monotouch in the solution and reference it as a project the problem does not reproduce. If that's a clue I've missed it...
It's likely that the binary version of zxing.Monotouch is trying to access something that does not exists in 6.0.1. That's uncommon as we try to maintain source/binary compatibility unless the code is really broken (e.g. it would cause a crash anyway). I cannot be more precise without more data (e.g. a full build log).
If you include zxing.Monotouch as a reference then it will be rebuilt. If it works then it really looks like source compatibility was preserved (but not binary compatibility).
Whenever you have the source code available I encourage you to use .csproj (not .dll) references. Is has a few advantages, including the source/binary compatibility (above) and the fact that it makes things easier to debug from your project.
I read a lot about how MT works, that it binds to the iOS's API, that it uses AOT compiling, that there is no .NET runtime on the iPhone and so on.
Geoff once wrote this in an answer to one of my questions, which shows how to bind an ObjC selector:
var url = new NSUrl ("http://www.google.com/");
var str = (NSString) Runtime.GetNSObject (Messaging.IntPtr_objc_msgSend_IntPtr (Class.GetHandle ("NSString"), Selector.GetHandle ("stringWithContentsOfURL:"), url.Handle));
But what is happening under the hood if I do this? And does that mean if I use a call that is already bound, it will execute something similar like the code above in the background, hiding it from me? Does it mean that everytime some Selector.GetHandle() and Runtime.GetNSObject() is executed?
How has the whole MT project been started? At some point the team must have been there thinking, "we have ObjC here and Mono there - how can we combine them?" I mean, what was the first thing that was done, tried?
And one last thing about the garbage collector: I assume it has to run in a separate thread - but is it really ONE thred? Or are there several? How does the GC collector decide that it is time to clean up?
Alot of what MonoTouch does is exactly what Mono does on other operating systems.
They started with a subset of the .Net BCL: Silverlight, and also bound the Objective-C apis on the iPhone. They also probably created the AOT compiling option, as I would assume this is the first situation that needed it. Apple required (or strongly preferred) that no one would abstract, or put a layer on top of their APIs. So far MonoTouch, is the only framework that has succesfully done this to bring a new language to the iPhone.
To read some of the more interesting details, check there documentation here. When I first started working with MonoTouch, I read every bullet point under the Documentation heading, as all were pretty interesting and in-depth.
Another resource that you might get more answers than stackoverflow is at their IRC chat. Here is a link to a web-based version, if you don't want to mess with IRC.
Been searching for a good coverage tool for a while now.
I'm with VC++ 2008.
Tried already:
NCover, PureCoverage, PartCover and a few others I can't remember their names.
None works!
Not even with a very basic console application that does almost nothing.
Tried to get an evaluation copy from BullsEye and few more others - not only that they require you to ask for it (no automatic process), they don't even answer after you request AND after you ask what's going on, through the support mail.
So the question is: Is there any tool, which I can immediately download an evaluation for it, that actually works on VC 2008 projects? Something that will get me going within 10 minutes? It's funny but it seems to be a very non-trivial request in the area of this kind of software.
Well, you have to ask for it... but it does work:
SD C++ Test Coverage
EDIT May 2011: Downloads available for since late 2010.
So my company uses a delightfully buggy program called Rational Purify (as a plugin to Microsoft Visual Developer Studio) to manage memory leaks. The program is deigned to let you click on a memory leak after you have encountered it, and then jump to the line that the leak occurs on.
Unfortunately Purify is malfunctioning and Purify will not jump to the place that the leak occurred it only mentions the class and method that the leak occurs in. Unfortunately, sometimes this is about as useful as hiring a guide to help you hunt bears and having him point to the forest and tell you there are bears there.
Does anyone with Purify experience have any idea how I might fix this problem or have a good manual to look though?
Generally you have two options, one exclude modules DLL's from instrumentation in Purify, it helps some times. Second is get BoundsChecker, this does compile time instrumentation much slower but the level of detail is an order of magnitude better.
We generally use Purify on check-in, sanity checking, and BoundsChecker when we know a bug/crash exists.
BoundsChecker has some nice features like only instrument files A.cpp & B.cpp, excluding all the rest.
Be aware neither of these two applications function on 64 bit operating systems, and BoundsChecker will not install on 64 bit OS. Most frustrating if you make the switch to native 64 bit development with 32 bit back port!
Purify is like a swiss knife. If you know how to use it, you will get some results, not the best but still results. If you don't, it will crash, because it is just another program running on Windows.
In the end you will need a lot of patience, rebuilds and a bit of luck.
Purify comes with a script called ScanVSSolutionForPurifyPlus.pl which will ensure that your project files have all the right settings for Purify to work properly. If you haven't run it, give it a go.
(I've personally used ScanVSSolutionForPurifyPlus.pl on a large solution, and it worked like a charm. One caveat: when you give it the name of your .sln file, you might need to give it the full pathname.)
Are you sure you have debug build? Or rather you have all PDB's enabled? Try WindDbg on your executable and check with !lmi command what is visible.
Is whole code properly instrumented?
Also consider using something else like free Visual Leak Detector or Microsoft's tool LeakDiag.
I used Purify about 5 years ago. It was really flaky then. They kept promising to fix all the bugs in the 'next release'. We gave up on it in the end. One can only wonder if they used their own QA tools on their products. Oh the irony...