I'm trying to do what I thought would be a very simple task: Create a zipfile with the contents of an entire directory, passed in to a function. I wrote (with very minor changes from the real code):

sub create_zipfile {
    my ($path) = @_;

    my $UUID = Data::GUID->new->as_string();
    my $zipfile_name = $UUID . ".zip";

    my $full_path = $path . "/" . $zipfile_name;
    
    my $zip = Archive::Zip->new();
    $zip->addTree($path, undef);

    if ( ! $zip->writeToFileNamed($full_path) == AZ_OK ) {
    print "Error writing zipfile: $!\n";
    }

    return $full_path;
}
[download]

In a previous version of this--and I don't remember what's different, and can't replicate it--it did create a zipfile, but it was empty.

I have code where I've supplied a snippet of the relevant parts below:

$soap = SOAP::Lite
->proxy($proxy)
->uri($uri)
->autotype(0)
->ns('http://www.w3.org/2003/05/soap-envelope','soap')
->ns('http://mil.dod.af.A1.personnel.dataservices.filter','mil')
->ns('http://mil.dod.af.A1.personnel.dataservices.training/v2.4','v2')
->readable(1);
[download]

This creates the following output:

<soap:Envelope
    soap:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/
    xmlns:mil=http://mil.dod.af.A1.personnel.dataservices.filter
    xmlns:soap=http://www.w3.org/2003/05/soap-envelope
    xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/
    xmlns:v2=http://mil.dod.af.A1.personnel.dataservices.training/v2.4
    xmlns:xsd=http://www.w3.org/2001/XMLSchema
    xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance>
[download]

But I need it to look like this, without the magically included namespaces:

<soap:Envelope
    xmlns:mil=http://mil.dod.af.A1.personnel.dataservices.filter
    xmlns:v2=http://mil.dod.af.A1.personnel.dataservices.training/v2.4
    xmlns:soap=http://www.w3.org/2003/05/soap-envelope>
[download]

How do I get rid of the soap:encodingStyle, xmlns:soapenc, xmlns:xsd and xmlns:xsi namespaces? If I use these extra namespaces in the web service call then it fails their validation check.

Fellow monks, I have a problem that isn't necessarily a Perl problem, so much as it manifests itself when I'm using Perl, and I'm hoping that there may be a relatively painless Perl solution.

For many years I've been getting monthly data files in Excel from a little company in Seattle. For years I've parsed them into a database, using first Spreadsheet::ParseExcel, then as the format changed using Spreadsheet::XLSX, and more recently using Spreadsheet::ParseXLSX. And despite the changes from .xls to .xlsx and a few format changes, things have been mostly good.

Some time around a year ago the format didn't change, but the Spreadsheet::ParseXLSX stopped reading the file correctly. Or maybe more accurately, whoever wrote the file stopped writing it correctly, and now Spreadsheet::ParseXLSX doesn't read it correctly. The particular issue where it first manifests is in reading a cell with "Month Year" in the contents (e.g. "December 2023"). When I read the cell with

and then try to evaluate it with either

my $value=$mycell->value(); # or
my $unformatted=$mycell->unformatted();
[download]

it returns "0" or "0.0" respectively. The catch is that if I simply open the file in Excel and hit "save", or open it in Apple's Numbers and export it back to XLSX, it then parses correctly, like it always used to. So the Excel file opener is fairly forgiving of whatever changed, but Spreadsheet::ParseXLSX isn't, and I don't see an obvious way to get at the content to debug. Using Data::Dumper on $mycell also shows zeros where it should give the month and year. I haven't tried other cells - once it barfs, I remember I have to open/save and that presumably fixes all the cells.

This is something I can live with if I have to, since I only have to deal with the files a few times a year and can just open/save them quickly, but it seems so wrong. I'm not sure it's a widespread problem - someone else is writing the file using a program other than Excel so I can read it with a program other than Excel. The smart thing would be if the generator produced CSV, but that's not something I can influence.

I know little about XS modules but I was looking at RPi::DHT11 and noticed that it is an XS module which seemed a little strange. Hence the question here. I was going to email stevieb, the author and ask but thought it would be good to get other people's take on this.

