Note: This project is currently on hold.
The reason for this is that I'm working on porting GT.M to Win32.
After that I will clean up the perl stuff so it's ready to be
an optional component of the main GT.M tree.
Customized Perl |
Stefan's (oesi's) Perl enabled GT.M Tree
This is the official site about the inofficial Perl
support for GT.M.
If you never heard of GT.M - it's a great hirachical
database made by Sanchez -
available including source code under GPL.
This page is all about Perl support for GT.M - about running
GT.M and Perl in the same address-space - about the interaction
between GT.M and Perl.
Read this for documentation about embedding Perl in GT.M.
Read this for information about embedding GT.M in Perl, look at
primes.pl to see how to access globals from Perl - it's not much
slower than the GT.M version primes.m.
An even more cool version ties the global to a perl hash (using
Here is the ChangeLog, please read it first.
Patches here are not what I would call stable so don't use it on production systems
without extensive testing.
Here is the latest patch gtm_V44004_linux_i386_src-perl-45.diff.gz
Here are some older, obsolete revisions:
The following man-pages are currently available:
Please report all problems with this module to Stefan Traby <firstname.lastname@example.org>.
This tree is not stable yet, but I'm working on it and we plan to use the stuff
on about 180 production systems.
I'm open to discussions - you can direct feature-requests directly to me.
I'm also willing to support you if you have problems installing this module -
if it's not too time-consuming.
Creating your own Perl especially for GT.M
Well, you can use your system Perl - but I suggest to build a Perl for GT.M
The reason for this is that most system Perl's have threads in it - and Perl
threads are fundamentally broken by design - they are slow and they act like
the fork-model by default - they share nothing.
It's for example not possible to create an anonymous subroutine in one
thread and to use it afterwards within other threads.
If you use GT.M with embedded thread-enabled Perl,
call GT.M functions just from one thread.
I heavily suggest to use Marc Lehmanns Coro module instead of threads.
I also suggest to not use use64bitint on 32 bit architectures.
It works, but it makes the stuff 20% slower.
I use Perl 5.8.3 self-compiled for GT.M and I install it under /usr/gtm-perl/.
Here - just for reference - how I configure my Perl - Perl-Configure.sh.txt
Note: It's important to know that Perl-enabled GT.M uses the compiler that Perl used for building Perl - and
also the CFLAGS that Perl used.
This can cause trouble on Perl systems that are built by newer gcc compilers -
they have no support for varargs.h anymore - which is cool because
varargs.h is obsolete since about 15 years.
I hope that Sanchez will address this soon.
Here some of my plans related to Perl support within GT.M:
- Finishing the preprocessor Interface
- Adding hooks for calling out to perl within GT.M.
- Adding global-functions that
- work on hashes/arrays ("merging" globals from/to hashes/arrays)
- "grep" the global structure
- Adding source filters within Perl for mixing Perl/GT.M code
- Adding source filters for GT.M for mixing GT.M/Perl code
- Fixing the Perl side
All the stuff here is available under GPL.
If you need a different licensing, contact me.
Sanchez Computer Associates, Inc.
40 Valley Stream Parkway
Malvern, PA 19355, USA
is allowed to do with my Perl-stuff what ever they want.