Is there a way to run with --aot-only on the iOS Simulator with Xamarin.iOS? - xamarin.ios

When I test my app directly on the device, it crashes because I'm attempting to JIT-compile a method. I know why these crashes occur, I'm just trying to make them appear when I'm testing on the simulator instead. It's much easier than deploying to a device every time (it also takes less time).
I tried adding --aot-only to the mtouch arguments but I get the "Unknown command line argument" error.

No, there's no AOT compiler shipped for x86.
Now even if there was one it would:
a) become a lot slower to build. In fact it would be similar to building for devices. The only time saved would be for deployment (which is not the largest part of the build/deploy time);
b) still give you different results than iOS devices. The iOS simulator is, in many ways, different than iOS devices so testing on devices is very important.
Notes:
A lot of the JIT exceptions are related to the use of value-types inside generics. This is being, in large part, fixed in the 6.3.x releases (beta);
There are tricks to make your device builds faster. You can find some here in stackoverflow and (soon) the video about my Evolve 2013 presentation should be available.

Related

Android Libspotify Image Loading SIGSEGV

So this particular libspotify error has me a little stumped. My app basically loads a users playlists, and allows users to go into those playlists at which time it populates the track data.
So the problem lies in the function:
sp_image* image = sp_image_create(session, image_id);
(after calling)
const byte* image_id = sp_album_cover(album, SP_IMAGE_SIZE_SMALL);
Now this works fine some of the time, but quite often it will pop up with a 'Corrupt memory passed to dlfree(), SIGSEGV' error, which cause. So first thing I looked for is a memory error but theres plenty of free memory and there are no null pointers when this occurs. The call occurs from with the library to libc.so so its much deeper into the library than i can access.
It obviously has something to do with memory but its odd that it could happen after loading 10 tracks or after 400 tracks and stranger yet, from my testing devices, it only happens on the Nexus 4 and Nexus 7 and not on the Galaxy S3, or HTC sensation. First thing that springs to mind is the fact that the N4 & N7 are Qualcomm devices but thats all i have to go on, and probably has nothing to do with anything!
Any help is much appreciated!
It's probably libspotify's fault, not yours. This library has never been particularly stable on Android (in fact, Spotify still calls it "beta"), however they will be replacing it soon with a new library similar to the Spotify iOS SDK.
My advice to you would be to not use libspotify unless you are under pressure to ship something right away. The new SDK will likely solve many of the headaches familiar to developers working with libspotify on Android.
Edit: The new Spotify Android SDK is out! You should use it instead of libspotify, it will save you much headache.

Monodroid GC and Sensors

I recently started deploying my test code onto an actual device and ran some sample code provided by Xamarin involving different technologies that they introduce you to. Then I came upon an issue with their garbage collector when trying to test out sensors. With the latest version it runs when you reach a certain threshold however that makes the device unresponsive. Using the code from http://docs.xamarin.com/android/recipes/OS%2f%2fDevice_Resources/Accelerometer/Get_Accelerometer_Readings but just changing it to add 2 more sensors, a gyroscope and gravity sensors, the project lasts about 30 seconds before the GC begins to run. I noticed that every time you reference the e.Values list from the OnSensorChanged function you get more references created. Is there a way to delete those references, as the app I'm working on requires those three sensors and needs to run for about 4 to 5 mins, (its just a section of the app but a really important section). Thanks in advance for any help you can give me.
The following link actually provides a way to understand that issue comes up as well as the solution that would fix the issue completely.
https://bugzilla.xamarin.com/show_bug.cgi?id=1084#c6

Communicate with a NES game running in an emulator