My understanding of an XS module is that it uses XSLoader to load C / C++ / C# code. The Perl is just a wrapper around the loaded code with the Perl doing little processing. I believe the main reason to do this is for speed as compiled languages of the C family are faster than interpreted languages such as Perl. Is that about right so far?

Assuming that is something like correct...
Why would the RPi::DHT11 module use XS? The DHT11 is a temperature and humidity sensor with a maximum frequency of 0.5Hz (one read per 2 seconds). So speed is not the issue here!

What reason would there be for creating an XS module in this use case? Would it not be easier and simpler and just as fast given the speed of the sensor, to write all the code in Perl?

I'm hoping for more insights into the world of XS modules here...

My module does not need to use unicode. If the unicode comments and POD were stripped out of it, it would not even require "use utf8;" as there is no unicode in its actual code. But because it is for utf8 and the tests, to be meaningful, incorporate uft8 characters, the entire module fails to install on perl systems which do not already have the non-core module "Test::More::UTF8."

In order to make the installation as easy and fuss-free as possible, and more space-conserving, too, I don't want to require the installation of non-core modules. If there is not a better way to do this, my next version release will abandon all of those useful tests and put in one or more tests which require no unicode at all--just a "free pass" so to speak. This way, at least, the install would be able to complete.

So the question remains, is it even possible to create, and install, a module designed for Perl 5.8.3 compatibility, that provides UTF8 functions, and that does not require any non-core modules--and do this with reasonable UTF8-based tests?

I think I've managed to find a hackish solution that should get me by for now. I've dumped once again (I should not have gone back to it after dropping it the first time) the "Test::More::UTF8" package earlier thought to be a "solution" for the lack of UTF8 compatibility of Test::More...it wasn't, and even when the package was manually installed (not part of core), it tended to generate some inexplicable 'wide character' warnings. So, I went with a pure-ASCII solution, no need even for "use utf8" in the testing script. Instead of testing on actual UTF8 characters, the script now tests on the hexadecimal codepoints returned from the module. If the correct codepoint is returned, the function can legitimately be considered to be installed and functioning. It would have been nice to test on real unicode, but oh well...the module will still work just fine, I'm sure.

 these are the constants from cryptfix
# use constant APOSTROPHE => "’" ;
# use constant OPENQUOTE =>  "“" ;
# use constant CLOSEQUOTE => "”" ;
# use constant COMMA      => "¸" ;

# This is the version from a hex dump of the crypt text file
use constant APOSTROPHE => "\x{e2}\x{80}\x{22}" ;
use constant OPENQUOTE =>  "\x{e2}\x{80}\x{90}" ;
use constant CLOSEQUOTE => "\x{e2}\x{80}\x{9d}" ;
use constant COMMA      => "¸" ;


unless (@ARGV)
{   die "usage: <crypts-text-file>\n" ; }

open(CRYPTS, "<",  $ARGV[0]) or die "Can't open $ARGV[0]: $!" ;
while (my $line = <CRYPTS>)
{   say "apostrophe in line $." if $line =~ /@{[APOSTROPHE]}/;
    say "open quote in line $." if $line =~ /@{[OPENQUOTE]}/;
    say "close quote in line $." if $line =~ /@{[CLOSEQUOTE]}/;
}
[download]

package WWW::OpenAPIClient::Object::AuthorizeRequestDTO;

require 5.6.0;
use strict;
use warnings;
use utf8;
use JSON qw(decode_json);
use Data::Dumper;
use Module::Runtime qw(use_module);
use Log::Any qw($log);
use Date::Parse;
use DateTime;

use base ("Class::Accessor", "Class::Data::Inheritable");

__PACKAGE__->mk_classdata('attribute_map' => {});
__PACKAGE__->mk_classdata('openapi_types' => {});
__PACKAGE__->mk_classdata('method_documentation' => {});
__PACKAGE__->mk_classdata('class_documentation' => {});

# new plain object
sub new {
    my ($class, %args) = @_;

    my $self = bless {}, $class;

    $self->init(%args);

    return $self;
}

# initialize the object
sub init
{
    my ($self, %args) = @_;

    foreach my $attribute (keys %{$self->attribute_map}) {
        my $args_key = $self->attribute_map->{$attribute};
         $self->$attribute( $args{ $args_key } );
    }
}

