win32 specific Win32::IPC dependency missing #40

rurban · 2015-06-07T22:14:15Z

With EUMM it would be trivial to add the required MSWin32 dependency Win32::IPC,
but I have no idea how to add it your build system. Is there only Meta, or is there more?

It fails to build on windows smokers which do not have Win32::IPC installed.
e.g. http://www.cpantesters.org/cpan/report/d3d8beb6-6dbd-1014-9f5e-99bfe3f2b8ca

wbraswell · 2019-01-22T18:43:00Z

@sisyphus
How can we properly add Win32::IPC as a dependency of Inline::C?
If you just tell me what to do, then I will create a pull request etc.

sisyphus · 2019-01-23T00:53:03Z

I don't know. Does anyone know what the problem actually is? First thing I do whenever I've just built a new perl on Windows (eg 4 configurations of 5.29.7, as I did yesterday) is to run 'cpan -fi Inline::C'. And that always works fine for me. I use force because there's a couple of Inline::C tests that fail near the end. Those failures don't bother me, and no-one else experiences them, so I'm quite content to leave them alone and keep using force. So ... my first thought was Win32::IPC might require force, but that's not the case. I've just manually removed if from a couple of the 5.29.7 builds that I created yesterday and then successfully ran 'cpan -i Win32::IPC'. Does anyone know the reason that Win32::IPC is not being installed on these Windows smokers when Inlline::C is built ? Is it a deficiency in Inline::C ? ... or a deficiency in the smoking environment ? Cheers, Rob

…

On Wed, Jan 23, 2019 at 5:43 AM William N. Braswell, Jr. < ***@***.***> wrote: @sisyphus <https://github.com/sisyphus> How can we properly add Win32::IPC as a dependency of Inline::C? If you just tell me what to do, then I will create a pull request etc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEdvHDINZR61TklJQ-elHCz5TKYAQ1uks5vF1u0gaJpZM4E68uV> .

wbraswell · 2019-01-23T02:59:37Z

Only 1 of the failing Win32 tests is due to something other than missing Win32::Mutex; it appears to have an old incompatible version of Inline installed which is not related to this issue:
http://www.cpantesters.org/cpan/report/cbf280e9-6bf9-1014-bc51-f8d3665dec09

For Inline::C v0.78, there are 57 total Win32 tests, of which 37 are passing and (as mentioned) 20 are failing. We have 19/57 which is a 33% failure rate due only to missing Win32::Mutex. This seems to indicate that is is a relatively common occurrence that Win32::Mutex is NOT installed in Windows Perl by default, so we SHOULD be explicitly adding it to the Inline::C dependencies.

@sisyphus
Is my reasoning valid here?

sisyphus · 2019-01-23T04:52:09Z

Your reasoning is quite valid. However, I think we've already explicitly added Win32::Mutex to the Inline::C dependencies for Windows via this entry in the Makefile.PL: if ( $^O eq 'MSWin32' ) { $WriteMakefileArgs{PREREQ_PM}{'Win32::Mutex'} = '1.09'; } And that's working fine for me. Every time I install Inline::C on a fresh build of perl it installs Win32::Mutex along with a heap of other dependencies. How come its working fine for me, but not for smokers ? Is it because the smokers additionally require an entry for Win32::Mutex somewhere in one of the "META" files, as I think Reini might have been suggesting ? Cheers, Rob

…

wbraswell · 2019-01-23T05:24:58Z

@ingydotnet @perlpunk
Can you please give us the authoritative answer on where we need to put Inline::C dependencies, specifically Win32::Mutex?

rurban · 2019-01-23T14:13:24Z

This is a normal EUMM project, hence the deps need to be specified as in every other EUMM project. The PREREQ_PM array and optionally for the YAML and JSON generation the META entries. See perldoc ExtUtils::MakeMaker. Check if meta generation is broken by looking at the YAML and JSON files in the tarball. Am Mi., 23. Jan. 2019, 06:25 hat William N. Braswell, Jr. < notifications@github.com> geschrieben:

…

@ingydotnet <https://github.com/ingydotnet> @perlpunk <https://github.com/perlpunk> Can you please give us the authoritative answer on where we need to put Inline::C dependencies, specifically Win32::Mutex? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACjUf9DGs-7iOsM1diVhnknx_4QsiJwks5vF_IrgaJpZM4E68uV> .

