This is a cross post from Perl Monks and Mahalo answers, where I have not received a satisfactory response yet. Thanks for your time and spirit:
Why do I get this error message from perl:
Can't call method "scaleY" on an undefined value at C:/strawberry/perl +/site/lib/ Image/Seek.pm line 137?
I am getting the error in the title when calling the Image::Seek module from my script. My script is basically a rehash of the module's suggested code.
Here's the error again:
Can't call method "scaleY" on an undefined value at C:/strawberry/perl +/site/lib/ Image/Seek.pm line 137.
Here's my code:
#!/usr/local/bin/perl
use Imager;
use Image::Seek qw(loaddb add_image query_id savedb);
loaddb("haar.db");
my $img = Imager->new("photo-1.jpg")
or die Imager->errstr;
# my $img = Imager->new();
# $img->open(file => "photo-1.jpg")or die Imager->errstr;
add_image($img, 1);
savedb("haar.db");
Here's the section of the Image::Seek module causing the issue:
sub add_image_imager {
my ($img, $id) = #_;
my ($reds, $blues, $greens);
require Imager;
my $thumb = $img->scaleX(pixels => 128)->scaleY(pixels => 128);
for my $y (0..127) {
my #cols = $thumb->getscanline(y => $y);
for (#cols) {
my ($r, $g, $b) = $_->rgba;
$reds .= chr($r); $blues .= chr($b); $greens .= chr($g);
}
}
addImage($id, $reds, $greens, $blues); }
Line 137 is:
my $thumb = $img->scaleX(pixels => 128)->scaleY(pixels => 128);
If I remove
->scaleY(pixels => 128)
then line 129:
my #cols = $thumb->getscanline(y => $y);
gives me essentially the same error.
At this point I'm just trying to add one image to the database. There is an image in the directory where I'm running the script to add the image, named "photo-216.jpg". If I change the name to "photo-1.jpg" or "photo-0.jpg" and change the corresponding "add_image" and "query_id" to respectively 1 or 0, it's the same result.
I do have a database that is 385 KB big that comes from running makedb.pl below, but it is filled with null characters. I renamed this "haar.db". This is the database that gives me the error. If I recreate the haar.db file as an empty one, then the script hangs and after a couple of minutes, it give this different message:
"This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information."
If there is no "haar.db" the file still gives me the error in this post's title and unlike running makedb.pl, gives me no database named "haar.db".
By the way I get multiple examples of this post's title error also when trying to run this database filling script: http://www.drk7.jp/pub/imgseek/t/makedb.pl.txt/, which I was alluding to before. I obviously removed the .txt extension before trying it. The makedb.pl script is from this Japanese site: http://www.drk7.jp/MT/archives/001258.html.
If I run makedb.pl in a directory of 2423 scanned collectible postage stamps images, I get 362 instances of the error. The 2423 stamps is the number I have after removing the "small" thumbnail versions which I orignally thought might be causing the issue.
Could it be, that some of the images are less than 128 pixels and that is the issue? However if this is true why does the database get filled with null characters?...Unless they are not really null even though the editor I'm using, Notebook++, says they are.
Also note my images are of stamps which are only sometimes perfect squares. Otherwise, sometimes they are "landscape" sometimes "portrait". Maybe the issue is when the "landscape" scaled images get an X axis of 128 pixels and then their Y axis ends up less or much less. Could this be?
Thanks much
Update: Answer completely re-organized.
Image::Seek is not checking if
scaleX returned error. In your case, for some images, scaleX is failing.
You seem to know for which images scaleX is failing. So, leave your current
code aside, and put together a short test script:
#!/usr/bin/perl
use strict;
use warnings;
use Imager;
die "Specify image file name\n" unless #ARGV;
my ($imgfile) = #ARGV;
my $img = Imager->new;
$img->read( file => $imgfile )
or die "Cannot read '$imgfile': ", $img->errstr;
my $x_scaled = $img->scaleX( pixels => 128 )
or die 'scaleX failed: ', $img->errstr;
my $thumb = $x_scaled->scaleY( pixels => 128 )
or die 'scaleY failed: ', $x_scaled->errstr;
__END__
Running this test script, you got the error message:
Cannot read 'photo-1.jpg': format 'jpeg' not supported - formats bmp,
ico, pnm, raw, sgi, tga available for reading
indicating the underlying problem: When you installed Imager via Strawberry
Perl's cpan, the libraries for png, jpg etc were not installed. One
solution is to build those libraries with the gcc compiler provided with
Strawberry Perl.
First, you will need zlib.
C:\Temp\zlib-1.2.3> copy win32\Makefile.gcc Makefile
Set prefix = /strawberry/c/local in the Makefile. Compile. You may have to
manually copy the files zlib.h and zconf.h to
C:\strawberry\c\local\include and zlib1.dll, libz.a and libzdll.a to
C:\strawberry\c\local\lib (I don't know because I do not use Strawberry Perl very often and my Strawberry environment is very neglected.)
Then, get libpng. I used the source archive without config script.
C:\Temp\libpng-1.2.38> copy scripts\makefile.mingw Makefile
C:\Temp\libpng-1.2.38> make prefix=/strawberry/c/local ZLIBLIB=/strawberry/c/local/lib ZLIBINC=/strawberry/c/local/include
This built the PNG library. Again, you may have to manually copy the .dll,
.a and .h files to the appropriate directories. I did because of my less
than perfect Strawberry environment.
Finally, get the JPEG library.
C:\Temp\jpeg-7> copy Makefile.ansi Makefile
Make sure to edit this file and set CC=gcc. Customize jconfig.h according
to the instructions in jconfig.txt. I used jconfig.dj as a basis.
You might also want to set
CFLAGS= -O2
SYSDEPMEM= jmemansi.o
in Makefile, and
#define DEFAULT_MAX_MEM 4*1024*1024
in jconfig.h. After running make, again copy the files as needed (and as explained by install.txt).
Once the libraries are installed, you can
C:\Temp> SET IM_INCPATH=C:\strawberry\c\local\include
C:\Temp> SET IM_LIBPATH=C:\strawberry\c\local\lib
C:\Temp> cpan
cpan> force install Imager
which yields:
gif: includes not found - libraries not found
ungif: includes not found - libraries not found
jpeg: includes found - libraries found
png: includes found - libraries found
tiff: includes not found - libraries not found
freetype2: includes not found - libraries not found
freetype2: not available
T1-fonts: includes not found - libraries not found
TT-fonts: includes not found - libraries not found
w32: includes found - libraries found
If all of this is too much work, it is ... sigh I just realized the
binaries are available at GnuWin32.
Related
After booting SWUpdate yocto-generated image for the first time, executing swupdate results in error message:
Error parsing configuration file: 'globals' section missing, exiting.
I tried to strictly follow SWUpdate's documentation, but it gets short when it comes to yocto integration. I'm using meta-swupdate, meta-swupdate-boards, and meta-openembedded layers together with poky example repository all at Kirkstone tag, building via bitbake update-image and having modyfied local.conf as:
MACHINE ??= "raspberrypi4-64"
ENABLE_UART = "1"
RPI_USE_U_BOOT = "1"
IMAGE_FSTYPES = "wic ext4.gz"
PREFERRED_PROVIDER_u-boot-fw-utils = "libubootenv"
IMAGE_INSTALL:append = " swupdate"
Is there anything else I need to modify to generate the configuration file and be able to run SWUpdate binary properly?
Side question: In the documentation, it's recommended to append swupdate-www to achieve a better web server. However, if I append it, there is no swupdate-www binary inside the `/usr/bin' directory.
As with other recipes folders the recipes-support/swupdate/swupdate/raspberrypi4-64 folder was missing inside the meta-swupdate-boards layer. Therefore, an empty config file was always generated. After adding this folder and all related files, strongly inspired by raspberrypi3 folder, the error was gone and swupdate -h provided the expected output.
There was also one new error during build process thrown by yocto. It was related to missing systemd requirement and was solved by adding:
DISTRO_FEATURES_append = " systemd"
to local.conf
gitolite info didn't work, adding keys turned them into a no access key and did NOT create a corresponding entry in auth-keys file.
To fix this run gitolite setup on gitolite server
Question: what could have landed me in that mess?
And what does gitolite setup do when invoked for the n-th time (it's no longer setting things up, according to the docs it fixes hooks, but I wonder what the use case would be and which was mine)?
More details on gitolite info
gitolite info command is invoked like so:
> ssh git-user#ser-git
PTY allocation request failed on channel 0
hello git-admin, this is ...#... running gitolite3 3.6.7-2 (Debian) on git 2.17.1
R W some-repository
R W gitolite-admin
R W testing
Connection to ser-git closed.
Bad output is: FATAL: unknown git/gitolite command: 'info'
More details: keys without access.
gitolite sshkeys-lint was showing keys with (no access), now those keys have access as I set them (now meaning after gitolite setup).
ssh-keygen -lf /home/repo/.ssh/authorized_keys | wc -l (or without piped part, regardless) number of keys and their names indicated I didn't have the newest one added.
Similar question that did not work for me: keydir entries not propagating to authorized_keys
Docs pretty much had the answer once I dug deeper, I guess. Which is fairly nice of #sitaramc.
Without options, 'gitolite setup' is a general "fix up everything" command
(for example, if you brought in repos from outside, or someone messed
around with the hooks, or you made an rc file change that affects access
rules, etc.)
Symptoms keys stopped propagating and error FATAL: unknown git/gitolite command: 'info' on ssh git-user#ser-git. Fix was to run gitolite setup. So onto first question, the title one:
what does gitolite setup fix?
gitolite setup is implemented here
my Perl is rather weak, but there's a setup function in line 56. It calls args (which parses options, so here it had nothing to parse), then unless h_only (hooks only arg for setup), which wasn't used, so we skip compile and POST_COMPILE trigger and go for the hooks.
sub setup {
my ( $admin, $pubkey, $h_only, $message ) = args();
unless ($h_only) {
setup_glrc();
setup_gladmin( $admin, $pubkey, $message );
_system("gitolite compile");
_system("gitolite trigger POST_COMPILE");
}
hook_repos(); # all of them, just to be sure
}
package Gitolite::conf::store has hook_repos(), line 228: we change the dir to repo base dir (as per config file), and for each phy_repo we do hook_1(phy_repo). What is a phy_repo? a physical one.
same package, different method and line: hook_1($repo) in line 354.
Method hook_1($repo)
It's quite literally about fixing all the hooks.
Recreates dirs for common and admin hooks.
Rewrites update_hook (common) and post_update_hook (admin).
Sets 755 permissions for both common and admin hooks.
Then using ln_sf it symlinks the folders for common/admin hooks.
ln_sf is in common module, in line 162
I am trying to run ADNI .mnc image in MATLAB
I added folder emma-master, niak-0.7.1-ammo, mia and niak-0.7.1-ammo to my path. All these folders are located in
D:\EMINA BURCH\PhD Thesis\MATLAB Packages
But when I want to open ._bq_t_15T.mnc located also in D:\EMINA BURCH\PhD Thesis\MATLAB Packages
that is h = openimage('._bq_n_15T.mnc')
I get the following error
Error using miinquire (line 145)
Error getting image dimensions from file D:\EMINA BURCH\PhD Thesis\MATLAB Packages._bq_n_15T.mnc
Error in openimage (line 173)
DimSizes = miinquire (filename, 'imagesize');
When I enter debug mode in minquire function after the line
[stat,out] = system(['mincinfo -vardims image ' minc_file]);
I get stat = 1 and out = 'mincinfo' is not recognized as an internal or external command, operable program or batch file.
May You, please help me with this issue.
system isn't able to automatically recognise the different requirements that might be needed to run the same system command on different operating systems. Using commands like ispc, isunix, ismac and computer, you can automatically check and call different versions of the commands as appropriate:
if ispc
[stat,out] = system(['mincinfo.exe -vardims image ' minc_file]);
else
[stat,out] = system(['mincinfo -vardims image ' minc_file]);
end
Of course, you also have to have the appropriate program on your MATLAB path for this to work.
After successfully installation of Apache2(2.4.4) i tried to start https server but i am getting below error
bimlesh#server:/usr/local/apache2/bin$ ./apachectl start
httpd: Syntax error on line 71 of /usr/local/apache2/conf/httpd.conf: Cannot load modules/mod_authn_core.so into server: /usr/local/apache2/modules/mod_authn_core.so: cannot open shared object file: No such file or directory
bimlesh#server:/usr/local/apache2/bin$
I looked at /usr/local/apache2/modules/ and really those .so files are not available.
Can anyone please help that how to get rid off.
if i look at /usr/local/apache2/modules/ folder then i see:(no .so files available)
bimlesh#server:/usr/local/apache2/bin$ ls ../modules/
httpd.exp mod_authn_file.a mod_cache_disk.a mod_file_cache.a mod_logio.la mod_ratelimit.a mod_socache_dbm.la
mod_access_compat.a mod_authn_file.la mod_cache_disk.la mod_file_cache.la mod_mime.a mod_ratelimit.la mod_socache_memcache.a
mod_access_compat.la mod_authn_socache.a mod_cache.la mod_filter.a mod_mime.la mod_remoteip.a mod_socache_memcache.la
mod_actions.a mod_authn_socache.la mod_cgid.a mod_filter.la mod_negotiation.a mod_remoteip.la mod_socache_shmcb.a
mod_actions.la mod_authz_core.a mod_cgid.la mod_headers.a mod_negotiation.la mod_reqtimeout.a mod_socache_shmcb.la
mod_alias.a mod_authz_core.la mod_dav.a mod_headers.la mod_proxy.a mod_reqtimeout.la mod_speling.a
mod_alias.la mod_authz_dbd.a mod_dav_fs.a mod_include.a mod_proxy_ajp.a mod_request.a mod_speling.la
mod_allowmethods.a mod_authz_dbd.la mod_dav_fs.la mod_include.la mod_proxy_ajp.la mod_request.la mod_status.a
mod_allowmethods.la mod_authz_dbm.a mod_dav.la mod_info.a mod_proxy_balancer.a mod_rewrite.a mod_status.la
mod_auth_basic.a mod_authz_dbm.la mod_dbd.a mod_info.la mod_proxy_balancer.la mod_rewrite.la mod_substitute.a
mod_auth_basic.la mod_authz_groupfile.a mod_dbd.la mod_lbmethod_bybusyness.a mod_proxy_connect.a mod_sed.a mod_substitute.la
mod_auth_digest.a mod_authz_groupfile.la mod_deflate.a mod_lbmethod_bybusyness.la mod_proxy_connect.la mod_sed.la mod_unique_id.a
mod_auth_digest.la mod_authz_host.a mod_deflate.la mod_lbmethod_byrequests.a mod_proxy_express.a mod_session.a mod_unique_id.la
mod_auth_form.a mod_authz_host.la mod_dir.a mod_lbmethod_byrequests.la mod_proxy_express.la mod_session_cookie.a mod_unixd.a
mod_auth_form.la mod_authz_owner.a mod_dir.la mod_lbmethod_bytraffic.a mod_proxy_fcgi.a mod_session_cookie.la mod_unixd.la
mod_authn_anon.a mod_authz_owner.la mod_dumpio.a mod_lbmethod_bytraffic.la mod_proxy_fcgi.la mod_session_dbd.a mod_userdir.a
mod_authn_anon.la mod_authz_user.a mod_dumpio.la mod_lbmethod_heartbeat.a mod_proxy_ftp.a mod_session_dbd.la mod_userdir.la
mod_authn_core.a mod_authz_user.la mod_env.a mod_lbmethod_heartbeat.la mod_proxy_ftp.la mod_session.la mod_version.a
mod_authn_core.la mod_autoindex.a mod_env.la mod_log_config.a mod_proxy_http.a mod_setenvif.a mod_version.la
mod_authn_dbd.a mod_autoindex.la mod_expires.a mod_log_config.la mod_proxy_http.la mod_setenvif.la mod_vhost_alias.a
mod_authn_dbd.la mod_buffer.a mod_expires.la mod_log_debug.a mod_proxy.la mod_slotmem_shm.a mod_vhost_alias.la
mod_authn_dbm.a mod_buffer.la mod_ext_filter.a mod_log_debug.la mod_proxy_scgi.a mod_slotmem_shm.la
mod_authn_dbm.la mod_cache.a mod_ext_filter.la mod_logio.a mod_proxy_scgi.la mod_socache_dbm.a
bimlesh#server:/usr/local/apache2/bin$
Run
find / -type f -name mod_authn_core.so
or install updatedb ( mlocate, slocate, findutils or sth ) if needed and run
updatedb
and then ( or before )
locate mod_authn_core.so
To find out if these files are somewere else than they should be, and possibly fix location with symbolic link or moving files where they're expected to be.
If there is no file you need, you may need to comment it in httpd.conf ( if it's specific module ), or (re)install apache package(s). I believe mod_authn_core should be in basic package, not in separate module though. Possibly someone removed it blindly or accidentally, or some intruder messed up with system, or disk got broken or whatever else.
PS. Modules usually are under "lib" e.g. /usr/local/lib/apache2 or /usr/lib/apache2, or /usr/lib/apache2/modules or similar, not in /usr/local/apache2/modules, though it usually depends on compilation of package..
You might also run
apache2ctl -t -D DUMP_VHOSTS
to find out what modules were compiled as shared or static. You should also include information about distribution, and note you're building/installing from source.
Also, have look here: http://httpd.apache.org/docs/2.4/install.html#configure
The project I'm working in uses fabric for many build steps and requires a offline build as fallback.
I'm currently stuck at installing python packages provided in tarballs.
The thing is I have trouble getting into the newly extracted directory and running setup.py install in there.
#task
def deploy_artifacts():
"""Installs dependencies from local path, useful for offline builds"""
#TODO: Handle downloading files and do something like this bellow
tmpdir = tempfile.mkdtemp()
artifacts_path = ''
if not 'http' in env.artifacts_path:
artifacts_path = env.artifacts_path
with lcd(artifacts_path):
for f in os.listdir(artifacts_path):
if 'gz' in f:
put(f, tmpdir)
tar = os.path.join(tmpdir, f)
target_dir = os.path.join(tempfile.gettempdir(), normalize(f))
if not files.exists(target_dir):
run('mkdir %s' % target_dir)
else:
run('rm -rf %s' %target_dir)
run('mkdir %s' % target_dir)
run('tar xf %s -C %s' % (tar, target_dir))
run('rm %s' % tar)
with cd(target_dir):
sudo('python setup.py install')
I come from reading the tar man page for the bazillion time and I got nowhere near to getting what I want.
Did some of you face a situation like this? is there some other (read: better) approach to this scenario?
There's nothing wrong (in principle) with what you're trying do. Maybe just take smaller steps getting there. Rather than using temporary directories, it might make debugging easier if everything was put in a systematic location that has known permissions that nothing else writes to by convention. At least that would let you use some combination of fabric and manual intervention to check what is going wrong.
In the longer term, there are a few alternatives that I see. For simplicity you want the online and offline versions to work the same way, and that means fetching packages using easy_install / pip for both cases.
One way to do this is to build a mirror of PyPi. The right way to do this if you've got plenty of storage space (30Gb) is to use software that implements PEP381 (Mirroring Infrastructure for PyPI), there is already a client that does this (pep381client). A number of other projects are available that do similar things (basketweaver, djangopypi2, chishop).
An alternative is to consider a lighter weight proxying scheme. I've been looking a pip2pi and pipli. I'm unsure if they will work directly with easy_install, but it would be worth a try.
It's also worth noting that if you were using pip, you could have installed directly from the tarballs.