

New in RubyMotion: Blocks Rewrite, Retain Cycle Detection, Better Crash Reports - watson1978
http://blog.rubymotion.com/post/56232015979/new-in-rubymotion-blocks-rewrite-retain-cycle

======
sudhirj
Looks like a huge step forward for RM - it shows that the team is ready to
drop everything to address pressing issues and reassure everyone.

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?

~~~
sudhirj
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.

~~~
1qaz2wsx3edc
Save your money, checkout phonegap, IMO. I think RubyMotion still has
stability issues.

~~~
millerm
There is no comparison to the two though. RubyMotion is about writing native
apps where PhoneGap is not.

~~~
1qaz2wsx3edc
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.

~~~
millerm
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.

~~~
1qaz2wsx3edc
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.

------
duaneb
Do the GC changes address the problems outlined here?:
[http://joshsymonds.com/blog/2013/06/26/why-im-not-using-
ruby...](http://joshsymonds.com/blog/2013/06/26/why-im-not-using-rubymotion-
in-production/)

EDIT: Looks like it, great! :D (Also: it was the block changes, not GC
changes).

~~~
silasj
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.

~~~
duaneb
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.

~~~
millerm
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.

~~~
duaneb
> 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.

~~~
millerm
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.

~~~
duaneb
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.)

