Strange Buf.subbuf behavior in Perl 6

Today I installed Rakudo Star 2012.07 and tried to write a simple Perl 6 script:

#!/usr/bin/env perl6 use v6; use LWP::Simple; my $html = LWP::Simple.get('http://perl6.org'); say $html; 

This does not work due to the following error:

 No such method 'get_string' for invocant of type 'String' in method decode at src/gen/CORE.setting:6766 in method parse_response at lib/LWP/Simple.pm:244 in method make_request at lib/LWP/Simple.pm:199 in method request_shell at lib/LWP/Simple.pm:63 in method get at lib/LWP/Simple.pm:28 

LWP Code :: Simple Line 244:

 my @header_lines = $resp.subbuf( 0, $header_end_pos ).decode('ascii').split(/\r\n/); 

It is strange that the following code is in order:

 > Buf.new(1,2,3,4,5).decode('ascii') 

while this fails:

 > Buf.new(1,2,3,4,5).subbuf(0,3).decode('ascii') Method 'get_string' not found for invocant of class 'String' 

Could you please explain to me why this is happening? As far as I can see, in both cases the Buf.decode method is called:

 > Buf.new(1,2,3,4,5).subbuf(0,3).isa('Buf') True > Buf.new(1,2,3,4,5).isa('Buf') True 

Perhaps this is a bug in Rakudo Perl? Or maybe subbuf is an obsolete / undocumented method? This is not at doc.perl6.org. In this case, which method should be used?

+8
perl perl6 rakudo rakudo-star
source share
1 answer

This was a bug in Rakudo, which is already fixed in the latest development version.

 $ perl6 -e 'say Buf.new(1,2,3,4,5).subbuf(0,3).decode("ascii")'|hexdump -C 00000000 01 02 03 0a |....| 

(I'm sure the fix is ​​also a release of Rakudo 2012.08, a compiler-based Rakudo Star release coming out this week).

The reason it is not yet documented is because I focus on those methods that are also in the specification, since they have a higher chance of survival. I hope to prepare the documentation soon.

Update: go to it, see http://doc.perl6.org/type/Buf#subbuf

+6
source share

All Articles