Skip Menu |

This queue is for tickets about the Mac-FSEvents CPAN distribution.

Report information
The Basics
Id: 118258
Status: open
Priority: 0/
Queue: Mac-FSEvents

People
Owner: RHOELZ [...] cpan.org
Requestors: deepak.gulati [...] booking.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Problem compiling on macOS sierra
Date: Tue, 4 Oct 2016 16:09:17 +0200
To: <bug-Mac-FSEvents [...] rt.cpan.org>
From: Deepak Gulati <deepak.gulati [...] booking.com>
I am having trouble getting Mac::FSEvents to build on macOS Sierra. Looks like MacVersion.pm is choking on the new version string they introduced with the latest version of macOS. Here are more details. Please file a bug report on CPAN, and include the following in the description: Software: System Software Overview: System Version: macOS 10.12 (16A323) Kernel Version: Darwin 16.0.0 Boot Volume: macOS Boot Mode: Normal Computer Name: Deepak’s MacBook Pro User Name: Deepak Gulati (dgulati) Secure Virtual Memory: Enabled System Integrity Protection: Enabled Time since boot: 11 days 20:37 Ends in the following error: -> N/A Checking dependencies from MYMETA.json ... Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.24) Checking if you have File::Slurp 0 ... Yes (9999.19) Building and testing Mac-FSEvents-0.12 cp lib/Mac/FSEvents/Event.pm blib/lib/Mac/FSEvents/Event.pm cp lib/Mac/FSEvents.pm blib/lib/Mac/FSEvents.pm Running Mkbootstrap for FSEvents () chmod 644 "FSEvents.bs" "/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- FSEvents.bs blib/arch/auto/Mac/FSEvents/FSEvents.bs 644 "/usr/bin/perl" "/System/Library/Perl/5.18/ExtUtils/xsubpp" -typemap '/System/Library/Perl/5.18/ExtUtils/typemap' -typemap '/Users/dgulati/.cpanm/work/1475589466.89378/Mac-FSEvents-0.12/typemap' FSEvents.xs > FSEvents.xsc Cannot open 'const-xs.inc': No such file or directory in FSEvents.xs, line 476 make: *** [FSEvents.c] Error 1
Hmm, you can fix the version parser with this change to MacVersion.pm: - if($os_version =~ /System Version:(?: Mac)? OS X (?:Server )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { + if($os_version =~ /System Version:.+(?:(10)\.(\d+)(?:\.(\d+))?)/) { The string is now "macOS" instead of "Mac OS X". Thanks Apple! I tested this with: macOS 10.12 (16A320). $ gcc -v Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 8.0.0 (clang-800.0.38) Target: x86_64-apple-darwin16.0.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin I also had to remove the hints/darwin.pl file, or it would complain about a missing SDK. The original point of the hints file was to build fat binaries that supported both 32 & 64-bit. This is ancient history these days and everything is 64-bit, and just using the compiler flags from Perl should be fine. In other words, just remove the file. With the above patch and removing the hints file, I can compile and run the tests. Here's the test output. I'm not sure if the warnings are serious or not. t/01use.t .................. ok t/02pod.t .................. skipped: Test::Pod 1.14 required t/03podcoverage.t .......... skipped: Test::Pod::Coverage 1.04 required t/04critic.t ............... skipped: Critic test only for developers. t/05event.t ................ 1/7 Warning: unable to close filehandle properly: Bad file descriptor during global destruction. Warning: unable to close filehandle properly: Bad file descriptor during global destruction. Warning: unable to close filehandle properly: Bad file descriptor during global destruction. t/05event.t ................ ok t/06flags.t ................ 5/5 Warning: unable to close filehandle properly: Bad file descriptor during global destruction. Warning: unable to close filehandle properly: Bad file descriptor during global destruction. Warning: unable to close filehandle properly: Bad file descriptor during global destruction. Warning: unable to close filehandle properly: Bad file descriptor during global destruction. t/06flags.t ................ ok t/07noflags.t .............. ok t/08leftover-events.t ...... skipped: This is a problem with FSEvents itself, it seems t/09subprocess-events.t .... 1/2 Warning: unable to close filehandle properly: Bad file descriptor during global destruction. t/09subprocess-events.t .... ok t/10receive-all-changes.t .. 1/1 Warning: unable to close filehandle properly: Bad file descriptor during global destruction. t/10receive-all-changes.t .. ok All tests successful. Files=10, Tests=20, 25 wallclock secs ( 0.04 usr 0.03 sys + 0.68 cusr 1.27 csys = 2.02 CPU) Result: PASS
Subject: Re: [rt.cpan.org #118258] Problem compiling on macOS sierra
Date: Tue, 4 Oct 2016 16:51:08 +0200
To: Andy Grundman via RT <bug-Mac-FSEvents [...] rt.cpan.org>
From: Deepak Gulati <deepak.gulati [...] booking.com>
Yup, I already used a slightly different version of your suggestion to get it to build. } elsif ($os_version =~ /System Version:(?: macOS) (?:Server )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { return ($1, $2, $3 || 0); } Regarding the seriousness of test warnings - not sure. I’ve been running a script that uses Mac::FsEvents to observe a folder for changes and copy the changed files to several boxes. It seems to be working as expected for the past few minutes. Thank you for looking into it. On 4 Oct 2016, at 16:44, Andy Grundman via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=118258 > > > Hmm, you can fix the version parser with this change to MacVersion.pm: > > - if($os_version =~ /System Version:(?: Mac)? OS X (?:Server > )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { > + if($os_version =~ /System Version:.+(?:(10)\.(\d+)(?:\.(\d+))?)/) > { > > The string is now "macOS" instead of "Mac OS X". Thanks Apple! I > tested this with: macOS 10.12 (16A320). > > $ gcc -v > Configured with: --prefix=/Library/Developer/CommandLineTools/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 8.0.0 (clang-800.0.38) > Target: x86_64-apple-darwin16.0.0 > Thread model: posix > InstalledDir: /Library/Developer/CommandLineTools/usr/bin > > I also had to remove the hints/darwin.pl file, or it would complain > about a missing SDK. The original point of the hints file was to build > fat binaries that supported both 32 & 64-bit. This is ancient history > these days and everything is 64-bit, and just using the compiler flags > from Perl should be fine. In other words, just remove the file. > > With the above patch and removing the hints file, I can compile and > run the tests. Here's the test output. I'm not sure if the warnings > are serious or not. > > t/01use.t .................. ok > t/02pod.t .................. skipped: Test::Pod 1.14 required > t/03podcoverage.t .......... skipped: Test::Pod::Coverage 1.04 > required > t/04critic.t ............... skipped: Critic test only for developers. > t/05event.t ................ 1/7 Warning: unable to close filehandle > properly: Bad file descriptor during global destruction. > Warning: unable to close filehandle properly: Bad file descriptor > during global destruction. > Warning: unable to close filehandle properly: Bad file descriptor > during global destruction. > t/05event.t ................ ok > t/06flags.t ................ 5/5 Warning: unable to close filehandle > properly: Bad file descriptor during global destruction. > Warning: unable to close filehandle properly: Bad file descriptor > during global destruction. > Warning: unable to close filehandle properly: Bad file descriptor > during global destruction. > Warning: unable to close filehandle properly: Bad file descriptor > during global destruction. > t/06flags.t ................ ok > t/07noflags.t .............. ok > t/08leftover-events.t ...... skipped: This is a problem with FSEvents > itself, it seems > t/09subprocess-events.t .... 1/2 Warning: unable to close filehandle > properly: Bad file descriptor during global destruction. > t/09subprocess-events.t .... ok > t/10receive-all-changes.t .. 1/1 Warning: unable to close filehandle > properly: Bad file descriptor during global destruction. > t/10receive-all-changes.t .. ok > All tests successful. > Files=10, Tests=20, 25 wallclock secs ( 0.04 usr 0.03 sys + 0.68 > cusr 1.27 csys = 2.02 CPU) > Result: PASS >
Hi guys, any news when this fix be published?
On Fri Dec 16 05:21:39 2016, DBCM wrote: Show quoted text
> Hi guys, any news when this fix be published?
I'm working on a release right now.
On Tue Oct 04 10:51:25 2016, deepak.gulati@booking.com wrote: Show quoted text
> Yup, I already used a slightly different version of your suggestion to > get it to build. > > } elsif ($os_version =~ /System Version:(?: macOS) (?:Server > )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { > return ($1, $2, $3 || 0); > } > > Regarding the seriousness of test warnings - not sure. I’ve been > running a script that uses Mac::FsEvents to observe a folder for changes > and copy the changed files to several boxes. It seems to be working as > expected for the past few minutes. > > Thank you for looking into it. > > On 4 Oct 2016, at 16:44, Andy Grundman via RT wrote: >
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=118258 > > > > > Hmm, you can fix the version parser with this change to MacVersion.pm: > > > > - if($os_version =~ /System Version:(?: Mac)? OS X (?:Server > > )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { > > + if($os_version =~ /System Version:.+(?:(10)\.(\d+)(?:\.(\d+))?)/) > > { > > > > The string is now "macOS" instead of "Mac OS X". Thanks Apple! I > > tested this with: macOS 10.12 (16A320). > > > > $ gcc -v > > Configured with: --prefix=/Library/Developer/CommandLineTools/usr > > --with-gxx-include-dir=/usr/include/c++/4.2.1 > > Apple LLVM version 8.0.0 (clang-800.0.38) > > Target: x86_64-apple-darwin16.0.0 > > Thread model: posix > > InstalledDir: /Library/Developer/CommandLineTools/usr/bin > > > > I also had to remove the hints/darwin.pl file, or it would complain > > about a missing SDK. The original point of the hints file was to build > > fat binaries that supported both 32 & 64-bit. This is ancient history > > these days and everything is 64-bit, and just using the compiler flags > > from Perl should be fine. In other words, just remove the file. > > > > With the above patch and removing the hints file, I can compile and > > run the tests. Here's the test output. I'm not sure if the warnings > > are serious or not. > > > > t/01use.t .................. ok > > t/02pod.t .................. skipped: Test::Pod 1.14 required > > t/03podcoverage.t .......... skipped: Test::Pod::Coverage 1.04 > > required > > t/04critic.t ............... skipped: Critic test only for developers. > > t/05event.t ................ 1/7 Warning: unable to close filehandle > > properly: Bad file descriptor during global destruction. > > Warning: unable to close filehandle properly: Bad file descriptor > > during global destruction. > > Warning: unable to close filehandle properly: Bad file descriptor > > during global destruction. > > t/05event.t ................ ok > > t/06flags.t ................ 5/5 Warning: unable to close filehandle > > properly: Bad file descriptor during global destruction. > > Warning: unable to close filehandle properly: Bad file descriptor > > during global destruction. > > Warning: unable to close filehandle properly: Bad file descriptor > > during global destruction. > > Warning: unable to close filehandle properly: Bad file descriptor > > during global destruction. > > t/06flags.t ................ ok > > t/07noflags.t .............. ok > > t/08leftover-events.t ...... skipped: This is a problem with FSEvents > > itself, it seems > > t/09subprocess-events.t .... 1/2 Warning: unable to close filehandle > > properly: Bad file descriptor during global destruction. > > t/09subprocess-events.t .... ok > > t/10receive-all-changes.t .. 1/1 Warning: unable to close filehandle > > properly: Bad file descriptor during global destruction. > > t/10receive-all-changes.t .. ok > > All tests successful. > > Files=10, Tests=20, 25 wallclock secs ( 0.04 usr 0.03 sys + 0.68 > > cusr 1.27 csys = 2.02 CPU) > > Result: PASS > >
So I figured out what's happening with that test warning. Short version is that it's harmless - it's some data that we're leaking in watch() that Perl is trying to clean up at interpreter shutdown, but can't. Long version: Nearly five years ago, I made a change to fix a bug with double DESTROY. It involves the glob value returned by watch(). The unfortunate thing is that I screwed up and incremented the reference count of glob too many times, so that the glob returned by watch() is leaked and isn't cleaned up until interpreter shutdown. However, we probably can't fix this simply by lowering the reference count, since I think that would invalidate the file descriptor used for communication. I'll think of a fix and put out a release tonight.
On Sun Jan 01 17:19:57 2017, RHOELZ wrote: Show quoted text
> On Tue Oct 04 10:51:25 2016, deepak.gulati@booking.com wrote:
> > Yup, I already used a slightly different version of your suggestion > > to > > get it to build. > > > > } elsif ($os_version =~ /System Version:(?: macOS) (?:Server > > )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { > > return ($1, $2, $3 || 0); > > } > > > > Regarding the seriousness of test warnings - not sure. I’ve been > > running a script that uses Mac::FsEvents to observe a folder for > > changes > > and copy the changed files to several boxes. It seems to be working > > as > > expected for the past few minutes. > > > > Thank you for looking into it. > > > > On 4 Oct 2016, at 16:44, Andy Grundman via RT wrote: > >
> > > <URL: https://rt.cpan.org/Ticket/Display.html?id=118258 > > > > > > > Hmm, you can fix the version parser with this change to > > > MacVersion.pm: > > > > > > - if($os_version =~ /System Version:(?: Mac)? OS X (?:Server > > > )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { > > > + if($os_version =~ /System > > > Version:.+(?:(10)\.(\d+)(?:\.(\d+))?)/) > > > { > > > > > > The string is now "macOS" instead of "Mac OS X". Thanks Apple! I > > > tested this with: macOS 10.12 (16A320). > > > > > > $ gcc -v > > > Configured with: --prefix=/Library/Developer/CommandLineTools/usr > > > --with-gxx-include-dir=/usr/include/c++/4.2.1 > > > Apple LLVM version 8.0.0 (clang-800.0.38) > > > Target: x86_64-apple-darwin16.0.0 > > > Thread model: posix > > > InstalledDir: /Library/Developer/CommandLineTools/usr/bin > > > > > > I also had to remove the hints/darwin.pl file, or it would complain > > > about a missing SDK. The original point of the hints file was to > > > build > > > fat binaries that supported both 32 & 64-bit. This is ancient > > > history > > > these days and everything is 64-bit, and just using the compiler > > > flags > > > from Perl should be fine. In other words, just remove the file. > > > > > > With the above patch and removing the hints file, I can compile and > > > run the tests. Here's the test output. I'm not sure if the warnings > > > are serious or not. > > > > > > t/01use.t .................. ok > > > t/02pod.t .................. skipped: Test::Pod 1.14 required > > > t/03podcoverage.t .......... skipped: Test::Pod::Coverage 1.04 > > > required > > > t/04critic.t ............... skipped: Critic test only for > > > developers. > > > t/05event.t ................ 1/7 Warning: unable to close > > > filehandle > > > properly: Bad file descriptor during global destruction. > > > Warning: unable to close filehandle properly: Bad file descriptor > > > during global destruction. > > > Warning: unable to close filehandle properly: Bad file descriptor > > > during global destruction. > > > t/05event.t ................ ok > > > t/06flags.t ................ 5/5 Warning: unable to close > > > filehandle > > > properly: Bad file descriptor during global destruction. > > > Warning: unable to close filehandle properly: Bad file descriptor > > > during global destruction. > > > Warning: unable to close filehandle properly: Bad file descriptor > > > during global destruction. > > > Warning: unable to close filehandle properly: Bad file descriptor > > > during global destruction. > > > t/06flags.t ................ ok > > > t/07noflags.t .............. ok > > > t/08leftover-events.t ...... skipped: This is a problem with > > > FSEvents > > > itself, it seems > > > t/09subprocess-events.t .... 1/2 Warning: unable to close > > > filehandle > > > properly: Bad file descriptor during global destruction. > > > t/09subprocess-events.t .... ok > > > t/10receive-all-changes.t .. 1/1 Warning: unable to close > > > filehandle > > > properly: Bad file descriptor during global destruction. > > > t/10receive-all-changes.t .. ok > > > All tests successful. > > > Files=10, Tests=20, 25 wallclock secs ( 0.04 usr 0.03 sys + 0.68 > > > cusr 1.27 csys = 2.02 CPU) > > > Result: PASS > > >
> > > So I figured out what's happening with that test warning. Short > version is that it's harmless - it's some data that we're leaking in > watch() that Perl is trying to clean up at interpreter shutdown, but > can't. > > Long version: > > Nearly five years ago, I made a change to fix a bug with double > DESTROY. It involves the glob value returned by watch(). The > unfortunate thing is that I screwed up and incremented the reference > count of glob too many times, so that the glob returned by watch() is > leaked and isn't cleaned up until interpreter shutdown. However, we > probably can't fix this simply by lowering the reference count, since > I think that would invalidate the file descriptor used for > communication. I'll think of a fix and put out a release tonight.
Ok, no release tonight - I did a little bit of cleanup to make some of the error handling and resource cleanup, so I want to make sure this code is stable before shipping it. Would you folks care to try out what's on master on GitHub over the next few days to make sure I didn't break anything?
On Sun Jan 01 23:33:41 2017, RHOELZ wrote: Show quoted text
> On Sun Jan 01 17:19:57 2017, RHOELZ wrote:
> > On Tue Oct 04 10:51:25 2016, deepak.gulati@booking.com wrote:
> > > Yup, I already used a slightly different version of your suggestion > > > to > > > get it to build. > > > > > > } elsif ($os_version =~ /System Version:(?: macOS) (?:Server > > > )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { > > > return ($1, $2, $3 || 0); > > > } > > > > > > Regarding the seriousness of test warnings - not sure. I’ve been > > > running a script that uses Mac::FsEvents to observe a folder for > > > changes > > > and copy the changed files to several boxes. It seems to be working > > > as > > > expected for the past few minutes. > > > > > > Thank you for looking into it. > > > > > > On 4 Oct 2016, at 16:44, Andy Grundman via RT wrote: > > >
> > > > <URL: https://rt.cpan.org/Ticket/Display.html?id=118258 > > > > > > > > > Hmm, you can fix the version parser with this change to > > > > MacVersion.pm: > > > > > > > > - if($os_version =~ /System Version:(?: Mac)? OS X (?:Server > > > > )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { > > > > + if($os_version =~ /System > > > > Version:.+(?:(10)\.(\d+)(?:\.(\d+))?)/) > > > > { > > > > > > > > The string is now "macOS" instead of "Mac OS X". Thanks Apple! I > > > > tested this with: macOS 10.12 (16A320). > > > > > > > > $ gcc -v > > > > Configured with: > > > > --prefix=/Library/Developer/CommandLineTools/usr > > > > --with-gxx-include-dir=/usr/include/c++/4.2.1 > > > > Apple LLVM version 8.0.0 (clang-800.0.38) > > > > Target: x86_64-apple-darwin16.0.0 > > > > Thread model: posix > > > > InstalledDir: /Library/Developer/CommandLineTools/usr/bin > > > > > > > > I also had to remove the hints/darwin.pl file, or it would > > > > complain > > > > about a missing SDK. The original point of the hints file was to > > > > build > > > > fat binaries that supported both 32 & 64-bit. This is ancient > > > > history > > > > these days and everything is 64-bit, and just using the compiler > > > > flags > > > > from Perl should be fine. In other words, just remove the file. > > > > > > > > With the above patch and removing the hints file, I can compile > > > > and > > > > run the tests. Here's the test output. I'm not sure if the > > > > warnings > > > > are serious or not. > > > > > > > > t/01use.t .................. ok > > > > t/02pod.t .................. skipped: Test::Pod 1.14 required > > > > t/03podcoverage.t .......... skipped: Test::Pod::Coverage 1.04 > > > > required > > > > t/04critic.t ............... skipped: Critic test only for > > > > developers. > > > > t/05event.t ................ 1/7 Warning: unable to close > > > > filehandle > > > > properly: Bad file descriptor during global destruction. > > > > Warning: unable to close filehandle properly: Bad file > > > > descriptor > > > > during global destruction. > > > > Warning: unable to close filehandle properly: Bad file > > > > descriptor > > > > during global destruction. > > > > t/05event.t ................ ok > > > > t/06flags.t ................ 5/5 Warning: unable to close > > > > filehandle > > > > properly: Bad file descriptor during global destruction. > > > > Warning: unable to close filehandle properly: Bad file > > > > descriptor > > > > during global destruction. > > > > Warning: unable to close filehandle properly: Bad file > > > > descriptor > > > > during global destruction. > > > > Warning: unable to close filehandle properly: Bad file > > > > descriptor > > > > during global destruction. > > > > t/06flags.t ................ ok > > > > t/07noflags.t .............. ok > > > > t/08leftover-events.t ...... skipped: This is a problem with > > > > FSEvents > > > > itself, it seems > > > > t/09subprocess-events.t .... 1/2 Warning: unable to close > > > > filehandle > > > > properly: Bad file descriptor during global destruction. > > > > t/09subprocess-events.t .... ok > > > > t/10receive-all-changes.t .. 1/1 Warning: unable to close > > > > filehandle > > > > properly: Bad file descriptor during global destruction. > > > > t/10receive-all-changes.t .. ok > > > > All tests successful. > > > > Files=10, Tests=20, 25 wallclock secs ( 0.04 usr 0.03 sys + > > > > 0.68 > > > > cusr 1.27 csys = 2.02 CPU) > > > > Result: PASS > > > >
> > > > > > So I figured out what's happening with that test warning. Short > > version is that it's harmless - it's some data that we're leaking in > > watch() that Perl is trying to clean up at interpreter shutdown, but > > can't. > > > > Long version: > > > > Nearly five years ago, I made a change to fix a bug with double > > DESTROY. It involves the glob value returned by watch(). The > > unfortunate thing is that I screwed up and incremented the reference > > count of glob too many times, so that the glob returned by watch() is > > leaked and isn't cleaned up until interpreter shutdown. However, we > > probably can't fix this simply by lowering the reference count, since > > I think that would invalidate the file descriptor used for > > communication. I'll think of a fix and put out a release tonight.
> > Ok, no release tonight - I did a little bit of cleanup to make some of > the error handling and resource cleanup, so I want to make sure this > code is stable before shipping it. Would you folks care to try out > what's on master on GitHub over the next few days to make sure I > didn't break anything?
Have any of you had a chance to have a look at what's on master?
I did test your latest code on Sierra and it passed all tests for me. I think even my old version when last I touched it still basically worked surprisingly. I don't have any actual software that uses the module though, so I can't really test it further. In case you're interested, the original plan for this module was to use it in Logitech Media Server to watch for realtime changes to people's music libraries. We wanted this to work on all platforms, but getting a feature like that working reliably across Win/Mac/Linux/others turned out to be basically impossible. Not to mention that there was no solution of course for the common use case of having music on a mounted network share. I'm glad the module has proved useful though. Instead I ended up writing an IO::AIO-based directory scanner that can scan large directories fairly quickly to find anything that's changed.
Subject: Re: [External] [rt.cpan.org #118258] Problem compiling on macOS sierra
Date: Mon, 09 Jan 2017 22:07:23 +0100
To: "Rob Hoelz via RT" <bug-Mac-FSEvents [...] rt.cpan.org>
From: "Deepak Gulati" <deepak.gulati [...] booking.com>
I just tested it on macOS Sierra with my script and it works fine. On 9 Jan 2017, at 15:58, Rob Hoelz via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=118258 > > > On Sun Jan 01 23:33:41 2017, RHOELZ wrote:
>> On Sun Jan 01 17:19:57 2017, RHOELZ wrote:
>>> On Tue Oct 04 10:51:25 2016, deepak.gulati@booking.com wrote:
>>>> Yup, I already used a slightly different version of your suggestion >>>> to >>>> get it to build. >>>> >>>> } elsif ($os_version =~ /System Version:(?: macOS) (?:Server >>>> )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { >>>> return ($1, $2, $3 || 0); >>>> } >>>> >>>> Regarding the seriousness of test warnings - not sure. I’ve been >>>> running a script that uses Mac::FsEvents to observe a folder for >>>> changes >>>> and copy the changed files to several boxes. It seems to be working >>>> as >>>> expected for the past few minutes. >>>> >>>> Thank you for looking into it. >>>> >>>> On 4 Oct 2016, at 16:44, Andy Grundman via RT wrote: >>>>
>>>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=118258 > >>>>> >>>>> Hmm, you can fix the version parser with this change to >>>>> MacVersion.pm: >>>>> >>>>> - if($os_version =~ /System Version:(?: Mac)? OS X (?:Server >>>>> )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { >>>>> + if($os_version =~ /System >>>>> Version:.+(?:(10)\.(\d+)(?:\.(\d+))?)/) >>>>> { >>>>> >>>>> The string is now "macOS" instead of "Mac OS X". Thanks Apple! I >>>>> tested this with: macOS 10.12 (16A320). >>>>> >>>>> $ gcc -v >>>>> Configured with: >>>>> --prefix=/Library/Developer/CommandLineTools/usr >>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1 >>>>> Apple LLVM version 8.0.0 (clang-800.0.38) >>>>> Target: x86_64-apple-darwin16.0.0 >>>>> Thread model: posix >>>>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin >>>>> >>>>> I also had to remove the hints/darwin.pl file, or it would >>>>> complain >>>>> about a missing SDK. The original point of the hints file was to >>>>> build >>>>> fat binaries that supported both 32 & 64-bit. This is ancient >>>>> history >>>>> these days and everything is 64-bit, and just using the compiler >>>>> flags >>>>> from Perl should be fine. In other words, just remove the file. >>>>> >>>>> With the above patch and removing the hints file, I can compile >>>>> and >>>>> run the tests. Here's the test output. I'm not sure if the >>>>> warnings >>>>> are serious or not. >>>>> >>>>> t/01use.t .................. ok >>>>> t/02pod.t .................. skipped: Test::Pod 1.14 required >>>>> t/03podcoverage.t .......... skipped: Test::Pod::Coverage 1.04 >>>>> required >>>>> t/04critic.t ............... skipped: Critic test only for >>>>> developers. >>>>> t/05event.t ................ 1/7 Warning: unable to close >>>>> filehandle >>>>> properly: Bad file descriptor during global destruction. >>>>> Warning: unable to close filehandle properly: Bad file >>>>> descriptor >>>>> during global destruction. >>>>> Warning: unable to close filehandle properly: Bad file >>>>> descriptor >>>>> during global destruction. >>>>> t/05event.t ................ ok >>>>> t/06flags.t ................ 5/5 Warning: unable to close >>>>> filehandle >>>>> properly: Bad file descriptor during global destruction. >>>>> Warning: unable to close filehandle properly: Bad file >>>>> descriptor >>>>> during global destruction. >>>>> Warning: unable to close filehandle properly: Bad file >>>>> descriptor >>>>> during global destruction. >>>>> Warning: unable to close filehandle properly: Bad file >>>>> descriptor >>>>> during global destruction. >>>>> t/06flags.t ................ ok >>>>> t/07noflags.t .............. ok >>>>> t/08leftover-events.t ...... skipped: This is a problem with >>>>> FSEvents >>>>> itself, it seems >>>>> t/09subprocess-events.t .... 1/2 Warning: unable to close >>>>> filehandle >>>>> properly: Bad file descriptor during global destruction. >>>>> t/09subprocess-events.t .... ok >>>>> t/10receive-all-changes.t .. 1/1 Warning: unable to close >>>>> filehandle >>>>> properly: Bad file descriptor during global destruction. >>>>> t/10receive-all-changes.t .. ok >>>>> All tests successful. >>>>> Files=10, Tests=20, 25 wallclock secs ( 0.04 usr 0.03 sys + >>>>> 0.68 >>>>> cusr 1.27 csys = 2.02 CPU) >>>>> Result: PASS >>>>>
>>> >>> >>> So I figured out what's happening with that test warning. Short >>> version is that it's harmless - it's some data that we're leaking in >>> watch() that Perl is trying to clean up at interpreter shutdown, but >>> can't. >>> >>> Long version: >>> >>> Nearly five years ago, I made a change to fix a bug with double >>> DESTROY. It involves the glob value returned by watch(). The >>> unfortunate thing is that I screwed up and incremented the reference >>> count of glob too many times, so that the glob returned by watch() is >>> leaked and isn't cleaned up until interpreter shutdown. However, we >>> probably can't fix this simply by lowering the reference count, since >>> I think that would invalidate the file descriptor used for >>> communication. I'll think of a fix and put out a release tonight.
>> >> Ok, no release tonight - I did a little bit of cleanup to make some of >> the error handling and resource cleanup, so I want to make sure this >> code is stable before shipping it. Would you folks care to try out >> what's on master on GitHub over the next few days to make sure I >> didn't break anything?
> > Have any of you had a chance to have a look at what's on master?
Excellent! I'll cut a release some time this week, then. On Mon Jan 09 16:23:42 2017, deepak.gulati@booking.com wrote: Show quoted text
> I just tested it on macOS Sierra with my script and it works fine. > > On 9 Jan 2017, at 15:58, Rob Hoelz via RT wrote: >
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=118258 > > > > > On Sun Jan 01 23:33:41 2017, RHOELZ wrote:
> >> On Sun Jan 01 17:19:57 2017, RHOELZ wrote:
> >>> On Tue Oct 04 10:51:25 2016, deepak.gulati@booking.com wrote:
> >>>> Yup, I already used a slightly different version of your suggestion > >>>> to > >>>> get it to build. > >>>> > >>>> } elsif ($os_version =~ /System Version:(?: macOS) (?:Server > >>>> )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { > >>>> return ($1, $2, $3 || 0); > >>>> } > >>>> > >>>> Regarding the seriousness of test warnings - not sure. I’ve been > >>>> running a script that uses Mac::FsEvents to observe a folder for > >>>> changes > >>>> and copy the changed files to several boxes. It seems to be working > >>>> as > >>>> expected for the past few minutes. > >>>> > >>>> Thank you for looking into it. > >>>> > >>>> On 4 Oct 2016, at 16:44, Andy Grundman via RT wrote: > >>>>
> >>>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=118258 > > >>>>> > >>>>> Hmm, you can fix the version parser with this change to > >>>>> MacVersion.pm: > >>>>> > >>>>> - if($os_version =~ /System Version:(?: Mac)? OS X (?:Server > >>>>> )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { > >>>>> + if($os_version =~ /System > >>>>> Version:.+(?:(10)\.(\d+)(?:\.(\d+))?)/) > >>>>> { > >>>>> > >>>>> The string is now "macOS" instead of "Mac OS X". Thanks Apple! I > >>>>> tested this with: macOS 10.12 (16A320). > >>>>> > >>>>> $ gcc -v > >>>>> Configured with: > >>>>> --prefix=/Library/Developer/CommandLineTools/usr > >>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1 > >>>>> Apple LLVM version 8.0.0 (clang-800.0.38) > >>>>> Target: x86_64-apple-darwin16.0.0 > >>>>> Thread model: posix > >>>>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin > >>>>> > >>>>> I also had to remove the hints/darwin.pl file, or it would > >>>>> complain > >>>>> about a missing SDK. The original point of the hints file was to > >>>>> build > >>>>> fat binaries that supported both 32 & 64-bit. This is ancient > >>>>> history > >>>>> these days and everything is 64-bit, and just using the compiler > >>>>> flags > >>>>> from Perl should be fine. In other words, just remove the file. > >>>>> > >>>>> With the above patch and removing the hints file, I can compile > >>>>> and > >>>>> run the tests. Here's the test output. I'm not sure if the > >>>>> warnings > >>>>> are serious or not. > >>>>> > >>>>> t/01use.t .................. ok > >>>>> t/02pod.t .................. skipped: Test::Pod 1.14 required > >>>>> t/03podcoverage.t .......... skipped: Test::Pod::Coverage 1.04 > >>>>> required > >>>>> t/04critic.t ............... skipped: Critic test only for > >>>>> developers. > >>>>> t/05event.t ................ 1/7 Warning: unable to close > >>>>> filehandle > >>>>> properly: Bad file descriptor during global destruction. > >>>>> Warning: unable to close filehandle properly: Bad file > >>>>> descriptor > >>>>> during global destruction. > >>>>> Warning: unable to close filehandle properly: Bad file > >>>>> descriptor > >>>>> during global destruction. > >>>>> t/05event.t ................ ok > >>>>> t/06flags.t ................ 5/5 Warning: unable to close > >>>>> filehandle > >>>>> properly: Bad file descriptor during global destruction. > >>>>> Warning: unable to close filehandle properly: Bad file > >>>>> descriptor > >>>>> during global destruction. > >>>>> Warning: unable to close filehandle properly: Bad file > >>>>> descriptor > >>>>> during global destruction. > >>>>> Warning: unable to close filehandle properly: Bad file > >>>>> descriptor > >>>>> during global destruction. > >>>>> t/06flags.t ................ ok > >>>>> t/07noflags.t .............. ok > >>>>> t/08leftover-events.t ...... skipped: This is a problem with > >>>>> FSEvents > >>>>> itself, it seems > >>>>> t/09subprocess-events.t .... 1/2 Warning: unable to close > >>>>> filehandle > >>>>> properly: Bad file descriptor during global destruction. > >>>>> t/09subprocess-events.t .... ok > >>>>> t/10receive-all-changes.t .. 1/1 Warning: unable to close > >>>>> filehandle > >>>>> properly: Bad file descriptor during global destruction. > >>>>> t/10receive-all-changes.t .. ok > >>>>> All tests successful. > >>>>> Files=10, Tests=20, 25 wallclock secs ( 0.04 usr 0.03 sys + > >>>>> 0.68 > >>>>> cusr 1.27 csys = 2.02 CPU) > >>>>> Result: PASS > >>>>>
> >>> > >>> > >>> So I figured out what's happening with that test warning. Short > >>> version is that it's harmless - it's some data that we're leaking in > >>> watch() that Perl is trying to clean up at interpreter shutdown, but > >>> can't. > >>> > >>> Long version: > >>> > >>> Nearly five years ago, I made a change to fix a bug with double > >>> DESTROY. It involves the glob value returned by watch(). The > >>> unfortunate thing is that I screwed up and incremented the reference > >>> count of glob too many times, so that the glob returned by watch() is > >>> leaked and isn't cleaned up until interpreter shutdown. However, we > >>> probably can't fix this simply by lowering the reference count, since > >>> I think that would invalidate the file descriptor used for > >>> communication. I'll think of a fix and put out a release tonight.
> >> > >> Ok, no release tonight - I did a little bit of cleanup to make some of > >> the error handling and resource cleanup, so I want to make sure this > >> code is stable before shipping it. Would you folks care to try out > >> what's on master on GitHub over the next few days to make sure I > >> didn't break anything?
> > > > Have any of you had a chance to have a look at what's on master?
I just released version 0.13 - please let me know if you encounter any further problems with it! On Tue Jan 17 09:28:49 2017, RHOELZ wrote: Show quoted text
> Excellent! I'll cut a release some time this week, then. > > On Mon Jan 09 16:23:42 2017, deepak.gulati@booking.com wrote:
> > I just tested it on macOS Sierra with my script and it works fine. > > > > On 9 Jan 2017, at 15:58, Rob Hoelz via RT wrote: > >
> > > <URL: https://rt.cpan.org/Ticket/Display.html?id=118258 > > > > > > > On Sun Jan 01 23:33:41 2017, RHOELZ wrote:
> > >> On Sun Jan 01 17:19:57 2017, RHOELZ wrote:
> > >>> On Tue Oct 04 10:51:25 2016, deepak.gulati@booking.com wrote:
> > >>>> Yup, I already used a slightly different version of your suggestion > > >>>> to > > >>>> get it to build. > > >>>> > > >>>> } elsif ($os_version =~ /System Version:(?: macOS) (?:Server > > >>>> )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { > > >>>> return ($1, $2, $3 || 0); > > >>>> } > > >>>> > > >>>> Regarding the seriousness of test warnings - not sure. I’ve been > > >>>> running a script that uses Mac::FsEvents to observe a folder for > > >>>> changes > > >>>> and copy the changed files to several boxes. It seems to be working > > >>>> as > > >>>> expected for the past few minutes. > > >>>> > > >>>> Thank you for looking into it. > > >>>> > > >>>> On 4 Oct 2016, at 16:44, Andy Grundman via RT wrote: > > >>>>
> > >>>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=118258 > > > >>>>> > > >>>>> Hmm, you can fix the version parser with this change to > > >>>>> MacVersion.pm: > > >>>>> > > >>>>> - if($os_version =~ /System Version:(?: Mac)? OS X (?:Server > > >>>>> )?(?:(10)\.(\d+)(?:\.(\d+))?)/) { > > >>>>> + if($os_version =~ /System > > >>>>> Version:.+(?:(10)\.(\d+)(?:\.(\d+))?)/) > > >>>>> { > > >>>>> > > >>>>> The string is now "macOS" instead of "Mac OS X". Thanks Apple! I > > >>>>> tested this with: macOS 10.12 (16A320). > > >>>>> > > >>>>> $ gcc -v > > >>>>> Configured with: > > >>>>> --prefix=/Library/Developer/CommandLineTools/usr > > >>>>> --with-gxx-include-dir=/usr/include/c++/4.2.1 > > >>>>> Apple LLVM version 8.0.0 (clang-800.0.38) > > >>>>> Target: x86_64-apple-darwin16.0.0 > > >>>>> Thread model: posix > > >>>>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin > > >>>>> > > >>>>> I also had to remove the hints/darwin.pl file, or it would > > >>>>> complain > > >>>>> about a missing SDK. The original point of the hints file was to > > >>>>> build > > >>>>> fat binaries that supported both 32 & 64-bit. This is ancient > > >>>>> history > > >>>>> these days and everything is 64-bit, and just using the compiler > > >>>>> flags > > >>>>> from Perl should be fine. In other words, just remove the file. > > >>>>> > > >>>>> With the above patch and removing the hints file, I can compile > > >>>>> and > > >>>>> run the tests. Here's the test output. I'm not sure if the > > >>>>> warnings > > >>>>> are serious or not. > > >>>>> > > >>>>> t/01use.t .................. ok > > >>>>> t/02pod.t .................. skipped: Test::Pod 1.14 required > > >>>>> t/03podcoverage.t .......... skipped: Test::Pod::Coverage 1.04 > > >>>>> required > > >>>>> t/04critic.t ............... skipped: Critic test only for > > >>>>> developers. > > >>>>> t/05event.t ................ 1/7 Warning: unable to close > > >>>>> filehandle > > >>>>> properly: Bad file descriptor during global destruction. > > >>>>> Warning: unable to close filehandle properly: Bad file > > >>>>> descriptor > > >>>>> during global destruction. > > >>>>> Warning: unable to close filehandle properly: Bad file > > >>>>> descriptor > > >>>>> during global destruction. > > >>>>> t/05event.t ................ ok > > >>>>> t/06flags.t ................ 5/5 Warning: unable to close > > >>>>> filehandle > > >>>>> properly: Bad file descriptor during global destruction. > > >>>>> Warning: unable to close filehandle properly: Bad file > > >>>>> descriptor > > >>>>> during global destruction. > > >>>>> Warning: unable to close filehandle properly: Bad file > > >>>>> descriptor > > >>>>> during global destruction. > > >>>>> Warning: unable to close filehandle properly: Bad file > > >>>>> descriptor > > >>>>> during global destruction. > > >>>>> t/06flags.t ................ ok > > >>>>> t/07noflags.t .............. ok > > >>>>> t/08leftover-events.t ...... skipped: This is a problem with > > >>>>> FSEvents > > >>>>> itself, it seems > > >>>>> t/09subprocess-events.t .... 1/2 Warning: unable to close > > >>>>> filehandle > > >>>>> properly: Bad file descriptor during global destruction. > > >>>>> t/09subprocess-events.t .... ok > > >>>>> t/10receive-all-changes.t .. 1/1 Warning: unable to close > > >>>>> filehandle > > >>>>> properly: Bad file descriptor during global destruction. > > >>>>> t/10receive-all-changes.t .. ok > > >>>>> All tests successful. > > >>>>> Files=10, Tests=20, 25 wallclock secs ( 0.04 usr 0.03 sys + > > >>>>> 0.68 > > >>>>> cusr 1.27 csys = 2.02 CPU) > > >>>>> Result: PASS > > >>>>>
> > >>> > > >>> > > >>> So I figured out what's happening with that test warning. Short > > >>> version is that it's harmless - it's some data that we're leaking in > > >>> watch() that Perl is trying to clean up at interpreter shutdown, but > > >>> can't. > > >>> > > >>> Long version: > > >>> > > >>> Nearly five years ago, I made a change to fix a bug with double > > >>> DESTROY. It involves the glob value returned by watch(). The > > >>> unfortunate thing is that I screwed up and incremented the reference > > >>> count of glob too many times, so that the glob returned by watch() is > > >>> leaked and isn't cleaned up until interpreter shutdown. However, we > > >>> probably can't fix this simply by lowering the reference count, since > > >>> I think that would invalidate the file descriptor used for > > >>> communication. I'll think of a fix and put out a release tonight.
> > >> > > >> Ok, no release tonight - I did a little bit of cleanup to make some of > > >> the error handling and resource cleanup, so I want to make sure this > > >> code is stable before shipping it. Would you folks care to try out > > >> what's on master on GitHub over the next few days to make sure I > > >> didn't break anything?
> > > > > > Have any of you had a chance to have a look at what's on master?
> >