Re: [Cava Packager] "Unknown Windows version" error when running on Windows 8

[Cava Support]

Hi,

The 'Unknown Windows Version' error is something I'll have to provide a
workaround for in the Cava code.

Your exe crash is unrelated and occurs because no YAML module is getting
packaged by Cava.

YAML::Any does indeed call Carp::Croak (upper case) which looks like an
error in that module to me.

The error code is never entered in normal usage as YAML::XS or YAML
(etc.) exists in your Perl @INC.

The work around for you is to add

use YAML;

to the top of your EH2.pl script so that it

a) gets packaged
b) gets loaded

before YAML::Any.

(You could 'use YAML::XS;' instead if you prefer.)

Hope it helps

Mark

On 29/10/2012 11:18, Ed Kolis wrote:
> When I run Cava Packager on Windows 8 and try to build a project, I get
> these errors in the log:
>
> stderr : Unknown Windows version [2:6:2] at
> C:/PROGRA~1/CAVAPA~1.0/lib/std/Win32.pm line 530.
> stderr : Use of uninitialized value $name in concatenation (.) or string
> at C:/PROGRA~1/CAVAPA~1.0/lib/std/CF.pm line 612.
> stderr : Use of uninitialized value $data in concatenation (.) or string
> at C:/PROGRA~1/CAVAPA~1.0/lib/std/CF.pm line 612.
>
> The build completes successfully anyway, but the exe I've created crashes
> with an error:
> Undefined subroutine&Carp::Croak called at
> C:/Users/Ed/Documents/EclipseWorkspa
> ce/eh2/package/release/EH2/lib/std/YAML/Any.pm line 116.
> BEGIN failed--compilation aborted at
> C:/Users/Ed/Documents/EclipseWorkspace/eh2/
> package/release/EH2/lib/std/lib/IO_YAML.pm line 3.
> Compilation failed in require at
> C:/Users/Ed/Documents/EclipseWorkspace/eh2/pack
> age/release/EH2/lib/std/lib/IO_parse.pm line 6.
> BEGIN failed--compilation aborted at
> C:/Users/Ed/Documents/EclipseWorkspace/eh2/
> package/release/EH2/lib/std/lib/IO_parse.pm line 6.
> Compilation failed in require at
> C:/Users/Ed/Documents/EclipseWorkspace/eh2/pack
> age/release/EH2/lib/std/cavaexecscript/EH2.pl line 9.
> BEGIN failed--compilation aborted at
> C:/Users/Ed/Documents/EclipseWorkspace/eh2/
> package/release/EH2/lib/std/cavaexecscript/EH2.pl line 9.
> Not sure if the latter problem is related to the former in any way, though.
> Isn't the subroutine called Carp::croak (with a lowercase c), not
> Carp::Croak (with a capital C), anyway? Why would the YAML module be
> calling it with a capital C? The Perl script runs just fine if I run it
> normally (without packaging it as an exe)...
>

--
User Support
Cava Development Tools
Package and Distribute Perl Applications
http://www.cavapackager.com/

[Ed Kolis]

Thanks! 

 

The "use YAML;" fixed the YAML problem; now I just need to figure out why the program's crashing not being able to find any graphics! The graphics got packaged into the lib/std/graphics folder, but when I run the program, it can't find them. It normally looks in ./graphics, but it still couldn't find them even after I copied the graphics folder to the location of my exe!

[Cava Support]

Hi,

In your code:

use Cava::Packager;
Cava::Packager::SetResourcePath('c:/full/pathtofolder/graphics');

# to get file path to c:/full/pathtofolder/graphics/somefilename.png in
your code:

my $filepath = Cava::Packager::GetResource('somefilename.png');


When packaging, in Cava Packager application, set your Resource Folder to

c:/full/pathtofolder/graphics


All you graphics files should get packaged and the
my $filepath = Cava::Packager::GetResource('somefilename.png');

will work in the packaged app and plain Perl script.

You can remove the code that packages stuff in lib/std/graphics

Regards

Mark

[Ed Kolis]

On Tuesday, November 6, 2012 10:48:44 AM UTC-5, cava-admin wrote:

Hi,

In your code:

use Cava::Packager;
Cava::Packager::SetResourcePath('c:/full/pathtofolder/graphics');

# to get file path to c:/full/pathtofolder/graphics/somefilename.png in
your code:

my $filepath = Cava::Packager::GetResource('somefilename.png');

 

So I have to reference the packager in my code? I'd rather not have to do that - why can't my code access the filesystem anymore just because I packaged it? (I also want the packaged code to be portable... I guess if I used the packager I could configure it in code with a config file or something though?)

 

You can remove the code that packages stuff in lib/std/graphics

 

I don't have any code to package it there - it's only there because I used directory slurp to put it there. Is there a better way of including content in a packaged application that doesn't require referencing the packager in my code?