__PACKAGE__->method_documentation({
    'username' => {
        datatype => 'string',
        base_name => 'Username',
        description => '',
        format => '',
        read_only => '',
            },
    'password' => {
        datatype => 'string',
        base_name => 'Password',
        description => '',
        format => '',
        read_only => '',
            },
});

__PACKAGE__->openapi_types( {
    'username' => 'string',
    'password' => 'string'
} );

__PACKAGE__->attribute_map( {
    'username' => 'USERNAME',
    'password' => 'PASSWORD'
} );

__PACKAGE__->mk_accessors(keys %{__PACKAGE__->attribute_map});


1;
[download]

my %h= ('username' => 'TEST_USER','password' => 'dsds');
my $authobj=WWW::OpenAPIClient::Object::AuthorizeRequestDTO->new(%h);
print Dumper $authobj;

$VAR1 = bless( {
                 'username' => undef,
                 'password' => undef
               }, 'WWW::OpenAPIClient::Object::AuthorizeRequestDTO' );
[download]

I get this weird error when using the JSON or JSON::XS module:

$ perl -MJSON -e ''

XS.c: loadable library and perl binaries are mismatched (got first handshake key 0xeb80080, needed 0xf380080)

And the same error for perl -MJSON::XS -e ''

perl -v
This is perl 5, version 38, subversion 0 (v5.38.0) built for x86_64-li
+nux-thread-multi
...
[download]

What could cause this, and what can I do to fix it?

Hi Monks,

Today I've started to study perlembed, Here is the first code example in Perlembed:

#include <EXTERN.h>               /* from the Perl distribution     */
 #include <perl.h>                 /* from the Perl distribution     *
+/

 static PerlInterpreter *my_perl;  /***    The Perl interpreter    ***
+/

 int main(int argc, char **argv, char **env)
 {
    PERL_SYS_INIT3(&argc,&argv,&env);
        my_perl = perl_alloc();
        perl_construct(my_perl);
    PL_exit_flags |= PERL_EXIT_DESTRUCT_END;
        perl_parse(my_perl, NULL, argc, argv, (char **)NULL);
        perl_run(my_perl);
        perl_destruct(my_perl);
        perl_free(my_perl);
    PERL_SYS_TERM();
    exit(EXIT_SUCCESS);
 }
[download]

#include <EXTERN.h>
#include <perl.h>



 static PerlInterpreter *his_perl ;  /***    The Perl interpreter    *
+**/

 int main(int argc, char **argv, char **env)
 {

    PERL_SYS_INIT3(&argc,&argv,&env);
      
    PERL_SYS_TERM();  his_perl = perl_alloc();
        perl_construct(his_perl);
        PL_exit_flags |= PERL_EXIT_DESTRUCT_END;
        perl_parse(his_perl, NULL, argc, argv, (char **)NULL);
        perl_run(his_perl);
        perl_destruct(his_perl);
        perl_free(his_perl);
    exit(EXIT_SUCCESS);
 }
[download]

Hoping this is an easy problem to solve as my attempts are failing miserably. Using the AI bots and Google only seem to create solutions where the output is all mungled up or the XML elements get repeated, or worse new XML elements are added.

In short, I'm creating a specific soap envelope I need to send to the endpoint web service. The reason is due to complexity and the inability for SOAP::Lite to render the output correctly. This also provides more control for changes as they occur. But when I try to make the call to the web service and send the envelope it seems to be sending the data modified, or the method call is not correct, etc.

I'll post an example below and hopefully someone has a 'duh' answer I seem to be missing.

use SOAP::Lite;
use SOAP::Lite on_action => sub {sprintf '%s/%s',@_};

$proxy = 'https://proxy.com/2.3';
$uri   = 'https://uri.dataservices.training';
$method = 'methodCall';

$soap = SOAP::Lite
 ->proxy($proxy)
 ->uri($uri);

$soapenv = <<'EOF';
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope ... (bunch of NS values)>
<soap:Header>
 (bunch of header settings here)
</soap:Header>
<soap:Body>
 (bunch of body settings here)
</soap:Body>
</soap:Envelope>
EOF

$results = $soap->call("$uri/$method",$soapenv);
[download]

This is resulting in the error "Element ..($uri/$method) ... can't be allowed in valid XML message.