I am thinking of creating an arcade machine for fun. Something like this one. I wonder if it's possible to get events from some game, e.g.Super Mario. Assume I finish a level and I want to get that event, with the score and some other data and perform some actions with that data. I am thinking of running the emulator in Windows. Did anybody work on something like this? Are there not too difficult ways to get events and data from old NES games? May be I should run not Windows, but some Linux for that? Well, please share your thoughts about how to do the software part of it.
Modern emulators such as FCEUX make it possible to interact with the running ROM through Lua scripts (see example video). Using this API you could write a Lua script to:
monitor a certain memory location
wait for it to hold some special value (such as level_just_finished)
read out the current score from memory
do something with the score
In order to know which memory locations to check, you will either need to disassemble the ROM or run it through a debugger, or both. As for Super Mario Bros, there's already a commented disassembly available. The FCEUX emulator also has a built-in debugger/disassembler that you can use.
All of this takes a lot of effort and you would need to know Lua, 6502 assembly, and the inner workings of an NES. For your arcade machine, you might be better off just using an emulator such as UberNES, which automatically can track your highscore for many popular titles.
Class NES games don't have standard hooks for achievement reporting. The only options I can think of are the following:
Rebuild the ROMs in question, with your own hooks (which a custom emulator could handle).
Watch the ROM memory footprint directly, and parse the state continually, triggering when you observe some known state.
Both options require that you really understand the internals of a NES ROM.
IRQ...Go for Interrupt_requests..they triger a interrupt...I have read / and seen the code about it somewhere...even x86 also uses IRQs for communciation with various device a simple exmaple:keyboard when a key is pressed a call is made ti PIC and an IRQ is generated and system knows which key is pressed and the same mech is used in NES

Reloading Flash 17 times causes error #2046 and requires a browser restart

