I use Core Data in my application, and discovered some odd behavior of the simulator: When I add some data to Core Data in my app and quits the simulator using the "stop" button in XCode (or just press Cmd-Q) immediately, the data is not stored in the database the next time I start the simulator. After some testing, I found out, that the data is stored to disk:
immediately if I press the home button. (Almost - it is possible to quit the application before data is stored if quitting very fast.)
If I let the application run for some time (at least about 20 seconds) after adding data.
It does not help to call [NSManagedObjectContext save:]. The behavior is the same.
So my question is: What is the reason for this kind of behavior? Are there any way to force flushing to disk before quitting? And are there any risk that I can loose data this way when running on a device (personally, I do not see any, except a force close, but the odd behavior bothers me a bit)
Stopping the simulator with the stop button in Xcode is probably the same as smashing your iPhone with a hammer (but preserving the SSD). Basically, your app and everything else just stops. There's no reasonable way to ensure that data is saved when that happens.
You're probably using nested context's. If your context has a parent context, calling -save: will just save to that context, not to the file system.
Nested context are (usually) used to safely use a context on a background queue, and allowing a foreground context to save without having to incur the overhead of saving to the file system. The save to the file system will happen on a background queue and not block the main thread.
I too have been wrestling with this for a very long time and Daniel Eggert's answer under (2) above is the first - and only - useful answer I have found on the internet. I presume JRV is using the NSManagedDocumentContext from a UIManagedDocument. If this is the case then Apple's 'default' saving method is incomplete! Having adopted Daniel Eggert's solution my data is now preserving perfectly and is also immune to a simulator 'STOP' gesture. I recommend Daniel Eggert's answer under (2) above to anyone else wishing to write resilient code in this case.
Related
Unfortunately after swearing to never use the hunk of garbage that is Dreamweaver again, after 7 years - I found a need for some WYSIWYG editing and installed the complete hunk of garbage software on my machine.
I simply knew there would be some disaster awaiting, so I was being really meticulous about backing up.
But I got caught not backing up for about 4 hours, and lost those 4 hours of work to yet another of the endless array of bugs that will completely destroy your work when using Dreamweaver.
I was using CTRLZ multiple times when suddenly the code went all weird and blocks of code went missing, and it looks like sections were just cut in mid line - and it just went from ugly to uglier. I recognized this nightmare form 7 years ago - the exact same reason why I stopped using this garbage software to begin with and swore to never use again. Right now I am wishing I kept my promise to myself.
So I was really careful not to save the document, but the fun thing is - every time I hit CTRLZ - Dreamweaver is "conveniently" saving the file to the server.
I do want live updates as I hit "Save" or CTRLS, but I DO NOT want anything saved when I hit CTRLZ!
So knowing that I want to use CTRLZ, and knowing Dreamweaver is complete garbage and will crash and kill my code.
How do I turn off automatic saving when I hit CTRLZ?
As a secondary question - how about how do I prevent losing my code again with this hunk of garbage software?
You probably have auto-save AND auto-sync turned on together, and auto-save might have ran shortly after you undid changes, following which the file was uploaded to the server by auto-sync.
Simply switch off auto-save so that only a manual save will trigger an upload.
Also another option that may accidentally revert your changes is the Auto Recovery feature, that reverts your file to an incorrect state when Dreamweaver crashes (or encounters a bug). If auto-sync is switched on as well, that may cause a corrupt file to be uploaded.
Simply switch off Auto Recovery so that no corrupt files will be uploaded.
I'm using a Pharo 6.1 image to do some CSV file processing. Sometimes my image just becomes unresponsive — I have to terminate the Pharo VM from Task Manager.
Is it necessary to use somethings like:
ensure:[toStream close]
ensure:[fromStream close]
What's a simple but reliable approach to reading and especially writing files with Pharo?
The image is not really unresponsive but the UI thread for sure is when you do a long operation like reading a big CSV file.
The best would be to for a process for doing it.
Like in:
[ target doSomeLongThing ] fork.
You can view the process in the process browser from the world menu and terminate it there.
Now that is not really something one will think about when trying things out interactively in a playground.
What I do to alleviate this situation is twofold:
Put these things in a test. Why? Because tests have a maximum duration and if things are stuck, they will come back with a time exceeded notification from the test.
Start the Zinc REPL on a port, so that I can access the system from a web browser if the UI thread is kind of stuck and restart the UI thread.
I wish the interrupt key would work in all cases but well, it doesn't and is a solid annoyance.
I am of the opinion that images should be considered as discardable artifacts and CI job should be building them regularly (like daily) so that we have some recovery path.
This is not really cool as yes, using an image and being able to come back to it without having to rebuild stuff all the time when doing explorations shouldn't frustrate us with UI thread blockages. I hate that. I have an image that is stuck on restart from some Glamour problem, it is infuriating as it cannot be debugged or anything.
You can also use:
(FileLocation imageDirectory / 'somefile.csv') asFileReference readStreamDo: [ :stream |
"do something with the stream" ].
This will do the ensure: bit for you. Cleaner. Easier.
For CSV, also give a shot to NeoCSV as it will do the file handling for you as well.
HTH
I'm having a strange issue with my application for Mac OS X. I have a process that runs in a secondary thread. The process repeats a certain action a user-specified number of times in a for loop.
With each iteration of the for loop, there is a string that is initialized with the contents of a strings file. If the content of the strings file equals "YES" then the loop breaks (the file is set to "NO" by default). When the user wants to stop the loop, they hit the "Stop" button which sets the contents of the file to "YES".
This actually works great when I run the application in Xcode and when I export the application as a .app. The problem occurs when I actually turn the application into a pkg and install it. The stop function no longer operates correctly. I'm pretty stumped as to what the issue is. I'm initializing all my references to my file using [NSBundle mainBundle] so I should be referencing the file in my application bundle.
EDIT: I actually decided to switch to checking an atomic BOOL value within the loop that I change when the stop button is pressed. This seems to be a simpler solution for me.
Regular users do not have permission to modify applications installed in the /Application folder for very good security reasons. Also, signed apps (ie, any app sold through the App Store) cannot be modified without invalidating your signed code.
Never, ever, ever rely on the application bundle being modifiable. It's never supposed to be. Always use standard user data folders like "~/Library/Application Support/" or "~/Library/Caches/" for app-related, non-document files.
As to your general approach, repeatedly polling a file - especially in a tight loop - is a lot of disk activity. "Laptop Killah" would be a good name for the app. :-) You should consider changing this approach altogether. If you provide more detail in another question (what you're doing and why) and ask for suggestions, I'm almost positive there'll be a number of better ways that don't chew through your users' battery charge like crack-addled rats in a grocery store.
Also, I'm guessing you never check to see if your file is written successfully. The standard -writeToURL/File:... methods return a BOOL to signal success or failure as well as set an NSError (if you pass a pointer to one) with further details. Get into the habit of not ignoring this. In this case, you might've found your own answer because you'd have known just where your code is breaking. From there, it wouldn't have been a huge leap to figure out why.
Good news, my c64 ist still running after lots of years spending time on my attic..
But what I always wanted to know is:
How can I automatically load & run a program from a floppy disk that is already inserted
when I switch on the c64?
Some auto-running command like load "*",8,1 would be adequate...
Regards
MoC
You write that a command that you type in, like LOAD"*",8,1 would be adequate. Can I assume, then, that the only problem with that particular command is that it only loads, but doesn't automatically run, the program? If so, you have a number of solutions:
If it's a machine language program, then you should type LOAD"<FILENAME>",8,1: and then (without pressing <RETURN>) press <SHIFT>+<RUN/STOP>.
If it's a BASIC program, type LOAD"<FILENAME>",8: and then (without pressing <RETURN>) press <SHIFT>+<RUN/STOP>.
It is possible to write a BASIC program such that it automatically runs when you load it with LOAD"<FILENAME>",8,1. To do so, first add the following line to the beginning of your program:
0 POKE770,131:POKE771,164
Then issue the following commands to save the program:
PRINT"{CLR}":POKE770,113:POKE771,168:POKE43,0;POKE44,3:POKE157,0:SAVE"<FILENAME>",8
This is not possible without some custom cartridge.
One way to fix this would be getting the Retro Replay cartridge and hacking your own code for it.
I doubt there is a way to do it; you would need a cartridge which handles this case and I don't think one like that exists.
A better and more suitable solution is EasyFlash actually. Retro Replay is commonly used with its own ROM. Since it is a very useful cartridge by default ROM, I would never flash another ROM to it. Also it is more expensive than EasyFlash if you don't have any of those cartridges.
At the moment, I have Prince Of Persia (!) ROM written to my EasyFlash and when I open my c64, it autoruns just like you asked for.
Not 100% relevant, but C128 can autoboot disks in C128 mode. For example Ultima V (which has musics on C128 but not on C64 or C128 in C64 mode) autoboots.
As for cartridges, I'd recommend 1541 Ultimate 2. It can also run games from module rom images (although Prince of Persia doesn't work for me for some reason, perhaps software issue?), but you also get rather good floppy emulator (which also makes it easier to transfer stuff to real disks), REU, tape interface (if you order it) etc.
If you are working with a ML program, there are several methods. If you aren't worried about ever returning to normal READY prompt without a RESET, you can have a small loader that loads into the stack ($0100-$01FF) The loader would just load the next section of code, then jump to it. It would start at $0102 and needs to be as small as possible. Many times, the next piece to load is only 2 characters, so the file name can be placed at $0100 & $0101. Then all you need to do is set LFS, SETNAM, LOAD, then JMP to it. Fill the rest of the stack area with $01. It is also rather safe to only save $0100-$010d so that the entire program will fit on a single disk block.
One issue with this, is that it clears out past stack entries (so, your program will need to reset the stack pointer back to the top.) If your program tries to do a normal RTS out of itself, random things can occur. If you want to exit the program, you'll need to jmp to the reset vector ($FFFC by default,) to do so.
I am working with a free app that calculates grades for norwegian high school students. The different subjects are stored in a sqlite database. Everything works fine, except for one thing: If i close the app and restart quickly (faster than, say, one second), it crashes. Also, this only happens if I close the app in specific circumstances involving selecting/checking subjects in a UITableView (the changes are immediately stored in the database). Anyway if I wait for more than one second before restarting the app, it never crashes.
The error is not traced in any way in the console window.
Instruments has found some memory leaks in my app, but they are very small (16 bytes). I presume that is not the reason for the crash (but I will try to stop the leaks). I have also tried deleting and reinstalling the app, and turning the iPod/iPhone on and off. No change...
I understand that I cannot ask anyone to find the error in the extensive code of my app. My questions to you guys are:
Have any of you experienced similar errors? Related to sqlite?
Do you think App store will reject the app because of this?
Does anyone have any idea where to start looking for the error?
I am very thankful for any response!
When you say "it crashes," what is the actual error you get in the stack on the phone? Is it an actual crash, or are you getting a "failed to launch in time error?"
On iPhone, it's possible for an app's main thread to terminate while still running background nondetached threads. In this sense, despite all the claims that you cannot run in the background, you actually can... for a few seconds. When the main thread terminates, you go back to Springboard, and eventually the OS will kill your process if it doesn't terminate on its own. Do you manage any of your sqlite work on a background thread? Do you create any nondetached threads (this generally requires pthreads, so if you don't know, you probably aren't, but sqlite might; check in Instruments).
It's possible that your last instance still has a lock on your database, and that your re-launch doesn't react well to that lock. Do you have proper error handling around your open?