Inline::Files bug?

BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:

I've attempted t use readmore tags to reduce the length of this, but I wont see if they have worked or not until I submit it....my apologoes in advance if they don't.

I have been trying to make use of the Inline::Files module from CPAN. (Actually VERSION '0.60' from AS via PPM in conjunction with 'This is perl, v5.6.1 built for MSWin32-x86-multi-thread' ).

After an extended CB session with podmaster and dada (thanks guys!), we concluded that I may have a legitimate bug report against the module, but I am posting here to see if anyone else can see my error(s) before I raise the report and make a fool of myself. Referencing the Inline::Files pod (Files.pm:lines 360-380) the following code should? read and print the number 10..1 from the virtual file (vf) __INLINE__ and then re-write vf __INLINE__ with the numbers 1..10.

#! perl -w
#use strict;
use Inline::Files -backup;

print <INLINE>;
seek INLINE, 0, 0;
print INLINE   for (1..10);

__INLINE__
10
9
8
7
6
5
4
3
2
1
[download]

The results I get are:

C:\test>inline
10
9
8
7
6
5
4
3
2
1
seek() on unopened filehandle INLINE at
 e:/Perl/site/lib/Inline/Files/Virtual.pm line 227.
print() on unopened filehandle INLINE at C:\test\inline.pl line 14.
print() on unopened filehandle INLINE at C:\test\inline.pl line 14.
print() on unopened filehandle INLINE at C:\test\inline.pl line 14.
print() on unopened filehandle INLINE at C:\test\inline.pl line 14.
print() on unopened filehandle INLINE at C:\test\inline.pl line 14.
print() on unopened filehandle INLINE at C:\test\inline.pl line 14.
print() on unopened filehandle INLINE at C:\test\inline.pl line 14.
print() on unopened filehandle INLINE at C:\test\inline.pl line 14.
print() on unopened filehandle INLINE at C:\test\inline.pl line 14.
print() on unopened filehandle INLINE at C:\test\inline.pl line 14.

C:\test>type inline.pl
#! perl -w
use strict;
use Inline::Files -backup;

print <INLINE>;
seek INLINE, 0, 0;
print INLINE   for (1..10);

__INLINE__
10
9
8
7
6
5
4
3
2
1

C:\test>
[download]

dada pointed out that the pod example doesn't work as listed, and that this is because when a VF is being read and EOF is reached, it is automatically closed, which This explains the "unopened filehandle" errors above. With dada's help, I worked out the syntax for opening a VF is:

open INLINE, ">$INLINE" or die $!;

This wasn't obvious (to me) as

TheDamian shows (Files.pm:342):
open CACHE or die $!; # read access (uses $CACHE to locate file)
A one param open???
I routinely have use strict; and this violates stricture.
This is a strange (to me) choice of syntax as $INLINE is never set (in my code).

Anyway these changes gave me this:

#! perl -w
#use strict;
use Inline::Files -backup;

print <INLINE>;
#seek INLINE, 0, 0;
open INLINE, ">$INLINE" or die $!;
print INLINE   for (1..10);

__INLINE__
10
9
8
7
6
5
4
3
2
1