wbraswell · 2019-01-23T16:46:07Z

Win32::Mutex DOES appear in the following files:

https://github.com/ingydotnet/inline-c-pm/blob/master/Meta#L36-L38 (GitHub only, not on CPAN)

win32:
  requires:
    Win32::Mutex: 1.09

https://st.aticpan.org/source/TINITA/Inline-C-0.78/Makefile.PL (CPAN only, not on GitHub)

if ( $^O eq 'MSWin32' ) {
	$WriteMakefileArgs{PREREQ_PM}{'Win32::Mutex'} = '1.09';
}

Win32::Mutex does NOT appear in the following files:

https://st.aticpan.org/source/TINITA/Inline-C-0.78/META.json (CPAN only, not on GitHub)

https://st.aticpan.org/source/TINITA/Inline-C-0.78/META.yml (CPAN only, not on GitHub)

@rurban @sisyphus
Does this mean there is an error in our CPAN release process which has failed to properly generate the "META.json" and "META.yml" files???

rurban · 2019-01-23T21:34:51Z

Exactly. I will look into that later, I'm away.

perlpunk · 2019-01-24T17:59:10Z

It looks to me like the META.yaml/META.json files are correct.

Win32::Mutex is only needed on Win32, but AFAIK CPAN::Meta currently has no way to express such dynamic dependencies. We can't put it into the static META files because we don't want this on other operating systems.

The only thing you can specify in META is dynamic_config: 1:

"A boolean flag indicating whether a Build.PL or Makefile.PL (or similar) must be executed to determine prerequisites."
https://metacpan.org/pod/CPAN::Meta::Spec#dynamic_config

And the Makefile.PL has the dependency.

Both META.yaml/META.json have dynamic_config: 1, so I wonder why smokers don't adhere to that.
https://metacpan.org/source/TINITA/Inline-C-0.78/META.json#L6
https://metacpan.org/source/TINITA/Inline-C-0.78/META.yml#L16

edit: Interesting is, that the dependency is actually recognized. Look into this report:
http://www.cpantesters.org/cpan/report/99647050-6c1d-1014-ae7a-c367e3863dc7

Prerequisite modules loaded:

requires:

    Module                  Need     Have    
    ----------------------- -------- --------
    ExtUtils::MakeMaker     7.00     7.34    
    File::Spec              0.8      3.47    
    Inline                  0.79     0.80    
    Parse::RecDescent       1.967009 1.967009
    Pegex                   0.58     0.70    
    perl                    5.010000 5.012002
    Win32::Mutex            1.09     1.09

And it's also in PERL5LIB:
PERL5LIB = C:\strawberry\cpan\build\Win32-IPC-1.11-0/blib/arch;C:\strawberry\cpan\build\Win32-IPC-1.11-0/blib/lib;...

perlpunk · 2019-01-24T18:43:17Z

So PERL5LIB correctly contains Win32-IPC. But as we can see from the error message the directories reported in PERL5LIB get lost:

Can't locate Win32/Mutex.pm in @INC
 (@INC contains: C:\strawberry\cpan\build\Inline-0.80-0/blib/lib/
 C:\strawberry\cpan\build\Inline-C-0.79_001-0\blib\lib
 C:\strawberry\cpan\build\Inline-C-0.79_001-0\blib\arch
 C:\strawberry\cpan\build\Inline-0.80-0/blib/arch
 C:\strawberry\cpan\build\Inline-0.80-0/blib/lib
 C:/strawberry/perl/site/lib
 C:/strawberry/perl/site/lib
 C:/strawberry/perl/vendor/lib
 C:/strawberry/perl/lib .) at C:/strawberry/perl/lib/if.pm line 13.

So why does PERL5LIB get lost? I suspect this happens here:
https://metacpan.org/source/TINITA/Inline-C-0.78/lib/Inline/C.pm#L880
as this is the only place where perl calls itself.

wbraswell · 2019-01-24T18:46:16Z

@perlpunk
Wow great sleuthing! I don't have any way to test this myself, but perhaps @sisyphus or @rurban do?

sisyphus · 2019-01-25T00:51:54Z

