-Greg--
---
You received this message because you are subscribed to the Google Groups "RubyMotion - Ruby for iOS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubymotion+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
It's ok if using an ivar is just a pain or unsuitable, but if there are some cases where they can go away unexpectedly too, those cases would be good to understand (or fix ahead of a full solution).
If data collection in the wild could be part of the solution, I manage a collection platform that I could volunteer to receive and digest the data ... but I have no idea what would be useful app side instrumentation to create. Some kind of RM-aware auto-breadcrumb reporter that an affected user could trivially drop into their next update? Just spitballing.
We cannot simply say there is a simple workaround for the issue based on a reduced example. The manifestations of this appear to go far beyond a simple test case, and without a fix (non-performant if necessary) we are unable to see its extent or whether each failure is in fact the same issue or another. It is not reasonable to wait months for each fix, only then to uncover the next issue.
I see a clear lack of a sense of urgency over this and many other bugs. Perhaps the overly positive attitude about the community, or the quantity of simpler apps that are able to ship anyway have enabled it. I don't expect solutions are easy, but when new platform releases come out, that clearly indicates where priorities are. Quite misplaced. Serious bugs are not unexpected in a young product, but a laid-back approach to dealing with them is very costly to and an insult to developers. Engineering time is expensive, and time to market is critical. These are emergencies.
--
---
You received this message because you are subscribed to the Google Groups "RubyMotion - Ruby for iOS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubymotion+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to a topic in the Google Groups "RubyMotion - Ruby for iOS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rubymotion/x6-9c__IHH0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rubymotion+...@googlegroups.com.
--
---
You received this message because you are subscribed to a topic in the Google Groups "RubyMotion - Ruby for iOS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rubymotion/x6-9c__IHH0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rubymotion+...@googlegroups.com.
--
---
You received this message because you are subscribed to the Google Groups "RubyMotion - Ruby for iOS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubymotion+...@googlegroups.com.
To HipByte: What can the community do to make the importance of this kind of showstopping issue more visible to you?Steve
class Tiger
def dealloc puts "DEALLOC" super end
def self.blocker(&block) block.call end
def self.set_tiger(new_tiger) @tiger = new_tiger end
def self.set_tiger_with_block(new_tiger) blocker do @tiger = new_tiger end end
end
# Will print "DEALLOC" 10 times which is expected:
10.times { Tiger.set_tiger(Tiger.new) } # => Prints "DEALLOC" 10 times
# Does not print "DEALLOC". All tigers are retained:
# (Although maybe that's better than freeing a bunch of tigers into the streets... :) )
10.times { Tiger.set_tiger_with_block(Tiger.new) }
On Thu, Jun 27, 2013 at 12:50 PM, aceofspades <dou...@gmail.com> wrote:
I wonder if some sort of development mode could be helpful. I'm quite fine with a performance hit if it speeds development by detecting conditions so the causes of the all-to-frequent memory issues can be narrowed down.
--
---
You received this message because you are subscribed to a topic in the Google Groups "RubyMotion - Ruby for iOS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rubymotion/x6-9c__IHH0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rubymotion+...@googlegroups.com.
There are a lot of crucial information hidden in the threads of this google group that definitely should be in the official documentation. And I mean not in the future next new version of the documentation available in several months. I mean NOW.
--
---
You received this message because you are subscribed to a topic in the Google Groups "RubyMotion - Ruby for iOS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rubymotion/x6-9c__IHH0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rubymotion+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
With this update you should see less crashes related to dynamic variables. In the past, blocks would not retain variables created outside their scope. Now, these variables are allocated as heap-memory inside the Proc object, and the calling scope points to their storage accordingly.
Also, we rewrote the way blocks are represented in the runtime. Before, blocks were separate data structures cached by the VM object and never freed. Now, blocks and Proc objects are basically the same, we use only one data structure and it's properly released when no longer used. So, you should see less memory usage.
Hi guys,I just woke up and read about this. First I have to apologize, I'm not actively following the Google group since a long time due to time constrains.As far as I know (but correct me if I'm wrong), the issue discussed on this thread is the infamous http://hipbyte.myjetbrains.com/youtrack/issue/RM-3, which basically makes dynamic variables (block variables) subject to premature release.That bug existed since the first version of RubyMotion, and I personally tried a few times to fix it, but wasn't able to come with a good solution that would also perserve performance.Fortunately, there is a workaround. Instead of using dynamic/block variables, one can use instance variables instead. Instance variables will always create object references. The workaround has been discussed a lot of times and I know that pretty much everyone with a popular RubyMotion app on the store is carefully using it.Since the workaround was simple I decided that we should focus on fixing other bugs and adding more features to the platform. Actually, we are right now developing two new major features for the toolchain.But I realize that the problem might still affect people. I agree that keeping RM-3 alive is a disappointment. So, starting from this very day, we will stop working on other things and 100% focus on fixing RM-3.You can expect RubyMotion 2.4 to ship with a fix for that problem.If you have any question or concern please feel free to direct email me: l...@hipbyte.comCheers.Laurent
--
---
You received this message because you are subscribed to the Google Groups "RubyMotion - Ruby for iOS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubymotion+...@googlegroups.com.
retainDispatch::Queue.main.after(10) doputs selfautoreleaseend