I wonder if some problems I get are caused by object release.
Suppose I have a list of dictionaries managed by a controller. I bind the keys of the “current” dictionary (the controller’s selection) to interface elements.
When the file is closed, I write the dictionaries to the disk, and then, what should I do?
myController’s removeAllObjects() ?
and what happens if I set the list directly by:
set myList to {} ?
The result is the same: to empty the list does not really release the dictionaries.
More, what if one of these dictionaries key is a dictionary itself, bound by selection.myKey.mySubkey ?
There is no real myDictionary’s dispose() in ASOC (and it would not solve my problem anyway). Do I risk “unpredictable results” ?
So my question remains: do I end with bindings to dangling objects? When an object is released, theoretically I can’t assume it’s set to NIL – the address is just freed and may afterwards point right to a black hole.
Before carbage collection (and still on IOS) you have to ratain an object. When releasing it the application looks how many retains are stilll pointed to that object and when it reaches zero it will free itself. What the carbage collector does is looking in the other direction too. Does the owner of the retain still exists. If there are no owners left free the object too. So in case of your binding question, the memory will never be freed unless you set the binding to another object. Only then the object has not retains and carbage collector free the ‘dangling’ object.
set theDic to NSMutableDictionary’s – (creation/initialization of an object)
myListController.addObject_(theDic) – (theDic is added, as a reference, to myListController)
.
set myList to {} – (the list managed by the list controller is emptied “in its back”
→ theDic is set to NIL because there is no more reference to in in the program? I just can’t believe this. And what about a binding of a dictionary’s key to the interface (for example theDic.firstKey)? Doesn’t count as a reference preventing theDic to be freed?
Despite your explanations, all that remains a little confused for me.
Wrong. The object will be duplicated in cocoa. Because applescript doesn’t work with memory but a stack, the pointer in cocoa isn’t interchangable directly with applescript references. The bridge creates two objects, one in cocoa and one in applescript (a reference is still an object).
Because you’re looking in the wrong direction, your concolusion is also wrong. When an object is removed in cocoa the object in applescript is nil simply because it can’t be found through the bridge and returns a nil or throws an error. You have to remember that the carbage collector doesn’t work in the applescript environment, only in the cocoa which isn’t directly available. For the cocoa environment, it takes care of itself.
Then if you still don’t believe me, write a datasource, load gigs of data and then with applescript set the data source to {}. Run top next to it and you’ll see that the carbage collector is working. When you would do the same in C (which hasn’t a carbage collection) you’ll have a huge memory leak and the application will eat you macs memory.
Sorry, that’s the direction I have been looking for years when I’ll have to take take of disposing of my objects AND objects allocated by this object (with doubly linked lists it was sometimes very funny.)
OK, so if I don’t have to worry about objects in Cocoa, and as I never been worried about Applescript’s objects, my initial question has another answer.
My code is perfectly running under XCode 3.2 but randomly under XCode 4 (there is no error but XCode waits forever in background after launching my app, whose behavior is unstable: I can’t quit neither my app nor XCode and I have to force them to quit. That’s why I suspected a problem with bindings. But you are telling me that if “the bridge is broken” between AS and OC, the worse is simply a NIL setting, and a binding to NIL can’t hurt.
Sometimes I get an error that I’ve never seen: Cocoa tells it can’t set the value 9.22337e+18 (which seem to be the highest possible value) to q (or something similar). Ever met this?
Anyway, I cleaned the project, restart the Mac, rebuilt and now everything seems to work. It’s not because there is no more bomb icon that the good old tricks are obsolete.
Thank you for your explanations – I’m not sure I will retain everything
Bindings has nothing to with applescript directly because applescript doesn’t have such things. The binding is in Objective-C part of your application and with the bridge I meant the AppleScriptObjC.Framework. So the bridge between AS and OC is never broken. The binding with the Objective-C/Cocoa objects can be broken. But again when an object binding points to an object, that mean that there is still an retain open to that object so t isn’t released until you overwrite the binding as well.
yes I see this more often in C and C++ because it is indeed the highest possible number of an signed long on 64 bits machines. It means the value that is set can’t be set because it reaches the end. The reason I see this is mostly because when I have a unsigned int value and want to place it in a signed int (it misses one bit or value is indeed to high). What this error has to with bindings I’m not sure… but seems you’re sending the wrong values (which will be converted to pointers).
Additional information to both questions
Objective-C supports two bindings, static and dynamic/late/virtual bindings. The one that throws errors are static bindings. This means the binding is set at compile time and must exists at runtime. The other binding is set at runtime and is triggered through an message. This of course will slow down the application but will run through the OBJC environment and send the message to objects. If the object doesn’t exist then there is no problem at all.
No this is not documented or anything but Mac OS X is just another ordinary operating system like any other system. You’d think that today with internet everything can be found. Some information can others cant. For example tanenbaum’s book about minix is very interesting how an *nix OS actually works. Mac OS X an relative to a Minix OS and contains years of development in it. You do not only know what operating systems are but you also understand what applications really are and what they do.
It’s not fair to say but with not only knowledge about an single programming language or a library/framework but an overall ‘under-the-hood’ system knowledge you just know what is possible and not. For instance the BBC BASIC computer I had in my young years (i’m now only 30, I started young) was very remarkable machine, still today. It could mix assembly and interpreter code and mix variables in between them.
Back to applescript and my conclusion. I was already programming at the the development of software interpreters (like applescript, perl, python). Unlike my BBC BASIC machine (thanks to the hardwired interpreter) it is not possible with applescript to have interpreter instuctions and assembly/compiler code mixed together.
Sorry, much ado about nothing – it was a design error (a missing test for one of these “it should never happen” situations). The code had always worked properly (and the bindings too). But I learned a lot anyway.
when I’ll have to take take of disposing of my objects AND objects allocated by this object (with doubly linked lists it was sometimes very funny.)