[Ed Kolis]

By the way, this is really weird, but it might be a clue for you, Mark - I have two folders I want to include with the packaged application. One is called "mods", while the other is called "graphics". The files in the "mods" folder can be loaded just fine when I copy the folder to the bin folder where the exe sits. But the files in the "graphics" folder for some reason I can't load - the application says they aren't there! 

[Jeffrey Ray]

I'm not using windows 7, i'm not sure if your graphics issue is constricted to windows 8. If so, then I guess you can ignore the rest of the message.

The way I package and use graphics in my app is like this. When developing the application, I create a  "res\graphics" directory in the root folder. In Cava Packager, under "Resources" I select "res" as the resource path.

And then I use the relative path within my application to access the image:

Gtk2::Image->new_from_file( 'res\graphics\image.png' )

The application can find the image when running from the command line during development and after being packaged.

On Thu, Nov 8, 2012 at 3:39 PM, Ed Kolis <edk...@gmail.com> wrote:

By the way, this is really weird, but it might be a clue for you, Mark - I have two folders I want to include with the packaged application. One is called "mods", while the other is called "graphics". The files in the "mods" folder can be loaded just fine when I copy the folder to the bin folder where the exe sits. But the files in the "graphics" folder for some reason I can't load - the application says they aren't there! 

--
You received this message because you are subscribed to the Google Groups "Cava Packager" group.

To view this discussion on the web visit https://groups.google.com/d/msg/cava-packager/-/lOPVdqn_CTMJ.

To post to this group, send email to cava-p...@googlegroups.com.
To unsubscribe from this group, send email to cava-package...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cava-packager?hl=en.

[Johan Vromans]

Ed Kolis <edk...@gmail.com> writes:

> So I have to reference the packager in my code? I'd rather not have to
> do that - why can't my code access the filesystem anymore just because
> I packaged it?

You can access the file system without limitations. However, it was
assumed you want to access files that are part of the package, not of
the file system.

To access files that are part of the package you need packager specific
calls. That's inherent to packaging.

> Is there a better way of including content in a packaged application
> that doesn't require referencing the packager in my code?

Once you have the location of the resource directory you can access all
files normally,

You can probably find packages files in @INC when you package them with
Package Method: Plain text and Package Location: Standard @INC path.

-- Johan

[Ed Kolis]

On Thursday, November 8, 2012 4:14:25 PM UTC-5, Jeffrey Ray wrote:

The way I package and use graphics in my app is like this. When developing the application, I create a  "res\graphics" directory in the root folder. In Cava Packager, under "Resources" I select "res" as the resource path.

And then I use the relative path within my application to access the image:

Gtk2::Image->new_from_file( 'res\graphics\image.png' )

The application can find the image when running from the command line during development and after being packaged.

 

 

Oh, OK, so I want to use the resources option in the packager, not the directory slurp? I thought about using resources, but the problem is that I have two directories that I want to use as resource directories, and the packager seems to let me use only one... I guess I could put them in a "res" directory, but I might have to talk with the other guy who's working on this project with me :)

 

I guess if we ever got around to not hardcoding the relative paths to these directories, this wouldn't be as much of a problem, though!

[Cava Support]

Hi,

On 09/11/2012 02:32, Ed Kolis wrote:

>
> I guess if we ever got around to not hardcoding the relative paths to these
> directories, this wouldn't be as much of a problem, though!
>

I don't think this is really a Cava issue. I don't think your base Perl
code is portable regardless of whether it is packaged or not.

"./graphics" is not a relative path. It is a fixed path with the current
working directory at the head. This can only work if the current working
directory, at the time the string is interpolated, contains the sub
directory graphics.

I'd guess this always works for you when running under the plain Perl
interpreter because you always change directory to the folder where the
script is before running it. You can make this scheme work for the
script packaged with Cava simply by imposing the same restrictions on
users of the executable. That is, they must change directory to the
folder where the executable resides. Then "./graphics" will work fine
(assuming the "./graphics" folder exists ) for exactly the same reasons
it works when you run your script.

Once you have code in your script that works in more than one specific
execution circumstance, likely as not it will work in Cava in more than
one specific execution circumstance too.

Using Cava::Packager methods just gives you some short-cuts to
determining relative paths that are known to work. Feel free to code
your own. But you must have some method of getting the relative location.

Cheers

Mark

[Ed Kolis]

Sorry, but I'm not quite clear on what a "relative path" is, then, if it isn't relative to the working directory!

 

I did notice, however, that the mod files are specified as, e.g. mods/stock/thrusters.eggs, while the graphics are specified as, e.g. ./graphics/thruster-small.tga. Not sure why the ./ is present on the graphics folder, but I'll try removing it and seeing if that helps!

[Ed Kolis]

Oh, actually, neither of them has a ./ prefix anymore! Hmm...