New in RubyMotion: Blocks Rewrite, Retain Cycle Detection, Better Crash Reports(blog.rubymotion.com)
blog.rubymotion.com
New in RubyMotion: Blocks Rewrite, Retain Cycle Detection, Better Crash Reports
http://blog.rubymotion.com/post/56232015979/new-in-rubymotion-blocks-rewrite-retain-cycle
2 comments
Just to be clear, I think RubyMotion is awesome. I use a license at work and I'm about buy a personal one (here in India it's a very significant cost - I'm decently paid and I make only USD 1100 a month). But I do dislike the way they've handled issues with the platform.
Out of interest, why did you (or your work) decide to use RubyMotion (vs Objective-C)? Were you all using Ruby already / familiar with the language, or was it something else?
Save your money, checkout phonegap, IMO. I think RubyMotion still has stability issues.
There is no comparison to the two though. RubyMotion is about writing native apps where PhoneGap is not.
There is absolutely a comparison here. Both allow you to build mobile applications for IOS.
A single feature like native or not native does not dictate the quality of an application.
Also, I was trying to help some guy who only makes 1100/mo.
A single feature like native or not native does not dictate the quality of an application.
Also, I was trying to help some guy who only makes 1100/mo.
I'm just responding with my thoughts on this...
I don't think native vs. a browser based is a 'single feature'. It's huge. Without access to the SDK's real power you lose a LOT of functionality and performance. I would never deliver a PG app to anyone other than an in-house enterprise app that just gets the job done. Sorry, it's just the way I feel about it. I loath those applications. I won't take shortcuts that save me a little time but at the cost of all my customers being pissed off at a sub-standard application. Again, this is my opinion but I do have empirical evidence in my career that supports my assertions.
Performance we can debate till the end of days. As for functionality cordova/phonegap has a great plugin framework.
Sure you don't get native ui components, but I look at that as an advantage, because if you use web views you can create a uniform approach.
The onus of performance is always on the developer, and most likely not the tools.
Sure you don't get native ui components, but I look at that as an advantage, because if you use web views you can create a uniform approach.
The onus of performance is always on the developer, and most likely not the tools.
It was a mistake to leave that bug unfixed for so long. I'm glad they came around to fixing it. Hopefully this is a sign of a team and project maturing.
Do the GC changes address the problems outlined here?: http://joshsymonds.com/blog/2013/06/26/why-im-not-using-ruby...
EDIT: Looks like it, great! :D (Also: it was the block changes, not GC changes).
EDIT: Looks like it, great! :D (Also: it was the block changes, not GC changes).
There is no GC in RubyMotion. It uses the Obj-C ARC method to manage memory.
Correction: RubyMotion uses an ARC-like method to manage memory.
Correction: RubyMotion uses an ARC-like method to manage memory.
I would consider reference counting a form of garbage collection—python is certainly considered to have garbage collection and shares many of the same properties as the objective-c version. In fact, I would consider ARC far more powerful than Python's system because it allows deterministic destruction and more powerful weak references. What would you consider GC—reference rooting, or simply automatic memory management that doesn't use reference counting?
That said, duly noted, and I'll make sure to refer to it as reference counting in the future.
That said, duly noted, and I'll make sure to refer to it as reference counting in the future.
I would just like to politely argue that reference counting cannot be considered a form of garbage collection, at all. The discriminating factor is that in a GC world there is, well to put it bluntly, a garbage collector. A garbage collector is a basically a process itself which determines reachability of objects/memory and reclaims that memory if it can determine it is no longer in use. In manual reference counting (ARC also), there is not necessarily such a process. In Objective-C, as soon as an object's reference count gets to zero it's memory is immediately deallocated. There is no process which searches and marks an object's memory to be reclaimed. It would be like calling any other type of manual programatic memory management garbage collection because the programmer handled the garbage. Now, reference counting in Python may use a garbage collector to clean up zero count references, but they are mutually exclusive, IMHO.
> A garbage collector is a basically a process itself which determines reachability of objects/memory and reclaims that memory if it can determine it is no longer in use
That's a very.... narrow definition, to say the least. I've never seen this outside of the objective-c world. In my mind, garbage collection is automatic memory management, of which objective-c provides an arguably better solution than imprecise collectors. To distinguish between them at all strikes me as pedantic and counterproductive.
Anyway, the only real difference between python and objective-c is that yes, python has a garbage collection routine that bulk frees objects with refcounts of 0... functionality conveniently provided by @autorelease. This would make ARC a superset of python's GC.
That's a very.... narrow definition, to say the least. I've never seen this outside of the objective-c world. In my mind, garbage collection is automatic memory management, of which objective-c provides an arguably better solution than imprecise collectors. To distinguish between them at all strikes me as pedantic and counterproductive.
Anyway, the only real difference between python and objective-c is that yes, python has a garbage collection routine that bulk frees objects with refcounts of 0... functionality conveniently provided by @autorelease. This would make ARC a superset of python's GC.
I'm not here to argue, other than intellectual arguments... You call my definition narrow. Not sure why. Can you describe what a GC does in a single sentence? I'm just going for a simple description. It also doesn't matter if you haven't seen this outside of Obj-C. I am almost lost at the point that is being made. ARC is in no way, at all, a garbage collection technology. @autoreleasepool is in no way a garbage collection concept. All it does is provide a scope for the compiler to inject a 'release' call on all the instances in the block that were sent the autorelease message in said block.
ARC is purely a compile time feature. And an awesome one at that. There is no ARC runtime process/thread. There is no ARC memory manager.
Anyway. Feel free to respond. I have said all I am going to.
On another note, is there any way to be informed/notified that someone responded to a post? Or do you have to keep coming back and checking? I feel that I drop out of conversations because I lose track.
ARC is purely a compile time feature. And an awesome one at that. There is no ARC runtime process/thread. There is no ARC memory manager.
Anyway. Feel free to respond. I have said all I am going to.
On another note, is there any way to be informed/notified that someone responded to a post? Or do you have to keep coming back and checking? I feel that I drop out of conversations because I lose track.
Garbage Collection: A system wherein memory is automatically allocated when referenced and freed for another allocation when not referenced.
It sounds like you believe a garbage collection system must achieve a certain level of complexity beyond reference counting, and I can't help with that—however, it's a fairly pointless distinction if we switch from saying "GC" to "GC and reference counting" to talk about automatic memory management. What does that give us? And why WOULDN'T you want this simplicity? I don't much care how trivial you consider ARC to be, it certainly collects garbage effectively. No memory scans to worry about interrupting your real time application. If you really need to not deallocate in a tight loop you can autorelease (I never claimed it was a garbage collection mechanism).
And I am not aware of a way to be notified by HN itself but a lot of apps and sites provide that. (I don't use one myself, I just check threads I am still interested in.)
It sounds like you believe a garbage collection system must achieve a certain level of complexity beyond reference counting, and I can't help with that—however, it's a fairly pointless distinction if we switch from saying "GC" to "GC and reference counting" to talk about automatic memory management. What does that give us? And why WOULDN'T you want this simplicity? I don't much care how trivial you consider ARC to be, it certainly collects garbage effectively. No memory scans to worry about interrupting your real time application. If you really need to not deallocate in a tight loop you can autorelease (I never claimed it was a garbage collection mechanism).
And I am not aware of a way to be notified by HN itself but a lot of apps and sites provide that. (I don't use one myself, I just check threads I am still interested in.)
I'd agree that reference counting is a form of garbage collection; It's what wikipedia says on it's page on reference counting. Maybe I was too hasty in my comment - or not very clear. I do think that benefits are to be had (as far as conveying information efficiently) when using more narrow and precise definitions.
I was also thinking "garbage collector" not "garbage collection". :P
I was also thinking "garbage collector" not "garbage collection". :P
Wait, what? How is ARC more powerful than Python's system? ARC is reference counting. Python is reference counting (with a mark-and-sweep collector that sometimes runs to collect cycles). Python also supports weak references (http://docs.python.org/2/library/weakref.html). What's the difference?
The OP mentioned that Objective-C's memory management is deterministic since it does not use a garbage collector. The major benefit is you know exactly when the memory is reclaimed (at zero references). You cannot determine when this will happen in Python (or any other GC language). That's all. And, there is no GC pause time in Objective-C's runtime so, that's awesome too. Another plus of ARC is that the compiler can place the release calls to your releasable instances closer to where they should be and can keep your memory foot print significantly lower, as code would be a lot harder to write with intertwined release calls in the middle of methods. A lot of people like to write their code in a structured form (like, release at the end of a method instead of 'inline' or 'immediate', I hope that makes sense) rather than high performance, due to readability.
What? Python is ref counted. It releases at the time an object goes out of scope and has no references anymore... exactly like ARC. Although Python says its garbage collection is implementation-defined, in practice pretty much everybody uses CPython which uses refcounting. Where does the idea come from that Python releases at undeterministic time?
> Where does the idea come from that Python releases at undeterministic time?
It's not the time that's undeterministic, it's that the 'deconstructor' may not be called at all if python can't guarantee collecting cyclical references in the right order. The object will still be released/deallocated.
In this sense, Objective-C—mostly because you have complete control over the reference counting—has superior reference counting semantics.
I'd like to note that there's nothing stopping Python from using similar approaches.
It's not the time that's undeterministic, it's that the 'deconstructor' may not be called at all if python can't guarantee collecting cyclical references in the right order. The object will still be released/deallocated.
In this sense, Objective-C—mostly because you have complete control over the reference counting—has superior reference counting semantics.
I'd like to note that there's nothing stopping Python from using similar approaches.
Not too happy about the way the change came about, though: when the blocks bug was first reported, the HipByte team all but dismissed it saying it was a well known and understood problem with a clear workaround. It's only after the public caused a ruckus that they stopped developing new features and got around to fixing it.
This may have been the right choice - delay fixing things until there was an explosion of public pressure - but it also worries me. Why wait so long to fix something that was so fundamental? Not properly supporting blocks broke a fundamental contract; that you could write Ruby and it would Just Work(TM). The lack of support was undocumented and ignored until HN got all riled up and swore to boycott RubyMotion because of it. Then HipByte put their hero helmets on and got to work.
What happened to fixing bugs before you develop new features?