C:\test>inline
10
9
8
7
6
5
4
3
2
1
Use of uninitialized value in concatenation (.) or string at C:\test\i
+nline.pl line 7.
Use of uninitialized value in substitution (s///) at
 e:/Perl/site/lib/Inline/Files/Virtual.pm line 120.
Use of uninitialized value in substitution (s///) at
 e:/Perl/site/lib/Inline/Files/Virtual.pm line 120.

C:\test>type inline.pl
#! perl -w
#use strict;
use Inline::Files -backup;

print <INLINE>;
#seek INLINE, 0, 0;
open INLINE, ">$INLINE" or die $!;
print INLINE   for (1..10);

__INLINE__
10
9
8
7
6
5
4
3
2
1
__INLINE__
12345678910

C:\test>
[download]

Which, apart from the warnings from the open line in my code which I can't explain-- apart from the fact that $INLINE is never being set--also gives the two errors from Virtual.pm?

Added to this, the open has caused a second __INLINE__ to be created, rather than the original being overwritten?

Also, the (1..10) are being written as one line (my fault) so I thought I would correct this using my usual technique in test progs ie. using local($/="\n"); (which I think is a correct way to do things) so that resulted in this:

C:\test>inline
10
 | 9
 | 8
 | 7
 | 6
 | 5
 | 4
 | 3
 | 2
 | 1
Use of uninitialized value in concatenation (.) or string at C:\test\i
+nline.pl line 8.
Use of uninitialized value in substitution (s///) at
 e:/Perl/site/lib/Inline/Files/Virtual.pm line 120.
Use of uninitialized value in substitution (s///) at
 e:/Perl/site/lib/Inline/Files/Virtual.pm line 120.

C:\test>type inline.pl
#! perl -w
#use strict;
use Inline::Files -backup;
local ($,=' | ', $/="\n");

print <INLINE>;
#seek INLINE, 0, 0;
open INLINE, ">$INLINE" or die $!;
print INLINE  for (1..10);

 | __INLINE__
10
9
8
7
6
5
4
3
2
1
 | __INLINE__
12345678910

C:\test>
[download]

Which as you can see, appears to have effected everything except what I wanted.

I know that setting $, was unnecessary for what I wanted to achieve (I just cut&pasted the line from another file, but it would appear that despite my use of local, my changes to these vars has effected the IO done by Inline::Files?? Is this expected behaviour?

Comment on Inline::Files bug? Select or Download Code

Replies are listed 'Best First'.
Re: Inline::Files bug? by Abigail-II (Bishop) on Aug 01, 2002 at 11:51 UTC
One arg `open` is documented. From the manual page: If EXPR is omitted, the scalar variable of the same name as the FILEHANDLE contains the filename. (Note that lexical variables--those declared with "my"--will not work for this purpose; so if you're using "my", specify EXPR in your call to open.) Always consult the manual first, it's likely to be documented! ;-) Abigail	[reply] [d/l]
Re: Re: Inline::Files bug? by BrowserUk (Patriarch) on Aug 01, 2002 at 12:18 UTC
Well, that (half) explains that bit. Thanks. Problem is, in the sample (pod) code, $CACHE is used, but never given any value. In this particular use of `open`, its not clear what value I would give the scalar variable of the same name? It appears as if, in the case of Inline::Files, that it is the name of the scalar variable of the same name as the filehandle that is being used - which seems (to me) to be a little redundant? I freely admit to still being a newbie to this stuff, but to implicitly use the name of an undeclared, uninitialised global variable, with the same name as a supplied filehandle, to supply the name of the virtual file to open.....(phew)...seems...erm...a little confusing?	[reply] [d/l]
Re: Inline::Files bug? by Abigail-II (Bishop) on Aug 01, 2002 at 12:41 UTC
Of course `$CACHE` is given a value, even if grepping for `CACHE` didn't reveal it. I don't know Inline::Files myself, but one minute browsing of the module and I found: `my (%symbols, $source); foreach my $vfile (vf_load($file, $SOVFM_pat)) { my $symbol = vf_marker($vfile); $symbol =~ s/^__\|__\n//g; push @{$symbols{$symbol}}, $vfile; } foreach my $symbol (keys %symbols) { no strict 'refs'; my $fq_symbol = "${package}::${symbol}"; @$fq_symbol = @{$symbols{$symbol}}; $$fq_symbol = $symbols{$symbol}[0]; my $impl = tie *$fq_symbol, $class, $fq_symbol, -w $file; tie %$fq_symbol, $class."::Data", $impl; }` [download] I think I can guess what that does. Abigail	[reply] [d/l] [select]
Re: Re: Inline::Files bug? by BrowserUk (Patriarch) on Aug 01, 2002 at 13:02 UTC
Re: Inline::Files bug? by Abigail-II (Bishop) on Aug 01, 2002 at 13:38 UTC
Re: Re: Re: Inline::Files bug? by dada (Chaplain) on Aug 01, 2002 at 12:29 UTC
BrowserUk wrote: $CACHE is used, but never given any value have you tried `print $INLINE` in your program? it prints for me: `P:/dada/test.pl(00000000000000000259)` so it has a value. it all happens behind your shoulders, but it happens indeed. `<hint>`remember, you're using a module written by </code>TheDamian`</hint>` cheers, Aldo `__END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;` [download]	[reply] [d/l] [select]