What would be the best way to implement crash reporting in a cross-platform app in c++ (windows, mac, linux)? Looked into google breakpad, but spent a few weeks trying to make socorro (UI) work to no avail.
edit: #Nim to clear up, I want to send a stack-trace to my server when some exception occurs.
When we went crossplatform (from being previously Windows-only), we spent a lot of time researching the possible tools for exactly this. Google Breakpad really is the best crossplatform solution out there.
Your problem is Socorro, which is huge, obfuscated, and confusing. I can suggest two routes:
Drop the current version of Socorro, which is way too much in love with newfangled OSS toys like Hadoop, and roll back to Socorro 1.x. You'll need to do a bit more work to set up your processors, and your dumps will go into a Postgres table, but you'll have way fewer moving parts and crazy infrastructure to deal with.
Forget about Socorro altogether and write your own processors for the Breakpad dumps and a UI to view them with. Breakpad has already done the really hard work -- parsing the symbols and catching the exceptions -- so all you need to write is a collector that the dumps can get uploaded to, a farm to run the Breakpad processors on them, someplace to store the processed results, and something to view them.
Knowing what we do now, we would have probably gone with the second option rather than trying to integrate Socorro — the amount of time it's taken us to find a version of Socorro that works for us and adapt it to our workflow has already exceeded what it would have taken for us to just write a system that does exactly what we want.
I doubt there is a reliable one except google-breakpad as win/mac/linux all-in-one solution. Your best bet would be to use a cross-platform logging library and handle SEH exceptions and use windbg if you need minidumps (here is some good resources on that: http://www.debuginfo.com/articles.html)
Related
I'm looking for some advice and insight on how people approach creating Object-level GUI automation. Technically the type of functionality I am trying to achieve is easily described by Squish software. I want to be able to simulate Key-Press and Mouse Click events without relying on Platform-specific pixel displays, and screen sizes. I've tried to use tools like Sikuli, but unfortunately my application varies too from platform to platform to make reliably re-repeatable tests.
Basically what I am looking for is some advice as to where to look at how 3rd Part (EXTERNAL) programs hook into properties of QT Widgets and other objects. I know a long time ago there was something call QtObjectInspector, but this software required you making Source-Level changes to your Qt code to be compatible on top of being unavailable.
If companies like Squish can do it, how are they doing it? Where do you start? I doubt they are looking at very low level memory interactions, sniffing for "Traffic" that looks like QT on each different system, but I may be wrong.
I'm sorry for such a vague question, but I've been researching for over a day and all I can find now is articles about how amazing Squish is.
Thanks!
EDIT:
I looked into QtTestLib, however this doesn't have the "From the outside" kind of access that I am looking for.
I'm looking to create a "driver" I guess for a custom file system on physical disk for Windows. I don't exactly know the best way to explain it, but the device already has proper drivers and everything like that for Windows to communicate with it, but what I want to happen is for the user to be able to plug the device in to their PC, have it show up in My Computer, and give them full support for browsing the device.
I realize it's probably a little scary thinking about someone who doesn't know the basics of doing something like this even asking the question, but I already have classes and everything constructed for reading it within my own app... I just want everything to be more centralized and without more work from the end user. Does anyone have a good guide for creating a project like this?
The closest thing I know of to what I understand from your description is an installable file system, like the Ext2 installable file system that allows Windows computers to work with
Linux originating ext2 (and to a certain degree ext3) filesystems.
Maybe that can serve as a starting point for your investigations.
As an alternative approach there's the Shell extension which is a lot less complicated than the IFS. The now-defunct GMail shell extension used that approach, and even though it's become nonfunctional due to changes in GMail, it can still serve as inspiration.
Your options are:
Create a kernel mode file system driver. 9-12 months of work for experienced developer.
Use a framework and do everything in user mode. A couple of weeks of work to get the prototype working. The only drawback of this approach is that it's slower, than kernel-mode driver. You can play with Dokan mentioned above, or you can use our Callback File System for commercial-grade development.
I think you need to look through the Windows Driver Kit documentation (and related subjects) to figure out exactly what you're looking to create.
If you're intending to rely on the drivers that already exist, i.e. you don't need to actually execute your code in kernel land to communicate with it, I would recommend you take a look at FUSE for windows Dokan
If you indeed need to run in kernel space, and communicate directly with the hardware, you probably want to download windows DDK (driver development kit). Keep in mind that drivers for communicating with a block device and filesystems are separated, and it sound like you're talking about the filesystem itself. I believe that anything you run in kernel space will not have access to the c++ runtime, which means you can only use a subset of c++ for kernel drivers.
So I understand that there are a few options available as far as parsing straight XML goes: NSXMLParser, TouchXML from TouchCode, etc. That's all fine, and seems to work fine for me.
The real problem here is that there are dozens of small variations in RSS feeds (and Atom feeds too), so supporting all possible permutations of feeds available out on the Internet gets very difficult to manage. I searched around for a library that would handle all of these low-level details for me, but came out without anything.
Since one could link to an external C/C++ library in Objective-C, I was wondering if there is a library out there that would be best suited for this task? Someone must have already created something like this, it's just difficult to find the "right" option from the thousands of results in Google.
Anyway, what's the best way to parse RSS/Atom feeds in an iPhone application?
I've just released an open source RSS/Atom Parser for iPhone and hopefully it might be of some use.
I'd love to hear your thoughts on it too!
"Best" is relative. The best performance you'll need to go the SAX route and implement the handlers. I don't know of anything out there open source available (start a google code project and release it for the rest of us to use!)
Whatever you do, it's probably a really bad idea to try and load the whole XML file into memory and act on it like a DOM. Chances are you'll get feeds that are much larger than you can handle on the device leading to frequent memory warnings and crashes.
I'm currently trying out the MWFeedParser #Michael Waterfall is developing.
Quite easy to set up and use (I'm a beginner iPhone developer).
His sample code for using MWFeedParser to populate a UITableViewController implementation is helpful as well.
take a look at apple's XML Performance sample -- which points to using libXML directly -- for performance and quicker updates to the display. Which may be important if you are working with very large feeds.
Check out my library for parsing Atom feeds, (BSAtomParser) at GitHub. It doesn't care about validating the feed, it does its best at returning whatever is valid. The parser covers most of RFC 4287, even extensions.
Here's my solution: a really simple yet powerful RSS parsing library: https://github.com/H2CO3/RSSKit
Have you looked at TouchCode yet? I don't think it has an RSS processor, but it might give you a start.
http://code.google.com/p/touchcode/
I came accross igasus project on sourceforge today. I haven't used it or really checked it, but perhaps it might help.
From their site:
igagus is a web service for the iPhone that allows aggregation of RSS to be delivered in an iPhone friendly format.
Actually, I was trying to suggest you ask on the TouchCode discussion board, because I remember someone was trying to expand it to support RSS. That might be a decent starting point. But I was being rushed by my wife.
But I see now that TouchCode doesn't have a discussion board. I'd still ask the author, though, he might know what came of that effort.
This might be a reasonable starting point for you. Atom support isn't there yet, but you could help out?
I have a significant codebase written in MFC and am tasked with creating a port for Mac OS X. I know that I'm going to have to roll up my sleeves at some point and do alot of grunt work to get everything working correctly, but are there any tools out there that might get me partway?
I'm working on one.
From the GUI point of view, the new version of AppMaker is based around an import/generate model. Most of commercial work I've done with AppMaker has been the other way, porting Macintosh applications to Windows. However, there's no reason why the same principles can't be applied in reverse.
AppMaker v2 had a very good importer for PowerPlant UI resources and traditional Mac dialogs. As it is only able to run on Classic, that code base has been discarded (you really don't want to know) and the final generator languge I wrote for AppMaker v2 is an XML exporter which dumps the entire object model to an extended XAML.
I already have a XAML UI generator and am currently working on a Cocoa xib generator - one of the reasons for going to WWDC in June. The focus at this time is on import/generator suites before returning my attention to a GUI editor.
I wrote PP2MFC to allow PowerPlant applications to be compiled for Windows - a cross-platform solution needed because no other framework or cross-platform tool at the time (1997) would perform well enough for the hardware requirements. I've since discussed an opposite program with someone I could chase up and I'm sure an MFC portability layer could be created to map to Cocoa objects. Whilst many developers have a poor opinion of MFC's message-map architecture, the heavily macro-based API sits on top of a reasonably clean OO framework.
This is the kind of project where you need to think about long-term maintainability - do you want something which ends up as large chunks of MFC code working with Cocoa or do you want to migrate to an idiomatic Cocoa program.
Any further discussion should probably be taken off SO - contact me at dent at oofile.com.au but I'm happy to debate technicalities and feasibility on here. The combination of code generation and skinny framework adaptor layers works better than most people expect.
Honestly, the models are so different that I suspect you're going to need to do a nearly complete re-code at least of most of the UI parts.
No, Such a tool would be pretty much impossible to write.
MFC and Cocoa are such fundamentally different platforms there is no easy way to convert between the two.
Depending on how you've written your applications, you will either need to write the GUI portion of your code or even the whole codebase.
This project started as a development platform because i wanted to be able to write games for mobile devices, but also being able to run and debug the code on my desktop machine too (ie, the EPOC device emulator was so bad): the platforms it currently supports are:
Window-desktop
WinCE
Symbian
iPhone
The architecture it's quite complete with 16bit 565 video framebuffer, blitters, basic raster ops, software pixel shaders, audio mixer with shaders (dsp fx), basic input, a simple virtual file system... although this thing is at it's first write and so there are places where some refactoring would be needed.
Everything has been abstracted away and the guiding principle are:
mostly clean code, as if it was a book to just be read
object-orientation, without sacrifying performances
mobile centric
The idea was to open source it, but without being able to manage it, i doubt the software itself would benefit from this move.. Nevertheless, i myself have learned a lot from unmaintained projects.
So, thanking you in advance for reading all this... really, what would you do?
Throw it up on an open source website and attach a bunch of good keywords to help search engines find it. If someone's looking for it, they'll find it and be able to use it.
I would say that you should open source it.
If you do have the time, it may be helpful for other programmers who are interested in the project to know the status of the project, and what is next to do on the project. Writing a to do list may be helpful, or writing comments in the code may also help.
If you do not have the time to write up a to do list maybe somebody is willing to take the initiative on the project, find out what needs to be done.
Look at it a different way. The worst that can happen is that your work will go unnoticed, and your efforts will be lost. The best that can happen is that you will be recognized for having the foresight to start such a great project, and open sourcing it.
http://sourceforge.net
This allows you to set up as admin and manage the project.
Of course if somebody does not agree with you they can fork the project and start their own version but that's open source for you.
If you've put time and effort into it, don't let it die a quiet death. Instead share it under the license of your choice on a collaborative site. At the worst, you get nothing in return. At the best, other people like the idea and provide constructive feedback or code. Even better is if you get some time in the future to pick it back up.
Couple of good sites to post it on
codeplex
sorceforge
Definitely, you should open source it, just make the same considerations you made on this question on a place that anybody can see...
Maybe someone will pick it up, or just learn from it
Put it up on github so we can all check it out.