Yes - PERL5LIB is certainly being blasted out of existence, though I can't yet see how that happens. On my Windows box I've moved Win32::Mutex to C:/sislib/lib, which is a directory that's in $ENV{PERL5LIB}. And I then get the same error as the smokers report. I wondered whether it might be some quirk of using the 'if' module .... but it's not that. I don't see that perl calling itself is an issue. The following just prints out the same (correct) @inc twice: C:\>perl -le "print for @inc; system 'perl', '-le', 'print for @inc';" C:/sislib/lib C:/_64/blead-5.29.7-p/site/lib C:/_64/blead-5.29.7-p/lib C:/sislib/lib C:/_64/blead-5.29.7-p/site/lib C:/_64/blead-5.29.7-p/lib I'll keep looking as time permits. Any thoughts ? Cheers, Rob

…

On Fri, Jan 25, 2019 at 5:43 AM Tina Müller (tinita) < ***@***.***> wrote: So PERL5LIB correctly contains Win32-IPC. But as we can see from the error message the directories reported in PERL5LIB get lost: Can't locate Win32/Mutex.pm in @inc ***@***.*** contains: C:\strawberry\cpan\build\Inline-0.80-0/blib/lib/ C:\strawberry\cpan\build\Inline-C-0.79_001-0\blib\lib C:\strawberry\cpan\build\Inline-C-0.79_001-0\blib\arch C:\strawberry\cpan\build\Inline-0.80-0/blib/arch C:\strawberry\cpan\build\Inline-0.80-0/blib/lib C:/strawberry/perl/site/lib C:/strawberry/perl/site/lib C:/strawberry/perl/vendor/lib C:/strawberry/perl/lib .) at C:/strawberry/perl/lib/if.pm line 13. So why does PERL5LIB get lost? I suspect this happens here: https://metacpan.org/source/TINITA/Inline-C-0.78/lib/Inline/C.pm#L880 as this is the only place where perl calls itself. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEdvP3LBVcnwo5o_LvXILPETN_HWqFYks5vGf7FgaJpZM4E68uV> .

wbraswell · 2019-01-25T02:30:51Z

@bulk88
Any thoughts on why PERL5LIB is getting lost here???

sisyphus · 2019-01-25T05:44:18Z

PERL5LIB gets clobbered in Inline.pm's create_config_file() at line 810: local $ENV{PERL5LIB} if defined $ENV{PERL5LIB}; At least, if I comment out that line, everything goes ok and the test suite passes - except for t/27inline_maker.t, which always fail for me, irrespective. Might we safely replace that line with: unless($^O =~ /MSWin32/I) { local $ENV{PERL5LIB} if defined $ENV{PERL5LIB}; } What might such a change break ? Who understands the point of localizing PERL5LIB ? I notice that PERL5OPT is also localized. Might that bight us at some stage ? Cheers, Rob

…

On Fri, Jan 25, 2019 at 1:31 PM William N. Braswell, Jr. < ***@***.***> wrote: @bulk88 <https://github.com/bulk88> Any thoughts on why PERL5LIB is getting lost here??? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEdvPmNgULRenQRJU8X3AtpxuRJHf_Iks5vGmxbgaJpZM4E68uV> .

perlpunk · 2019-01-25T08:48:23Z

@sisyphus interesting.
Maybe this code is somehow broken?
https://metacpan.org/source/INGY/Inline-0.80/lib/Inline.pm#L822

my @_inc = map { "-I$_" }
($inline,
 grep {(-d File::Spec->catdir($_,"Inline") or
 -d File::Spec->catdir($_,"auto","Inline") or 
 -e File::Spec->catdir($_,"Parse/RecDescent.pm"))} @INC);
system $perl, @_inc, "-MInline=_CONFIG_", "-e1", "$dir"
...

As far as I can see this should actually replace the need for using PERL5LIB, but maybe Mutex.pm ends up somewhere else?
Does it work if you add "Win32/Mutex.pm" to that grep?

Edit: but I also don't see why one would delete PERL5LIB and then use only specific directories from @INC.
@ingydotnet any idea?

sisyphus · 2019-01-25T11:02:22Z

