Re: [MacRuby-devel] thread-safety and collections in macruby
That's odd. I would still use freeze more rubyish... :) Terry Moore On 22/10/2011, at 6:41 PM, Michael Johnston wrote: > Thanks, I am using: > > results = NSArray.arrayWithArray(worker_results) > > which although it reports true for is_a?(NSMutableArray) is immutable. > > Cheerio, > > Michael Johnston > [email protected] > > > > > On 2011-10-20, at 3:47 PM, terl wrote: > >> Just a note to the original question >> >> macruby collections are based on objc mutable collections...e.g. >> >> a = %w{my array of strings} >> ["my","array","of"strings"] >> >> b = a.dup. b is still a mutable array. >> >> c = NSarray.alloc.initWithArray( a ) immutable array >> >> c << "hi" >> >> runtime error cannot modify frozen/iimmutable array >> >> b= a.dup.freeze >> >> b << "hi" >> >> behaves the same way as NSArray an immutable array... >> >> >> Terry >> >> >> >> On 21/10/2011, at 9:00 AM, Andy Park wrote: >> >>> >>> On 19 Oct 2011, at 22:43, Jordan K. Hubbard wrote: >>> If the mail archives were easier to search, I'd pull it up, but it isn't and I'm too lazy. :) >>> >>> I set up an entry in gmane for the mailing list a while ago in order to >>> search the list a bit better: >>> >>> http://news.gmane.org/gmane.comp.lang.ruby.macintosh.devel >>> >>> >>> ___ >>> MacRuby-devel mailing list >>> [email protected] >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> ___ >> MacRuby-devel mailing list >> [email protected] >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > ___ > MacRuby-devel mailing list > [email protected] > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] locals & dispatch: is using a pointer the best practice?
On Saturday, October 22, 2011 at 1:35 AM, Michael Johnston wrote: > When I need to get a queue-protected result into a local in code that is > concurrent (so I can't use an ivar) is a pointer the best (only) way to get > the result of a sync block? Assuming I don't want to factor out a method > object. > > > ex: > > result_p = Pointer.new(:id) > some_queue.sync do > result_p.assign(value_protected_by_queue) > end > result = result_p[0] > > it's not very ruby-ish... There's no restriction on not using ivars in block. Indeed, even locals are in scope in a block (and with a #sync dispatched block such as the one you provided, there aren't even any threading issues): result = nil Dispatch::Queue.concurrent.sync do result = true end p result #=> true ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Mailing list hosting (was: thread-safety and collections in macruby)
> Hmm thanks, I didn't realize we had a google groups mirror. I'm wondering if > we shouldn't just move there since it's much easier to use and maintain than > macosforge. > Thoughts, ideas, suggestions? I'd personally prefer that a lot over a mailing list! In trying to work around this, I've turned off mails from the list and subscribed to the group's RSS feed but that makes posting difficult as you have to copy-paste stuff from the google group to a mail reply. Cheers, Sven -- Dr. Sven A. Schmidt abstracture GmbH & Co. KG Wilhelm-Theodor-Römheld-Straße 28 55130 Mainz Fon +49 6131 696 29 0 Fax +49 6131 696 29 29 Mail [email protected] Amtsgericht Mainz HRA 40625 USt-IdNr.: DE258454694 Persönlich haftender Gesellschafter: abstracture IT-Beratungs- und Beteiligungsgesellschaft mbH, Sitz Mainz, Amtsgericht Mainz HRB 41357 Geschäftsführer: Dr. U. Koch, T. Meyer, A. Misok, Dr. S.A. Schmidt, Dr. V. Schönharting smime.p7s Description: S/MIME cryptographic signature ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] locals & dispatch: is using a pointer the best practice?
Very strange, your example works for me in irb too. Irb must do something odd
with locals. Have you tried this outside of irb, though? If you wrap with a
method def'n in irb, it behaves differently, and the fact that locals are
copied has been discussed lots on the list. But Laurent (I think) said this
will likely change, has it already? I'm on 0.10
$ macirb --noprompt
def check
print "can I change a local scalar? "
maybe = "nope"
$q.sync do
maybe = "yep"
end
puts maybe
end
=> nil
def check_p
print "can I assign to a pointer? "
maybe_p = Pointer.new(:id)
maybe_p.assign "nope"
$q.sync do
maybe_p.assign "yep"
end
puts maybe_p[0]
end
=> nil
def check_w
print "can I assign to a wrapper attr? "
maybe = ResultWrapper.new("nope")
$q.sync do
maybe.value = "yep"
end
puts maybe.value
end
=> nil
ResultWrapper = Struct.new(:value)
=> ResultWrapper
$q= Dispatch::Queue.new('q')
=> q
check
can I change a local scalar? nope
=> nil
# but using a pointer works:
=> nil
check_p
can I assign to a pointer? yep
=> nil
# or a wrapper (but more expensive for tight loops):
=> nil
check_w
can I assign to a wrapper attr? yep
=> nil
$q= Dispatch::Queue.concurrent
=> com.apple.root.default-priority
# double-checking it isn't different for the parallel queues:
=> nil
check
can I change a local scalar? nope
=> nil
check_p
can I assign to a pointer? yep
=> nil
check_w
can I assign to a wrapper attr? yep
=> nil
Cheerio,
Michael Johnston
[email protected]
On 2011-10-22, at 12:32 AM, Joshua Ballanco wrote:
> On Saturday, October 22, 2011 at 1:35 AM, Michael Johnston wrote:
>> When I need to get a queue-protected result into a local in code that is
>> concurrent (so I can't use an ivar) is a pointer the best (only) way to get
>> the result of a sync block? Assuming I don't want to factor out a method
>> object.
>>
>>
>> ex:
>>
>> result_p = Pointer.new(:id)
>> some_queue.sync do
>> result_p.assign(value_protected_by_queue)
>> end
>> result = result_p[0]
>>
>> it's not very ruby-ish...
>
> There's no restriction on not using ivars in block. Indeed, even locals are
> in scope in a block (and with a #sync dispatched block such as the one you
> provided, there aren't even any threading issues):
>
> result = nil
> Dispatch::Queue.concurrent.sync do
> result = true
> end
> p result #=> true
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] brace yourselves, 0.11 is coming!
Hi, I installed 0.11 using the installer pkg. The install seemed to work fine. However, when I run my app I get a message that wasn't there with 0.10 or with an earlier build of 0.11. Here's the console message: Membership(4727,0x1043bf000) malloc: *** auto malloc[4727]: error: GC operation on unregistered thread. Thread registered implicitly. Break on auto_zone_thread_registration_error() to debug. I see that there's a closed "won't fix" ticket for a similar problem, so I guess this is not related to the installer. I'll just live with it unless it's of interest to anyone else. Steve ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] locals & dispatch: is using a pointer the best practice?
Ah, indeed, there are subtle differences with lvars at the top-level in IRB vs
in a method scope. Not sure if I'd consider this a bug or not, but to
illustrate:
>> result = nil
=> nil
>> Dispatch::Queue.concurrent.sync do
>> result = true
>> end
=> nil
>> result
=> true
>> def test
>> result = nil
>> Dispatch::Queue.concurrent.sync do
>> result = true
>> end
>> result
>> end
=> nil
>> test
=> nil
Anyway, we're getting away from the original question. If you replace your
lvars with ivars (s/result/@result/ above), then things will work. Just be
careful of the possibility of concurrency bugs when assigning the same ivar
from multiple queued blocks (and also have a look at the dispatch gem which has
some convenience methods to make this sort of thing easier).
On Saturday, October 22, 2011 at 6:30 AM, Michael Johnston wrote:
> Very strange, your example works for me in irb too. Irb must do something odd
> with locals. Have you tried this outside of irb, though? If you wrap with a
> method def'n in irb, it behaves differently, and the fact that locals are
> copied has been discussed lots on the list. But Laurent (I think) said this
> will likely change, has it already? I'm on 0.10
>
>
>
> $ macirb --noprompt
> def check
> print "can I change a local scalar? "
> maybe = "nope"
> $q.sync do
> maybe = "yep"
> end
> puts maybe
> end
> => nil
> def check_p
> print "can I assign to a pointer? "
> maybe_p = Pointer.new(:id)
> maybe_p.assign "nope"
> $q.sync do
> maybe_p.assign "yep"
> end
> puts maybe_p[0]
> end
> => nil
> def check_w
> print "can I assign to a wrapper attr? "
> maybe = ResultWrapper.new("nope")
> $q.sync do
> maybe.value = "yep"
> end
> puts maybe.value
> end
> => nil
> ResultWrapper = Struct.new(:value)
> => ResultWrapper
> $q= Dispatch::Queue.new('q')
> => q
> check
> can I change a local scalar? nope
> => nil
> # but using a pointer works:
> => nil
> check_p
> can I assign to a pointer? yep
> => nil
> # or a wrapper (but more expensive for tight loops):
> => nil
> check_w
> can I assign to a wrapper attr? yep
> => nil
> $q= Dispatch::Queue.concurrent
> => com.apple.root.default-priority
> # double-checking it isn't different for the parallel queues:
> => nil
> check
> can I change a local scalar? nope
> => nil
> check_p
> can I assign to a pointer? yep
> => nil
> check_w
> can I assign to a wrapper attr? yep
> => nil
>
>
>
>
>
>
>
>
>
> Cheerio,
>
> Michael Johnston
> [email protected] (mailto:[email protected])
>
>
>
>
> On 2011-10-22, at 12:32 AM, Joshua Ballanco wrote:
>
> > On Saturday, October 22, 2011 at 1:35 AM, Michael Johnston wrote:
> > > When I need to get a queue-protected result into a local in code that is
> > > concurrent (so I can't use an ivar) is a pointer the best (only) way to
> > > get the result of a sync block? Assuming I don't want to factor out a
> > > method object.
> > >
> > >
> > > ex:
> > >
> > > result_p = Pointer.new(:id)
> > > some_queue.sync do
> > > result_p.assign(value_protected_by_queue)
> > > end
> > > result = result_p[0]
> > >
> > > it's not very ruby-ish...
> >
> > There's no restriction on not using ivars in block. Indeed, even locals are
> > in scope in a block (and with a #sync dispatched block such as the one you
> > provided, there aren't even any threading issues):
> >
> > result = nil
> > Dispatch::Queue.concurrent.sync do
> > result = true
> > end
> > p result #=> true
> > ___
> > MacRuby-devel mailing list
> > [email protected]
> > (mailto:[email protected])
> > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
> ___
> MacRuby-devel mailing list
> [email protected] (mailto:[email protected])
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
