[#23457] [Bug #1471] "Mutual join" deadlock detection faulty in 1.8.6 and 1.8.7 — John Carter <redmine@...>

Bug #1471: "Mutual join" deadlock detection faulty in 1.8.6 and 1.8.7

17 messages 2009/05/15

[#23483] [Bug #1478] Ruby archive — Oleg Puchinin <redmine@...>

Bug #1478: Ruby archive

29 messages 2009/05/16
[#29225] [Feature #1478] Ruby archive — Luis Lavena <redmine@...> 2010/04/02

Issue #1478 has been updated by Luis Lavena.

[#30345] Re: [Feature #1478] Ruby archive — "NAKAMURA, Hiroshi" <nakahiro@...> 2010/05/21

On Fri, Apr 2, 2010 at 17:13, Luis Lavena <redmine@ruby-lang.org> wrote:

[#30346] Re: [Feature #1478] Ruby archive — Jonathan Nielsen <jonathan@...> 2010/05/21

> Thanks for your comment.

[#30347] Re: [Feature #1478] Ruby archive — Jonathan Nielsen <jonathan@...> 2010/05/21

OK Hiroshi, I read some of the comments earlier in the thread that I

[#30355] Re: [Feature #1478] Ruby archive — Caleb Clausen <vikkous@...> 2010/05/21

On 5/20/10, Jonathan Nielsen <jonathan@jmnet.us> wrote:

[#30364] Re: [Feature #1478] Ruby archive — Benoit Daloze <eregontp@...> 2010/05/22

Hi,

[#23505] [Bug #1494] tempfile#unlink may silently fail on windows — Nicholas Manning <redmine@...>

Bug #1494: tempfile#unlink may silently fail on windows

19 messages 2009/05/19

[#23572] [Bug #1525] Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork? — Hongli Lai <redmine@...>

Bug #1525: Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork?

27 messages 2009/05/27

[#23595] Meaning of RUBY_PLATFORM — Rick DeNatale <rick.denatale@...>

The RUBY_PLATFORM constant is documented in the latest Pickaxe as "The

17 messages 2009/05/28
[#23596] Re: Meaning of RUBY_PLATFORM — Luis Lavena <luislavena@...> 2009/05/28

On Thu, May 28, 2009 at 3:41 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:

[#23602] Re: Meaning of RUBY_PLATFORM — Rick DeNatale <rick.denatale@...> 2009/05/28

On Thu, May 28, 2009 at 2:52 PM, Luis Lavena <luislavena@gmail.com> wrote:

[#23608] Re: Meaning of RUBY_PLATFORM — Luis Lavena <luislavena@...> 2009/05/28

On Thu, May 28, 2009 at 7:08 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:

[#23609] Re: Meaning of RUBY_PLATFORM — Rick DeNatale <rick.denatale@...> 2009/05/29

On Thu, May 28, 2009 at 7:22 PM, Luis Lavena <luislavena@gmail.com> wrote:

[ruby-core:23608] Re: Meaning of RUBY_PLATFORM

From: Luis Lavena <luislavena@...>
Date: 2009-05-28 23:22:13 UTC
List: ruby-core #23608
On Thu, May 28, 2009 at 7:08 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
> On Thu, May 28, 2009 at 2:52 PM, Luis Lavena <luislavena@gmail.com> wrote:
>> On Thu, May 28, 2009 at 3:41 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
>>> The RUBY_PLATFORM constant is documented in the latest Pickaxe as "The
>>> identifier of the platform running this program."
>>>
>>> Actually it appears to actually be the identifier of the platform on
>>> which ruby was compiled. For example, I'm running a darwin ports
>>> version of Ruby installed back when this machine was running OS X 10.4
>>> (Tiger), it has since been upgraded to Leopard 10.5.7
>>>
>>> $ ruby -e'p RUBY_PLATFORM;p `uname -a`'
>>> "i686-darwin8.11.1"
>>> "Darwin Macintosh-3.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar
>>> 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386\n"
>>>
>>> Note the difference.
>>>
>>
>> On my case, RUBY_PLATFORM is reporting "universal-darwin-9.0'
>>
>> And Gem::Platform.local:
>>
>> #<Gem::Platform:0x9267c4 @cpu="universal", @os="darwin", @version="9">
>>
>>> I just noticed this today when I tried out a new OS X specific gem
>>> which baled out when it tought I was running a back-level version of
>>> OS X.
>>>
>>
>> Unless there is a i386 or ppc code there (like you're compiling with
>> inline assembler or something) then RUBY_PLATFORM =~ /darwin/ should
>> be enough.
>>
>> Can you tell me which Gem? (just curious).
>
> The gem is autospec-mac which is looking at the version of OS X to
> determine if it has fsevent support. 澣his isn't an issue of
> installing the gem, it is looking at runtime to determine if the
> service can be used, if so it then forks execution (with backticks) of
> a binary provided with the gem.
>
> This is an OS X only gem which allows autotest to be driven by file
> system events rather than having to poll the filesystem for changed
> files, it also adds working growl notifications.
>
> That gem was actually split into two gems autospec-fsevent and autospec-growl.
>
> the autospec-fsevent gem is now looking at not only the major version
> of OS X, but the minor one since the fsevent service seems to be there
> starting with 8.9.
>
> I opened a ticket with the gem author suggesting that he use `uname
> -a` rather than RUBY_PLATFORM to determine the OS version, since
> RUBY_PLATFORM is showing the version at the time that ruby was
> compiled/configured.
>

Checking for one specific version of the OS to ensure a service is
running or installed is brittle.

There must be another way to determine, at runtime if fsevent is
installed, enabled or running.

For the gem part, I suggest build the gem with the following for
Gem::Specification:

Gem::Platform.new('universal-darwin')
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup駻y

In This Thread