Aaah, yes ... adding or -e File::Spec->catdir($_,"Win32/Mutex.pm") to the grep conditions has the desired effect .... and also feels like the right thing to do ;-) Pushed to git in commit 3b4ea7b92fdf23035000e09e829f22cc934b55c0 Seems a bit odd to be taking care of Inline::C issues inside the Inline module, but the relationship has always been a bit like that (for some definition of "bit like that"). Please feel free to revert/modify if what I've done is incorrect. Nice work, Tina. Kudos to Will for making things happen. Cheers, Rob.

…

On Fri, Jan 25, 2019 at 7:48 PM Tina Müller (tinita) < ***@***.***> wrote: @sisyphus <https://github.com/sisyphus> interesting. Maybe this code is somehow broken? https://metacpan.org/source/INGY/Inline-0.80/lib/Inline.pm#L822 my @_inc = map { "-I$_" } ($inline, grep {(-d File::Spec->catdir($_,"Inline") or -d File::Spec->catdir($_,"auto","Inline") or -e File::Spec->catdir($_,"Parse/RecDescent.pm"))} @inc); system $perl, @_inc, "-MInline=_CONFIG_", "-e1", "$dir" ... As far as I can see this should actually replace the need for using PERL5LIB, but maybe Mutex.pm ends up somewhere else? Does it work if you add "Win32/Mutex.pm" to that grep? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEdvNbkobI8Bk2qqSB1O3kuZOBeysNyks5vGsTXgaJpZM4E68uV> .

mohawk2 · 2019-01-25T12:52:36Z

I expect Inline doesn't rely on PERL5LIB in case the build stage gets run later, with different environment. However, there is no earthly reason why it's doing the grep it's doing: it should capture the whole of @INC. @sisyphus, disagree?

wbraswell · 2019-01-25T17:16:18Z

@sisyphus @perlpunk
great job with this fix!

Out of curiosity, why do we have the strategy of making case-by-case exceptions such as "Parse/RecDescent.pm" or "Win32/Mutex.pm", instead of just NOT clobbering PERL5LIB in the first place?

sisyphus · 2019-01-26T01:40:01Z

Do you mean that we could simply populate @_inc with: my @_inc = map { "-I$_" } @inc; That seems to be working fine for me, both inside and outside of Test::Harness. (At least it's fine with Inline::C - I haven't yet tried building Inline itself with that change.) It assumes that everything that needs to be in @inc is already there - and that seems to be the case. I suspect the original grepping was done because there were some directories that were not in @inc, but needed to be included. (That now seems to NOT be the case. Is perl doing something differently now or was it always like that ?) I'll test it over a range of perl versions (windows only) and get back. Cheers, Rob

…

On Fri, Jan 25, 2019 at 11:52 PM mohawk2 ***@***.***> wrote: I expect Inline doesn't rely on PERL5LIB in case the build stage gets run later, with different environment. However, there is no earthly reason why it's doing the grep it's doing: it should capture the whole of @inc. @sisyphus <https://github.com/sisyphus>, disagree? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEdvLc7PMMm7Sf9lG7KdyZkX7CPuBt1ks5vGv4UgaJpZM4E68uV> .

wbraswell · 2019-01-26T02:18:41Z

@sisyphus
Yes I believe that is approximately what I am saying, although I do not know if this is actually correct or not...

sisyphus · 2019-01-26T05:53:59Z

That post of mine was written in response to mohawk2's. Looks like I managed to get it stuck in the wrong place in the queue ;-) Anyway, the simplified method of assigning to @_inc with: my @_inc = map { "-I$_" } @inc; hasn't broken any Inline-80 or Inline-C-0.79_001 tests for me - tested on Windows for perls 5.10.0 through to 5.28.0. So I don't mind if someone wants to commit that to git, or just leave us go down the path of adding Win32::Mutex to the grep list. It would be nice to get rid of the localizing of PERL5LIB and that probably wouldn't break any tests either. But I can't help feeling that there's a valid case for localizing PERL5LIB under some usage case, even though I can't properly grasp just how that plays out. So ... we need to get a new version of Inline released before we can get the Win32 smokers to start testing Inline::C. Cheers, Rob

…

On Sat, Jan 26, 2019 at 1:19 PM William N. Braswell, Jr. < ***@***.***> wrote: @sisyphus <https://github.com/sisyphus> Yes I believe that is approximately what I am saying, although I do not know if this is actually correct or not... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEdvPOiql7n6W1FNN5L0v6t6XP3trquks5vG7sBgaJpZM4E68uV> .