I am encountering some very strange behaviour with a Flex 4.1 app I am writing which gets in the way of testing. It seems that I can reload the app 16 times and then on the 17th, the loading process fails with
Error #2046: The loaded file did not have a valid signature
It seems to be consistently happening on the 17th reload on both Firefox 5.0 and Chrome 12. I am not sure if it's relevant, but I am running Flash Player v10.2.159.1 (also happens with 10.3.181.34) on Ubuntu 10.04. Happens with both regular and debugger versions of the player. When I run the app on Windows FF5, it doesn't seem to happen. Closing the current browser window does not seem to fix it. The only way around it is to completely close all browser windows and restart the browser. And then again after 16 successful loads, the 17th fails.
At this point I'm thinking of chalking it as a Linux Flash bug but I'd like to make sure and check if anyone knows if there's something I should be doing to prevent this.
The user from this post seems to have had the same problem but I guess he didn't notice the pattern I have.
Any help will be greatly appreciated.
Ruy
== UPDATE ==
I just realized that after my app starts throwing the 2046 error, trying to load any other Flash that uses signed RSLs also shows the 2046 error (e.g. this app), which means the problem is not specific to my app and most likely related to the Flash cache or something of the sort.
Disclosure: I am a Flash Player Developer at Adobe.
This is unlikely to get much attention as it is Linux only and kind of an edge case: Probably annoying during dev work but very few users will reload the same page more than 16 times. It might also be a browser issue. But it is probably us :) I will look at the jira tomorrow and see if I can bump it up a bit, but I'll be honest in that it is really an edge case and unlikely to get much love. If you want to increase your chances make sure to add the most simple .swf test case you can make to the bug. Also please double check if it still happens with the latest beta.
I also just took a look at the earlier bug reports and forum posts, you probably should post this as a Flash Player bug, not as Flex.
Long shot guess, but it sounds similar to a problem we had.... in the project properties - Flex Build Path - Framework Linkage - change to "merged into code". This fixes a problem very similar to what you are describing, though I wish I knew exactly what the cause is. Good luck!
tl;dr: No idea on the cause, posting random possibility in hope it might give someone else an idea or two for testing.
Considering that it seems to be an unresolved bug in Adobe issue tracker, its unlikely that you will get any definitive answer here. Considering it occurs on both Firefox & Chrome, let's rule out browser bugs and assume it is in either some common library (Flash) or OS API (Linux kernel implementation). A comment in one of the jira issues specifically mentions killing Flash process fixes it, so its a Flash issue and not OS bug.
The most interesting thing I can see here is your observation that it succeeds for exactly 16 times before failing to load. Time for some speculation here, from someone who's never worked on kernel or crypto dev:
With a 2048 bit RSA key and 32k cache for storing them, 16 keys would fit before adding another one fails - so one conjecture is that each time this file is loaded, Flash is caching the signed value (possibly a hashed version) for some reason - maybe to keep track of allowed & used security permissions etc.? If this entry is not removed, then once it is full all file loads will fail if caching the signature is part of checking it.
Things you can experiment with:
Reduce size of app to see if page can be reloaded more often (as suggested by stackfish)
Count number of signed RSLs used and if its a power/multiple of 2 (maybe others get the error after 32 page loads if they use half the no. of signed libs?)
Check if Linux Flash plugin has some option to increase credentials cache or something (or decrease it, just to see if it impacts the no. of loads - if so, could be related to the problem)
I expect that to actually find a solution, you'd have to dive into the library loading code and look at all constants related to loading signed libs that are 4, 16, or a multiple of 16 to see if they might be responsible - in short, unlikely to be soluble by others outside of Flash dev team imho :/
This behavior could be related to a memory leak caused either by the Flex implementation, or the browser plugin. Firefox is notorious for not cleaning up memory anyway and the footprint will continue to grow the longer you have the same browser window open.
If you reduce the size of your flex app to produce something very tiny, does the number of times you can reload the page go up?
Error #2046 on win vista, 64 bit machine wit 1000 mb ati radeon videocard
problem occurs only in msn video sofar
I meet a same problem when I use ppt on icourse163.org . when I open the course site, I can't see the ppt but I use chrome can do it .there are the same flash version(32.0.0.344),and Then ,I copy the tar.gz file that downloaded from adobe.
usr/* to /usr.I solved it.wish can help you .

Pocket PC 2003 C# Performance Issues...Should I Thread It?

Environment
Windows XP SP3 x32
Visual Studio 2005 Standard Edition
Honeywell Dolphin 9500 Pocket PC/Windows Mobile 2003 Platform
Using the provided Honeywell Dolphin 9500 VS2005 SDK
.NET Framework 1.1 and .NET Compact Framework 1.0 SP3
Using VC#
Problem
When I save an image from the built in camera and Honeywell SDK ImageControl to the device's storage card or internal memory, it takes 6 - 7 seconds.
I am currently saving the image as a PNG but have the option of a BMP or JPG as well.
Relevant lines in the code: 144-184 and 222, specifically 162,163 and 222.
Goal
I would like to reduce that time down to something like 2 or 3 seconds, and even less if possible.
As a secondary goal, I am looking for a profiling suite for Pocket PC 2003 devices specifically supporting the .NET Compact Framework Version 1.0. Ideally free but an unfettered short tutorial would work as well.
Things I Have Tried
I looked into asynchronous I/O via System.Threading a little bit but I do not have the experience to know whether this is a good idea, nor exactly how to implement threading for a single operation.
With threading implemented as it is in the code below, there seems to be a trivial speed increase of maybe a second or less. However, something on the next Form requires the image, possibly in the act of being saved, and I do not know how to mitigate the wait or handle that scenario at all, really.
EDIT: Changing the save format from PNG to BMP or JPG, with the threading, seems to reduce the save time considerably..
Code
http://friendpaste.com/3J1d5acHO3lTlDNTz7LQzB
Let me know if the code should just be posted here in code tags. It is a little long (~226 lines) so I went ahead and friendpasted it as that seemed to be acceptable in my last post.
By changing the save format from PNG to BMP and including the Threading code shown in the Code link, I was able to reduce the save time to ~1 second.
You're at the mercy of the Honeywell SDK for this one, since their control is doing the actual saving of the image. Calling this on a separate thread (i.e. not the UI thread) isn't going to help at all (as you've found out), and it will actually make things more difficult for you since you need to wait until the save task is completed before moving on to the next form.
The only suggestion I can make is to make sure you're saving the image to internal memory (and not to the SD card), since writing to an SD card usually takes significantly longer than writing to memory. Or see if you can get technical support from Honeywell - 6-7 seconds seems way too long for a task like this.
Or see if the Honeywell SDK lets you get the image as a byte array (instead of saving to disk). If this call returns in less than 6-7 seconds, you can handle persisting it yourself.

Resources