Skip Menu |
Report information
Id: 127329
Status: new
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: drforr [at]

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)

Date: Wed, 20 Jan 2016 23:31:45 +0100
Subject: OOM Killer bug with multiple -I CLI options
From: drforr [...]
To: Rakudobug <rakudobug [...]>
Download (untitled) / with headers
text/plain 1.2k
Given the following (somewhat unusual) file layout: -- lib/Program.pm6 -- use Vector; # included in lib/Java class Program { } -- cut here -- -- lib/Java/Vector.pm6 -- use String; # Included in lib/Java class Vector { } -- cut here -- -- lib/Java/String.pm6 -- class String { } -- cut here -- invoke with: perl6 -c -Ilib -Ilib/Java lib/Program.pm6 Resolution order *should* go something like this (though I'm aware that @INC is an old-fashioned notion): read lib/, attempt to resolve Vector. readdir lib/, find no or .pm6 readdir lib/Java, find Vector.pm6 Read lib/Java/Vector.pm6, attempt to resolve String. readdir lib/, find no or .pm6 readdir lib/Java, find String.pm6 Compile. I'd accept OOM or looping (I've seen both behaviors while playing with this) if I were foolish enough to create mutually-recursive includes, although I would be surprised. There is no recursion, mutual or otherwise, going on here though. lib/Java is a subdirectory of lib/ and I'm well aware that could be playing havoc with file includes. I'm also aware that ordinarily lib/Java/Vector.pm6 would contain a class called 'class Java::Vector { }', but I wanted to experiment with a slightly different kind of include style and ran across what appears to me to be a quirk.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at