On Tue, Feb 15, 2011 at 5:28 PM, Laurent Sansonetti
wrote:
> Hi Alan,
> Do you control the data structure that holds a reference to 'B'? If yes, you
> may want to use NSHashTable which supports weak references.
> To me, this sounds like a design problem. Maybe your project can be
> re-architecture
finalizers. By using WeakReferences (and especially
PhantomReferences) you can drive finalization from userland code,
avoiding much of the GC overhead that might otherwise result.
- Charlie
On Fri, Feb 18, 2011 at 5:28 PM, Charles Oliver Nutter
wrote:
> On Tue, Feb 15, 2011 at 5:28 PM, Laurent Sansone
On Fri, Feb 11, 2011 at 4:08 PM, Rich Morin wrote:
> At 6:09 PM -0200 2/11/11, Caio Chassot wrote:
>> On 2011-02-11, at 15:25 , Matt Aimonetti wrote:
>>>
>>> Magically converting a snake_case method call to a
>>> CamelCase method dispatch is bad for peformance
>>> and documentation.
>
> It's not c
On Sun, Jan 30, 2011 at 6:19 PM, Morgan Schweers wrote:
> Greetings,
> Ruby's sort algorithm is quicksort, last I checked, and quicksort is not
> stable (which is the property you're looking for in a sort). There are a
> bunch of ways around this, including writing your own, but one cute, quick,
On Wed, Jan 26, 2011 at 4:50 PM, Laurent Sansonetti
wrote:
> No, only locals and dynamic (block) variables.
> To be honest I always disliked this semantic change too. I think it was a
> mistake to add it. It will probably be reverted for 1.0.
I started to try to implement it, and it's not easy. I
On Wed, Jan 26, 2011 at 4:45 PM, Laurent Sansonetti
wrote:
> Hi Charles!
> Sorry for the late response.
> As others have noted, in this snippet, #apply is called on a sequential
> queue (queues created by Queue.new are always sequential), therefore there
> shouldn't be any problem here. If the que
On Mon, Jan 24, 2011 at 11:13 AM, Joshua Ballanco wrote:
> Regarding the potential bug...well...where to begin? So, yes, MacRuby blocks
> have the same semantics as regular Ruby blocks, *except* when they are
> dispatched through GCD. In that case, ivars are shared, but local variable
> get copied
On Tue, Jan 25, 2011 at 2:11 AM, Charles Oliver Nutter
wrote:
> I did have to hack around the parser logic, since native extensions
> largely mean death for concurrency on JRuby (and by native I mean C
> extensions using MRI's API). Instead, I lifted code from Mongrel and
> Rack
On Tue, Jan 25, 2011 at 1:00 AM, Joshua Ballanco wrote:
> On Mon, Jan 24, 2011 at 8:20 PM, Charles Oliver Nutter
> wrote:
>> I'm curious what you mean by this. Can you point out the code? Is it
>> actually attempting to rewrite local variable or instance variable or
&g
On Mon, Jan 24, 2011 at 11:23 AM, Joshua Ballanco wrote:
> Arrays in MacRuby are not inherently thread safe. However,
> "Dispatch::Queue.new" creates a serial queue. So, there is an error in that
> each invocation of the block will execute serially. If, instead, the example
> had used "Dispatch::Q
On Mon, Jan 24, 2011 at 11:39 AM, Jordan K. Hubbard wrote:
> FWIW, we've tried this same approach experimentally (use a per-object serial
> queue behind the scenes to implement an async setter / sync getter model)
> over in CoreFoundation land, and it seemed to work reasonably well for the
> mo
On Mon, Jan 24, 2011 at 11:26 AM, Joshua Ballanco wrote:
> On Mon, Jan 24, 2011 at 12:15 PM, Charles Oliver Nutter
> wrote:
>>
>> Queue#apply is actually defined in gcd.c in MacRuby's code, so this
>> would be a MacRuby bug. I'd have filed it, but I wasn&#x
On Mon, Jan 24, 2011 at 10:24 AM, Matt Massicotte wrote:
> My guess is that most problems need a thread-safe mechanism, where
> manipulating an array is just one part of a more complex system. Pushing the
> details of the thread-safety into the array just hides the problem, and will
> likely t
On Sat, Jan 22, 2011 at 2:00 PM, wrote:
> Taking
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html
> as a sign, the answer appears to be:
> neither of these can be safe, the latter even more so since the result is
On Sat, Jan 22, 2011 at 8:52 AM, Ernest N. Prabhakar, Ph.D.
wrote:
> My assumption was that doing a parallel assign:
>
> result[i] = i*i
>
> would be safe, since it always accessed a unique portion of memory, but doing
> a serial append:
>
> result << i*i
>
> would not. But that may have been a
Apologies reporting this here; I'm not sure where I should report bugs
in ControlTower.
I believe there's a bug in ControlTower around line 34:
def open
@status = :open
while (@status == :open)
connection = @socket.accept # << here
@request_queue.async(@request_gr
I'm curious about this example in Queue#apply's rdoc:
* gcdq = Dispatch::Queue.new('doc')
* @result = []
* gcdq.apply(5) {|i| @result[i] = i*i }
* p @result #=> [0, 1, 4, 9, 16, 25]
apply is said to issue the jobs in parallel, so this would be making
concurrent updates to the
On Thu, Jan 6, 2011 at 1:26 AM, Henry Maddocks wrote:
> Neither of those projects have anything to do with MacRuby and as far as I
> can they don't have much to do with MRI either so their impact will be
> academic at best. The Mirah project is trying to make ruby more like Java.
> Well there a
On Fri, Jul 10, 2009 at 3:02 PM, Laurent
Sansonetti wrote:
> Now, consider:
>
> def foo
> begin
> yield
> ensure
> p :ok
> end
> end
> def bar
> foo { return 42 }
> end
> p bar
>
> Here you don't have a choice, since you need to honor the ensure block.
>
> In Ruby, return is semantically
Eloy Duran wrote:
What would be great is if you could first complete the openssl part of
the rubyspec, which desperately needs some love.
Wow, I concur a thousand times over. I'd love to have a complete set of
OpenSSL specs out there, but I'm totally underqualified to write them.
- Charlie
_
Laurent Sansonetti wrote:
OpenSSL might be way harder given the richness of its API (as well as
the fact that every release seems to introduce API breakage).
I was going to say basically that but didn't want to discourage anyone.
So I'll say it now: OpenSSL would be a serious pain to wrap. Som
Laurent Sansonetti wrote:
Very good question... We currently need to access readline (for IRB), so
porting the readline extension to FFI will be very useful.
There's actually a (partial?) port of readline to FFI by Koichiro Ohba.
I'll try to find out where it's located.
Other extensions part
Laurent Sansonetti wrote:
Hi Łukasz,
This mailing-list was usually created for all people developing with
MacRuby, not necessarily people developing MacRuby itself. But I can
understand that the group name is ambiguous.
Just to let everyone know, there is absolutely no problem posting
anyth
Vincent Isambart wrote:
the test_string tests in Ruby 1.9 repository do seem to mostly function
You mean test/ruby/test_m17n.rb, test/ruby/test_m17n_comb.rb,
test/ruby/test_io_m17n.rb and test/ruby/enc/test_*.rb?
test/ruby/test_string.rb does not contain anything m17n related.
We simply could
Vincent Isambart wrote:
I think everyone agrees that having a Ruby 1.9 String specs will be
necessity. And we'll also need to decide what parts of it to follow
and what parts we do not need to. For example handling access to
characters in a string with a partly invalid encoding exactly the same
w
Vincent Isambart wrote:
Hi again,
So plan B: We emulate Ruby 1.9 strings behavior on top of of NSString/NSData.
I'm really interested in this discussion too. A little background for JRuby:
We started out (or really, the original authors started out) with JRuby
using all Java strings and stri
Laurent Sansonetti wrote:
On Apr 4, 2009, at 7:57 PM, Charles Oliver Nutter wrote:
The interesting thing about many of these microbenchmarks is that a
substantial part of MacRuby's performance seems to come from one key
optimization: recursive calls.
If you're talking about fib or
Laurent Sansonetti wrote:
For instance, the optimizations that are (and will be) implemented in
the experimental branch are not random but were selected after having
profiled a big MacRuby/Cocoa application and found many areas where we
performed badly. I assume that other implementations are u
Richard Kilmer wrote:
I don't necessarily agree that microbenchmarks are _NOT_ good indicators.
I think a specific microbenchmark is not, but the point of these micro-
benchmarks are to judge the speed of specific runtime units. If you run
one really fast it is not a good indicator of general pe
Charles Oliver Nutter wrote:
Matt Aimonetti wrote:
Hi Charlie,
I don't think/hope you do it on purpose, but it seems that you're
asking questions just to prove that Laurent is wrong and that whatever
he will do will end up slowing down the current experimental branch.
I th
Matt Aimonetti wrote:
Hi Charlie,
I don't think/hope you do it on purpose, but it seems that you're
asking questions just to prove that Laurent is wrong and that whatever
he will do will end up slowing down the current experimental branch.
I think you're misinterpreting me. I'd love for Lau
Laurent Sansonetti wrote:
I don't think it's a good idea to provide a way to turn off
optimizations and I do not see the point in benchmarking dead code in
general (I would never do this).
I think it's actually very useful to provide a way to turn off specific
optimizations, if only because t
Laurent Sansonetti wrote:
It's possible by modifying the source code and comment the call to
createInstructionCombiningPass() and createCFGSimplificationPass(), but
I do not recommend to remove these because I think it would break the
way we compile Dwarf exception handlers in blocks.
# In my
Laurent Sansonetti wrote:
Hi guys,
As some of you already noticed we have been working on a branch for a
few weeks and I thought it's now time to describe what has been done and
were we are going exactly.
Very cool stuff...some low-level benchmarks seem to have really
excellent performance.
34 matches
Mail list logo
