# Revision history for Inline::SLang
--
version: 0.24
date: Tue Apr 13 22:16:12 EDT 2004
changes:
- A one-line fix means that PDL support now works on Linux as well as
Solaris. It works on OS-X until you try to convert a S-Lang array
to a piddle. PDL support is now on by default for Solaris and Linux
machines.
--
version: 0.23
date: Wed Apr 7 21:32:07 EDT 2004
changes:
- This is a fix to 'make test' in version 0.22, which failed on systems
which did not already have a version of Inline::SLang installed.
--
version: 0.22
date: Wed Apr 7 16:29:05 EDT 2004
changes:
- This is a minor release over 0.21.
- The major change is in the details of the build process: we now use
Inline::C to embed the C code - which is used to interrogate the
S-Lang interpreter - within Makefile.PL rather than having it in a
separate file (slfconfig.c) which we have to compile ourselves. This
should make the build process more portable.
- One really minor documentation fix to the "CHANGES" section of
Inline::SLang.
--
version: 0.21
date: Mon Apr 5 15:15:51 EDT 2004
changes:
- This is a minor release over version 0.20. The main user-visible changes
are:
o The module will now build on OS-X.
o Support for PDL has been turned off by default since it does not
work on Linux and OS-X machines.
o The dump() method has been added to the Struct_Type class. This
should be considered an experimental feature (which is why it has
not been documented) and not relied upon.
o Inline::SLang::Details has been added to document the design and
implementation of the module. It is not intended to be read by the
average user, unless there is a problem. Currently it is little more
than a place holder.
- The code has been re-organised: the single file util.c has been
split into sl2pl.c, pl2sl.c, and pdl.c.
--
version: 0.20
date: Wed May 21 00:37:07 EDT 2003
changes:
- Support for conversion of S-Lang arrays to piddles (PDL):
o requires v2.4.0 of PDL which isn't actually released
(a fairly-recent CVS build should do the trick)
o conversion betweed 1D arrays and piddles works
o should 0D piddles be converted to a scalar or a 1-element 1D array?
(currently the code croaks)
o > 1D arrays is a mess since a 2x3 array in S-Lang maps to a
3x2 piddle. The first time this happens a warning is printed to
STDERR as a precaution. Not sure what the best approach is.
o it has only been tested on 32-bit machines
- Remove some warnings from the test suite seen on an Alpha
- Tie::ExtraHash appears to have been added to Tie::Hash after 5.6.0
so copy the code for this package rather than import it.
--
version: 0.12
date: Sun May 11 23:33:38 EDT 2003
changes:
- Added support for type "synonyms": you can now create DataType_Type
objects of type Int16_Type, UInt16_Type, Int32_Type, UInt32_Type,
Float32_Type, Float64_Type, Short_Type, Long_Type and possibly
Int64_Type, UInt64_Type. The return value of Inline::SLang::Int32_Type()
- or whatever - is the actual type usedf by S-Lang rather than the
type synonym. Note that Short/Long types may not actually be synonyms.
- The build process now checks that the S-Lang interpreter was built with
support for floats and complex types; if not it exits with an error.
- Added a brief section to the Inline::SLang document describing how
S-Lang are handled.
--
version: 0.11
date: Wed May 7 00:39:17 EDT 2003
changes:
- S-Lang arrays can now be converted to Array_Type objects as well
as array references. Use the Inline::SLang::sl_array2perl()
function (described in the Inline::SLang manpage) to control how
arrays are converted.
- Added functions called Inline::SLang::<datatype name>() that return
a DataType_Type object whose value matches the given datatype. These
can be imported via the EXPORT array individually or by using '!types'.
This means you can say
Integer_Type()
rather than
DataType_Type->new("Int_Type")
[unfortunately there are no functions for type "synonyms" like 'Int_Type'].
- DataType_Type objects can now be compared for equality and inequality
(i.e. the ==, eq, !=, and ne operators).
- Added Inline::SLang::sl_have_pdl() and Inline::SLang::sl_version()
functions that return information about how the module was compiled.
- changed storage mechanism for "opaque" types; should be better behaved
when converting a large array of such items.
- re-arranged some of the internals to take advantage of recent changes
or make them more robust/maintainable. Should be no user-visible changes.
- we no longer allow the S-Lang namespace "_inline" to be bound to Perl
(this namespace is for use only by the module).
--
version: 0.10
date: Sat May 3 19:39:00 EDT 2003
changes:
Since there have been a number of significant changes over 0.06 the
version number has been pushed to 0.10.
- Support for S-Lang libraries earlier than 1.4.7 has been discontinued.
- Perl class names have been changed from Inline::SLang::XXX to
XXX. This reduces the amount of typing, but it doesn't fit in
with standard Perl module/namespace policy. There's also the (rare?)
possibility that a data type name will clash with an extant
Perl module. A compromise would be to use SLang::XXX?
- S-Lang structs (both Struct_Type and named structs) are now handled
using a tied hash. What this means is that you get back a hash
reference and so can use it as any other hash (e.g. $$foo{x}) with
the caveat that you can not create new keys and the iteration order
- eg the value from keys(%$foo) and each(%$foo) - is fixed to match
that of the struct's fields. The returned value is still a member
of the Struct_Type class (or derived from it if it's a named struct).
- S-Lang Assoc_Type arrays are now converted to the Perl Assoc_Type
class (and vice-versa). This is a reference to a hash array (as with
Struct_Type) but you can add and delete keys. Note that when iterating
through the key names of the array [eg via Perl's keys/values/each or
the get_keys/values method calls] you are NOT guaranteed to get
the same order as S-Lang's assoc_get_keys/values/foreach construct.
If a user supplies a hash reference (ie not an Assoc_Type object)
then this gets converted to an 'Assoc_Type [Any_Type]' array.
- Have created a Perl Array_Type class to handle S-Lang arrays. This
will not use a tied interface, instead using methods as mutators.
It is expected that piddles will be used for numeric arrays - at least
once the PDL support is added! - and so this will only really be
used for arrays of non-numeric data types (and even then you will
probably want to use a normal Perl array reference as discussed below).
- Perl array references are converted to S-Lang arrays with the
type and dimensionality guessed at based on the first element in the
array. Note that it's not too hard to confuse the poor computer; for
such cases you can use the Inline::SLang::sl_array() function to
specify the data type and/or dimensionality.
- Conversion of S-Lang arrays to Perl now accomdates all dimensions
(previously only 1 and 2D) and all variable types (previously only
numeric, string, and a couple of other ones such as DataType_Type).
Still use Perl array references to represent this data (and not
Array_Type objects). This will be configurable.
- Several Inline::SLang::XXX routines can now be exported to Perl's
main package by use of the EXPORT configuration option (rather than
the standard Perl way of using 'use foo qw( ... );'. This can be
looked at as something of a hack.
- Handling of S-Lang errors has been improved: they are now caught
and then converted into Perl errors. So, calls to sl_eval() can
now be wrapped in an eval block and the S-Lang error message will
appear in $@. Needs more testing to see if this is really what is
wanted (I don't really grok Perl's error handling). For instance the
lack of line numbers can be annoying.
This means that calling DataType_Type->new() with an unknown type
name no longer results in S-Lang error messages printed to STDERR
(which it did in 0.06).
- fixed mem leak when converting structs from Perl to S-Lang. Note that
the code used *may* trigger a mem leak in the S-Lang library if you
are using a version < 1.4.9.
--
version: 0.06
date: Thu Apr 3 22:36:54 EST 2003
changes:
- big improvement in amount of S-Lang scalar types that can be converted
to Perl (and vice versa). If a S-Lang type is not recognised then
it is converted into an Inline::SLang::XXX object, where XXX matches
the S-Lang type. These objects do not do much in Perl, but will
convert back to the S-Lang type. Types handled like this are
Ref_Type (removes hacky handling of this type 0.05); Any_Type; and
any module-defined types
- named/type-deffed structures - ie those created via 'typedef struct ...'
- are now handled as Inline::SLang::XXX objects, where XXX is
the S-Lang type name. These objects are sub-classes of the
Inline::SLang::Struct_type class.
- Inline::SLang::DataType_Type->new() now verifies that the type is
recognised by S-Lang. This means that type synonyms (eg 'Int_Type'
for 'Integer_Type' are recognised and converted to the 'base' type),
but it does mean that unrecognised values result in several lines of
S-Lang error messages being printed to STDERR. This could be stopped
by installing an error hook, but that's for later.
- fixed BIND_NS => "All"
- added examples/ directory (not too different from those in the tests
and in the Inline::SLang::Types documentation)
Note that in the next release the class names for objects will be
shortened from Inline::SLang::Foo_Type to Foo_Type.
--
version: 0.05
date: Fri Mar 14 11:57:31 EST 2003
changes:
- Removed the namespace tests (t/20bind_foo|many.t) if S-Lang version is
less than 1.4.3. This should remove the CPAN testing failure.
If you wish to use the BIND_NS option then make sure you have at least
this version of S-Lang (you gain further benefits if you upgrade to
at least v1.4.7).
- Can specify the Perl package name for each S-Lang namespace to be bound
to (by specifying "foo=bar" in the BIND_NS config option to get S-Lang
namespace "foo" to be bound to the "bar" Perl package). I can't actually
think of a need for this.
- BIND_NS = "All" will bind all namespaces without having to specify them
individually (only available if you use v1.4.7 or higher of S-Lang)
- Added the BIND_SLFUNCS option to allow binding of selected S-Lang
intrinsic functions. We allow these functions to use a different function
name in Perl to that in S-Lang (specified as "slang_name=perl_name").
- The output of 'perl -MInline=info' has been updated to account for the
inproved binding schemes.
- added support for Ref_Type (both from and to S-Lang) variables (scalar
only). This makes use of "private" routines/structures and so should
be considered a hack.
- handling of S-Lang structs has changed to more closely match the S-Lang
API (in that the method names match the S-Lang function names without
the 'slang_')
- Support for "non native" types (those that are represented by an object
from an Inline::SLang::* class) has been standardised to use the name
of the S-Lang datatype: at present we have Inline::SLang::DataType_Type,
Inline::SLang::Struct_Type, and Inline::SLang::Ref_Type. All classes
provide several common methods (all classes are sub-classes of a
hidden base class).
This has the side effect of making the class names even more verbose.
- Documentation for configuration of Inline::SLang has been moved from
Inline::SLang to Inline::SLang::Config.
--
version: 0.04
date: Fri Mar 7 00:14:47 EST 2003
changes:
- The copyright holder is now the Smithsonian Astrophysical Observatory.
- The license changed to GNU General Public License only (prior to v0.04
it was distributed under a dual "perl or GNU GPL license" scheme)
- S-Lang's Struct_Type variables are converted to Inline::SLang::struct
objects, assuming the types of the fields are also supported.
The conversion leaks memory.
- 1D and 2D support for DataType variables (S-Lang to Perl)
- Fixed mem leaks in the code converting associative-array
- improvement to access 1D/2D arrays of Complex_Type values; users
should see no change because of this
- internal function added to access S-Lang version module was compiled
against. This is almost-certainly not needed.
- Conversion of perl types to S-Lang is still very limited.
- added the configuration option BIND_NS: only functions in namespaces
in this list are bound to Perl. Note that S-Lang intrinsic functions
are not bound to Perl and that S-Lang functions in namespace foo
(ie that would be evaluated via foo->function_name() in S-Lang)
are accessed via foo::function_name() in Perl. See the TODO file for
possible future upgrades.
- improved the build/load functions used when evaluating/loading the
S-Lang code. This stops the S-Lang code being evaluated twice the
first time a file was evaluated.
- further separation (and improvement) of test cases
--
version: 0.03
date: Tue Jan 28 12:01:49 EST 2003
changes:
- Initial CPAN release (for feedback/comments as still pre-alpha)
- S-Lang's associative arrays are supported (in so far as there is
1D array support for the data type of the stored data)
- S-Lang's Complex_Type is stored as a Math::Complex object in Perl
and can convert between the two languages (scalars only)
- S-Lang's Datatype_Type is represented as an Inline::SLang::datatype
object (scalars only).
- 1/2D array support (S-Lang to Perl) no longer lumps together similar
datatypes (eg char, short, int, long) into the code (should we just
typecast them to long in S-Lang scope instead?)
- Complex types are supported in 1 & 2D arrays
- documentation split: data type information is now in a separate pod,
Inline::SLang::Types.
- 'perl Makefile.PL' now supports the --gdb(=string) flag (--help for
help)
Initial support for both static and dynamically-loaded forms of the
S-Lang library.
Added Test::More as a requirement.
--
version: 0.02
date: Sun Jan 19 10:56:10 EST 2003
changes:
- now correctly accesses elements from String_Type (thanks to John Davis)
- started support for > 1D arrays (S-Lang to Perl only)
- added some necessary files for a perl module
--
version: 0.01
date: Thu Jan 16 23:59:59 EST 2003
changes:
- initial version
- the fact it works is thanks to Neil Watkiss' Ruby & Python Inline modules
--