wbraswell · 2019-01-26T06:34:02Z

@sisyphus
Okay sorry I got confused with the mixed up messages. :-P
I vote for releasing the File::Spec->catdir($_,"Win32/Mutex.pm") code now on CPAN to see if it solves all the Win32 failures w/out causing any other unexpected failures.
If all goes well, we could then try another CPAN testers release with the experimental generic my @_inc = map { "-I$_" } @inc; code, which could in theory cause unforeseen issues because we are disabling all the grep behavior w/out really understanding why.
(Either way, we are already due for another CPAN dev release to test the latest fix for the still-pending include dir issue #72)

perlpunk · 2019-01-26T10:53:09Z

Yes, this was also my question. Why don't we keep @INC completely and perform a grep?
But just releasing the Win32::Mutex fix would help us now going forward with Inline::C, I agree.

@ingydotnet do you want me to do a release of Inline? Or who should & can do one? I would need a commit bit and CPAN comaint.
I see there have been two dev releases in 2018 without a following regular release.
We need a regular release so that smokers of Inline::C install it. Any reasons not to do one?

perlpunk · 2019-01-26T12:08:34Z

I just released 0.79_002. I guess it will take some more time until we can get an Inline.pm release out.

wbraswell · 2019-01-26T18:37:01Z

@sisyphus Do you still have a CPAN commit bit for Inline? If so, can you please make a CPAN dev release of Inline v0.80_03 w/ your latest commit ingydotnet/inline-pm@3b4ea7b ?
(I assume it is preferred to make a CPAN dev release first to make sure the "Win32::Mutex" code does not accidentally break anything, then we can make a full CPAN release in a day or two if all is well.)

sisyphus · 2019-01-27T03:25:31Z

Seems that I have commit bits for both Inline and Inline::C, but I'm not going to get involved in making releases. Cheers, Rob

…

On Sun, Jan 27, 2019 at 5:37 AM William N. Braswell, Jr. < ***@***.***> wrote: @sisyphus <https://github.com/sisyphus> Do you still have a CPAN commit bit for Inline? If so, can you please make a CPAN dev release of Inline v0.80_03 w/ your latest commit ***@***.*** <ingydotnet/inline-pm@3b4ea7b> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEdvGrEWqreKxWVOzoU9baU3dtr7cx8ks5vHKBNgaJpZM4E68uV> .

wbraswell · 2019-02-19T04:57:35Z

Inline v0.81 has been released, which includes this commit:
ingydotnet/inline-pm@3b4ea7b

@sisyphus says "Inline-0.81 looking fine here - and enabling Win32::Mutex to be found via PER5LIB on Windows."
#72 (comment)

Does this mean we can close this issue as being correctly resolved? How do we know for sure if the issue is actually solved?

sisyphus · 2019-02-27T03:22:10Z

The only indication that it's solved will be the absence of the error. However, the fix is tested only when someone relies on PERL5LIB to locate Win32::Mutex - and I'm certainly not interested in creating a test script that emulates those conditions. I did wonder whether similar problems might arise if the Pegex modules were being located via PERL5LIB, but my testing on Windows 10 indicates there's no such problem. Probably should wait 'til at least the next stable release of Inline::C has been tested by the affected smoker(s) before closing. Cheers, Rob

…

On Tue, Feb 19, 2019 at 3:57 PM William N. Braswell, Jr. < ***@***.***> wrote: Inline v0.81 has been released, which includes this commit: ***@***.*** <ingydotnet/inline-pm@3b4ea7b> @sisyphus <https://github.com/sisyphus> says "Inline-0.81 looking fine here - and enabling Win32::Mutex to be found via PER5LIB on Windows." #72 (comment) <#72 (comment)> Does this mean we can close this issue as being correctly resolved? How do we know for sure if the issue is actually solved? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEdvHZxa16b1Jk_6xlDtdi74avcXNZ0ks5vO4RAgaJpZM4E68uV> .

wbraswell · 2019-03-06T04:14:42Z

@sisyphus
Okay sounds like a good plan! :-)

mohawk2 · 2019-04-02T18:29:36Z

Can this be closed?

wbraswell · 2019-04-02T18:56:19Z

