Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec
Set by moderator on 10 August 2017.
01:52 ilbot3 joined
moderator Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec
02:19 sivoais joined, sjn joined 02:20 lizmat joined, ranguard joined 02:29 camelia joined
ugexe github.com/sergot/http-useragent/b...nt.pm6#L30 02:48
02:48 ribasushi joined
ugexe github.com/sergot/http-useragent/b...se.pm6#L13 02:48
X::HTTP::Response is declared in both modules, one inherits from Exception and one inherits from X::HTTP is Exception 02:49
But again this works for just `use HTTP::UserAgent`. once its `use Bailador; use HTTP::UserAgent;` this becomes a problem. So what does Bailador bring to cause a problem? I see two interesting things: X:: namespace and ::Response namespace (both dists use these). I suspect one of these changes conditional outcomes in merge_globals (is_stub or =:=) to ultimately merge differently than without Bailador 02:56
im kinda just taking shots in the dark, but the stash difference with/without Bailador before merge failure has only 2 differences - :Bailador(X::Bailador) and :Template(X::Template) stash entries 03:00
but that bit might be irrelevant... i'm not totally sure its *exactly* the same spot 03:01
thats its. by removing X::HTTP::Response from HTTP::UserAgent it all loads fine. it looks like it was done like this to avoid circular dependency on base exception class X::HTTP (defined in HTTP::UserAgent, but would then need to be used in HTTP::Response which already is used by HTTP::UserAgent) 03:11
i wonder if its the X:: or ::Response from Bailador that causes it 03:23
07:03 lizmat joined 07:38 lizmat joined 07:49 lizmat joined 09:00 lizmat joined 09:18 lizmat joined 09:39 lizmat joined 10:10 lizmat joined 10:32 lizmat joined 11:34 lizmat joined
nine I can't shake the feeling (and it's not more than that) that maybe the X namespace may be handled specially somewhere 11:41
12:19 tbrowder joined 13:03 lizmat joined 13:30 lizmat joined 13:57 lizmat joined 13:59 lizmat joined 14:28 lizmat joined 15:08 lizmat joined 15:35 lizmat joined 15:44 lizmat joined 16:36 lizmat joined 18:29 tadzik joined 20:04 tadzik joined
ugexe nine: gist.github.com/ugexe/f78c4218235f...5953f8263a this "fixes" the problem. but I imagine it breaks other things (despite passing spec test) 22:19
created as a workaround for irclog.perlgeek.de/perl6-toolchain...i_14996577 23:16
maybe a good spot to put more debugging info at least 23:19
23:33 lizmat joined