FAQ
SPVM FAQs.
Because the MIT license is the open source license that most developers know and understand.
The Perl Artistic License is a great open source license, but its biggest problem is that it is not well known outside of Perl developers.
Because the local variable name ($foo) has a sigil, it will not conflict with keyword names, class names, method names, or field names.
When declaring local variables, you can write programs without worrying about name conflicts.
You can write programs without worrying about name conflicts with keywords that may be added in the future.
Class variable names will conflict with local variable names, but this can be conventionally avoided by using upper case for class variable names($FOO) and lower case for local variable names($foo).
The SPVM string are simply a sequence of bytes of the string type. The sequence of bytes is exactly the same as the byte[] type.
A string are supposed to be represented in UTF-8, which is just a sequence of bytes.
A Perl string is converted to a SPVM string by the new_string method in the SPVM::ExchangeAPI class.
Whether the UTF-8 flag is set in the Perl string or not, the sequence of bytes stored in the PV slot of Perl's SV type is copied to the SPVM string.
A SPVM string is converted to a SPVM::BlessedObject::String object when is is returned to Perl.
A SPVM::BlessedObject::String has the SPVM string as it is.
If you want to convert it to a Perl string with UTF-8 flag, use the to_string method in the SPVM::BlessedObject::String class or use "" overloading, like "$blessed_object_string". The utf8::decode function is called and the UTF-8 flag is set to the Perl string.
If you want to treat it as a sequence of bytes, use the to_bin method in the SPVM::BlessedObject::String class.
The system calls used in the SPVM distribution are the following ones.
In the SPVM language, the print operator calls a system call of stdout. The warn operator calls a system call of stderr.
The modules contained in the SPVM distribution do not call any system calls.
The methods for system calls are implemented in SPVM::Sys distribution.
Why is it necessary to write both the version number of the SPVM class and the Perl module file?
The version number is declared in lib/SPVM/Foo.spvm.
# lib/SPVM/Foo.spvm
class Foo {
version "0.100";
}
The following version declaration in lib/SPVM/Foo.pm is needed.
# lib/SPVM/Foo.pm
package SPVM::Foo;
our $VERSION = "0.100";
This is needed for ExtUtils::MakeMaker to get the version number in the Perl module file.
This is performed statically, not loading the module file, so lib/SPVM/Foo.pm must contain the version number.
The get_version_number method in the Fn class is used.
use Fn;
my $version_number = Fn->get_version_number("MyClass");
if ($version_number >= 2.001003) {
}
if ($version_number >= 2.001) {
}
if ($version_number >= 2) {
}
The term "module" is not used in the SPVM language, but we are used to say "CPAN modules"(we does not say "CPAN classes").
So SPVM::Foo class can be called by SPVM::Foo module.
Static Perl Virtual Machine.
SPVM provides fast calculation, fast array operations, easy C/C++ binding, and creating executable files.
Any multithreading support? Let's say I want to run some blocking code in parallel (fork() won't work as I need shared memory). Is that possible with SPVM? How do I do that?
Sorry, Currently multi-threading are not supported . If you try to run with multithreading, the object release operation will cause a segfault because there is no synchronous.
I will work on multithreading after I implemenet the features (reflection) and introduce POSIX mutexes so that the SPVM program will work properly.
(The following anwer is added at 2024/02/23)
SPVM::Thread was released.