I think the plan is to keep this issue open until Inline::C 0.79 is fully released on CPAN and we have waited a sufficient period of time for CPAN testers to report errors.

perlpunk · 2019-04-27T09:15:24Z

Ok, so I think it can be closed :)

wbraswell · 2019-05-06T19:32:39Z

Yes I agree this issue can be closed for now, so far all Win32 tests are passing for Inline 0.80:
http://matrix.cpantesters.org/?dist=Inline-C%200.80;os=mswin32;reports=1

wbraswell mentioned this issue Jan 22, 2019

validate() Incorrectly Appends FindBin As -I Include Dir #72

Open

perlpunk closed this as completed Apr 27, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

win32 specific Win32::IPC dependency missing #40

win32 specific Win32::IPC dependency missing #40

rurban commented Jun 7, 2015

wbraswell commented Jan 22, 2019

sisyphus commented Jan 23, 2019 via email

wbraswell commented Jan 23, 2019

sisyphus commented Jan 23, 2019 via email

wbraswell commented Jan 23, 2019

rurban commented Jan 23, 2019 via email

wbraswell commented Jan 23, 2019

rurban commented Jan 23, 2019

perlpunk commented Jan 24, 2019 •

edited

perlpunk commented Jan 24, 2019

wbraswell commented Jan 24, 2019

sisyphus commented Jan 25, 2019 via email

wbraswell commented Jan 25, 2019

sisyphus commented Jan 25, 2019 via email

perlpunk commented Jan 25, 2019 •

edited

sisyphus commented Jan 25, 2019 via email

mohawk2 commented Jan 25, 2019

wbraswell commented Jan 25, 2019

sisyphus commented Jan 26, 2019 via email

wbraswell commented Jan 26, 2019

sisyphus commented Jan 26, 2019 via email

wbraswell commented Jan 26, 2019

perlpunk commented Jan 26, 2019 •

edited

perlpunk commented Jan 26, 2019

wbraswell commented Jan 26, 2019 •

edited

sisyphus commented Jan 27, 2019 via email

wbraswell commented Feb 19, 2019

sisyphus commented Feb 27, 2019 via email

wbraswell commented Mar 6, 2019

mohawk2 commented Apr 2, 2019

wbraswell commented Apr 2, 2019

perlpunk commented Apr 27, 2019

wbraswell commented May 6, 2019

win32 specific Win32::IPC dependency missing #40

win32 specific Win32::IPC dependency missing #40

Comments

rurban commented Jun 7, 2015

wbraswell commented Jan 22, 2019

sisyphus commented Jan 23, 2019 via email

wbraswell commented Jan 23, 2019

sisyphus commented Jan 23, 2019 via email

wbraswell commented Jan 23, 2019

rurban commented Jan 23, 2019 via email

wbraswell commented Jan 23, 2019

rurban commented Jan 23, 2019

perlpunk commented Jan 24, 2019 • edited

perlpunk commented Jan 24, 2019

wbraswell commented Jan 24, 2019

sisyphus commented Jan 25, 2019 via email

wbraswell commented Jan 25, 2019

sisyphus commented Jan 25, 2019 via email

perlpunk commented Jan 25, 2019 • edited

sisyphus commented Jan 25, 2019 via email

mohawk2 commented Jan 25, 2019

wbraswell commented Jan 25, 2019

sisyphus commented Jan 26, 2019 via email

wbraswell commented Jan 26, 2019

sisyphus commented Jan 26, 2019 via email

wbraswell commented Jan 26, 2019

perlpunk commented Jan 26, 2019 • edited

perlpunk commented Jan 26, 2019

wbraswell commented Jan 26, 2019 • edited

sisyphus commented Jan 27, 2019 via email

wbraswell commented Feb 19, 2019

sisyphus commented Feb 27, 2019 via email

wbraswell commented Mar 6, 2019

mohawk2 commented Apr 2, 2019

wbraswell commented Apr 2, 2019

perlpunk commented Apr 27, 2019

wbraswell commented May 6, 2019

perlpunk commented Jan 24, 2019 •

edited

perlpunk commented Jan 25, 2019 •

edited

perlpunk commented Jan 26, 2019 •

edited

wbraswell commented Jan 26, 2019 •

edited