Jerome Quelin > Language-Befunge-4.13 > Language::Befunge::Storage



Annotate this POD



Open  0
View/Report Bugs
Source   Latest Release: Language-Befunge-5.000


Language::Befunge::Storage - a generic Storage base class


    my $storage = Language::Befunge::Storage::Generic::AoA->new;


This class implements a set of basic methods which can be used by all Storage subclasses. Subclasses may choose to override any or all of these methods, for efficiency reasons... these methods are the baseline, generic counterparts.

These methods will work with any subclass which stores the number of dimensions within the self hash, as the "nd" key, and the minimum and maximum vector sizes stored as "min" and "max", respectively. No other assumptions about the storage model are made; they just call expand, get_value and set_value to do their dirty work.


Storage update

my $size = $storage->store_binary( $code [, $position] );

Store the given $code at the specified $position (defaulting to the origin coordinates).

Return the size of the code inserted, as a vector.

The code is a string, representing a block of Funge code. This is binary insertion, that is, EOL sequences are stored in Funge-space instead of causing the dimension counters to be resetted and incremented.

my $size = $storage->store( $code [, $position] );

Store the given $code at the specified $position (defaulting to the origin coordinates).

Return the size of the code inserted, as a vector.

The code is a string, representing a block of Funge code. Rows are separated by newlines.

$storage->expand( vector );

Expand the storage range to include the specified point, if necessary. This is a stub method, to be superceded by subclasses which do something meaningful here.

It is usually called for new "min" and "max" values, for efficiency reasons: if we expand the storage ahead of time, we only have to do the expansion once, rather than expanding it again and again every time a rasterize loop reaches new ground.

Sparse storage models do not need this; all other storage models should implement a specific method to resize their data structure.

Data retrieval

my $dims = $storage->get_dims;

Return the number of dimensions this storage object operates in.

my $vmin = $storage->min;

Return a LBV pointing to the lower bounds of the storage.

my $vmax = $storage->max;

Return a LBV pointing to the upper bounds of the storage.

my $chr = $storage->get_char( $offset )

Return the character stored in the torus at the specified $offset. If the value is not between 0 and 255 (inclusive), get_char will return a string that looks like <np-0x4500>.

/!\ As in Befunge, code and data share the same playfield, the character returned can be either an instruction or raw data. No guarantee is made that the return value is printable.

my $str = $storage->rectangle( $pos, $size );

Return a string containing the data/code in the rectangle defined by the supplied vectors.

Miscellaneous methods

my $href = $storage->labels_lookup;

Parse the storage to find sequences such as ;:(\w[^\s;])[^;]*; and return a hash reference whose keys are the labels and the values an anonymous array with four values: a vector describing the absolute position of the character just after the trailing ;, and a vector describing the velocity that leads to this label.

This method will only look in the four cardinal directions, and does wrap basically like befunge93 (however, this should not be a problem since we're only using cardinal directions)

This allow to define some labels in the source code, to be used by Inline::Befunge (and maybe some exstensions).




Mark Glines, <> Jerome Quelin, <>


Copyright (c) 2001-2009 Jerome Quelin, all rights reserved.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

syntax highlighting: