Menu
▾
▴
ids-devel — IDS developers use this list
You can subscribe to this list here.
| 2001 |
Jan
(2) |
Feb
(48) |
Mar
(16) |
Apr
(14) |
May
(42) |
Jun
(36) |
Jul
(57) |
Aug
(13) |
Sep
(2) |
Oct
(23) |
Nov
(17) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(5) |
Feb
|
Mar
(10) |
Apr
(1) |
May
(6) |
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(12) |
Oct
(26) |
Nov
(11) |
Dec
(37) |
| 2003 |
Jan
(11) |
Feb
(27) |
Mar
(5) |
Apr
(21) |
May
(11) |
Jun
(38) |
Jul
(8) |
Aug
(29) |
Sep
(2) |
Oct
|
Nov
(7) |
Dec
(5) |
| 2004 |
Jan
(5) |
Feb
(2) |
Mar
(19) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
| 2005 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(4) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(8) |
|
From: Ashley M. K. <as...@pc...> - 2001-07-12 18:36:54
|
I have some rather...uh...odd sized images and I'm noticing
something weird with the way the album PNGs are created.
The images are either 3900x400 (or less than 400), or 400x3900 (in
other words, they are very skinny, and long). Now, if it's an
horizontal image, the thumbnail gets created by sizing the *height* of
the image to the height of the thumbnail needs, and the rest gets
cropped - this works fine. However, if it's a vertical image, it takes
the full height of the image (3900 pixels), sizes that down to the
thumbnail height. Consequently, you end up with a thumbnail that has a
very tiny image left aligned, and the rest of the thumbnail is blank (or
whatever album_preview.png is).
I would've guess the vertical resizing would check the width vs.
height of the image and resize accordingly (in this case, grab the width
of the image and size that to the width of the thumbnail and crop the
rest of the image off, so that the thumbnail would (still) have a full
size preview in it, and not a tiny strip) - an I making sense?
AMK4
--
H | Hi, I'm currently out of my mind. Please leave a message. BEEEEP!
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130
Director of Internet Operations / SysAdmin . 800.441.3873 x130
Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave, #6
http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
|
|
From: Rick B. <Ri...@Bi...> - 2001-07-07 22:05:52
|
On Sat, 7 Jul 2001, Rick Byers wrote: > Regardless, it works fine if I have Albums and Albums/MyAlbum > as real directory, but fails if MyAlbum is a sym-link to somewhere else. Ok, so I just realized that when I used the sym-link I also had some sub-directories that I wasn't aware of. So I think it was the "nested albums" causing trouble, not the symlink. Still not sure what is causing the problem, but I'll worry about it some other time.... Thanks, Rick |
|
From: Rick B. <Ri...@Bi...> - 2001-07-07 20:48:30
|
On Sat, 7 Jul 2001, John Moose wrote: > This is one of the many reasons for re-writing IDS. URL's and paths are > a lot cleaner and more consistent in IDS 1.0. Awesome. Is 1.0 far enough along to start using it, or should I stick with 0.711? Any idea when you expect 1.0 to be nearly complete? I'm just wondering if I should start hacking on .711 and submitting patches (I've got a bunch of things I want to add/change), or just be patient until 1.0 is ready for use. > As for 0.711, I use symlinks quite often and don't experience that > problem. I don't think IDS ever changes its working directory. The > working directory should always be the same directory as the CGI. If you > are using the admin, postcomment, or commentviewer CGI (located in > subdirectories), "../" is prepended to some paths. Look for the $ppath > variable. Hmm.. I'll have to look at the problem further. It was failing a command like "makedir( ../album-data/blah)", so I was just assuming cwd was "Albums" which was a sym-linked directory, so that "../album-data" was invalid. Its probably just a bug somewhere causing the ../ to get inserted. Regardless, it works fine if I have Albums and Albums/MyAlbum as real directory, but fails if MyAlbum is a sym-link to somewhere else. I'll try to figure out where the ../ is coming from later and submit a patch. My Perl is a little rusty, but I've seen some things that look strange to me. I.e. is "x =~ s/[..\/]*albums//" really correct, or should it be "s/(..\/)*albums//"? I thought Perl's regular expressions were almost the same as standard REs (where [] is used to specify a list/sequence of possible characters like [a-z]). Thanks, Rick |
|
From: John M. <mo...@mu...> - 2001-07-07 20:01:14
|
This is one of the many reasons for re-writing IDS. URL's and paths are a lot cleaner and more consistent in IDS 1.0. As for 0.711, I use symlinks quite often and don't experience that problem. I don't think IDS ever changes its working directory. The working directory should always be the same directory as the CGI. If you are using the admin, postcomment, or commentviewer CGI (located in subdirectories), "../" is prepended to some paths. Look for the $ppath variable. I believe that the only time a variable named "$path" is used is when I use the "fileparse" function, but those are not at all consistent. It definitely doesn't contain the working path. John On Saturday, July 7, 2001, at 01:52 PM, Ashley M. Kirchner wrote: > Rick Byers wrote: > >> Or, if having to set a path variable was undesirable, how about just >> not >> changing the current working directory. Or, better yet - store the >> cwd on startup and use it for generation of absolute paths. > > Actually, it does store its working path in the $path variable. It > just doesn't > use it all the time. Uh, John? Wanna chime in here as to...why? > > >> Yeah, that makes sense but isn't that problem already present in the >> current system? There is allways a WWW-space and file-space >> discontinuity >> possibility, I don't see how using ".." vs. absolute paths makes any >> difference in that respect. > > I was referring to my previous suggestion, not whether using '..' > would make a > difference. :) Although, what would you prefer seeing? > http://somehost/ids/albums/../image-cache/blah blah, or > http://somehost/ids/image-cache/blah blah ? > > Granted, it doesn't do that now, but I have seen places where some > (rather > poorly) programmed script did that because they insisted on using '..' > instead of a > fixed $path (which then gets translated to a WWW url). > > AMK4 - [ coming soon : PhotoCorners Theme v1.0 ] > [ preview at http://photos.yeehaw.net/ ] > > -- > H | Hi, I'm currently out of my mind. Please leave a message. BEEEEP! > +-------------------------------------------------------------------- > Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130 > Director of Internet Operations / SysAdmin . 800.441.3873 x130 > Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave, #6 > http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A. > > > > _______________________________________________ > IDS-devel mailing list > IDS...@li... > http://lists.sourceforge.net/lists/listinfo/ids-devel |
|
From: Ashley M. K. <as...@pc...> - 2001-07-07 17:53:40
|
Rick Byers wrote:
> Or, if having to set a path variable was undesirable, how about just not
> changing the current working directory. Or, better yet - store the
> cwd on startup and use it for generation of absolute paths.
Actually, it does store its working path in the $path variable. It just doesn't
use it all the time. Uh, John? Wanna chime in here as to...why?
> Yeah, that makes sense but isn't that problem already present in the
> current system? There is allways a WWW-space and file-space discontinuity
> possibility, I don't see how using ".." vs. absolute paths makes any
> difference in that respect.
I was referring to my previous suggestion, not whether using '..' would make a
difference. :) Although, what would you prefer seeing?
http://somehost/ids/albums/../image-cache/blah blah, or
http://somehost/ids/image-cache/blah blah ?
Granted, it doesn't do that now, but I have seen places where some (rather
poorly) programmed script did that because they insisted on using '..' instead of a
fixed $path (which then gets translated to a WWW url).
AMK4 - [ coming soon : PhotoCorners Theme v1.0 ]
[ preview at http://photos.yeehaw.net/ ]
--
H | Hi, I'm currently out of my mind. Please leave a message. BEEEEP!
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130
Director of Internet Operations / SysAdmin . 800.441.3873 x130
Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave, #6
http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
|
|
From: Rick B. <Ri...@Bi...> - 2001-07-07 17:40:44
|
On Sat, 7 Jul 2001, Ashley M. Kirchner wrote: > > Am I correct in guessing that there isn't any easy way to modify ids-0.711 > > to either use a configured-root path or to not change its working > > directory to avoid the problems with ..? I played around with the code > > for a bit, but it didn't appear to be an easy change. > > This is something that has come up (on my end) before and for the time > being I've learned to live with it (read: I don't make symlinks). Although, > it shouldn't be all too hard to do. If IDS had a configurable $path setting > (aside from the dynamic guessing of the $path), I don't see why we can't > change it to use $path/<whatever> instead of ../<whatever> Or, if having to set a path variable was undesirable, how about just not changing the current working directory. Or, better yet - store the cwd on startup and use it for generation of absolute paths. > The catch here is that a lot of times, the $path won't correspond to what > the web sees. For example, if my path on the server was ~user/www/ids, > http:// might guess my URL to be http://host/~user/ids (sans the www) part, > however, I may have a completely different setting for it (which I do by the > way), so not only would you need a physical $path setting for IDS internals to > work, but you'd also need a routine that translates that $path into what the > web would see. Am I making sense? Yeah, that makes sense but isn't that problem already present in the current system? There is allways a WWW-space and file-space discontinuity possibility, I don't see how using ".." vs. absolute paths makes any difference in that respect. Thanks, Rick |
|
From: Ashley M. K. <as...@pc...> - 2001-07-07 17:38:49
|
Rick Byers wrote:
> Am I correct in guessing that there isn't any easy way to modify ids-0.711 to either use a configured-root path or to not change its working directory to avoid the problems with ..? I played around with the code for a bit, but it didn't appear to be an easy change.
This is something that has come up (on my end) before and for the
time being I've learned to live with it (read: I don't make symlinks).
Although, it shouldn't be all too hard to do. If IDS had a configurable
$path setting (aside from the dynamic guessing of the $path), I don't
see why we can't change it to use $path/<whatever> instead of
../<whatever>
The catch here is that a lot of times, the $path won't correspond to
what the web sees. For example, if my path on the server was
~user/www/ids, http:// might guess my URL to be http://host/~user/ids
(sans the www) part, however, I may have a completely different setting
for it (which I do by the way), so not only would you need a physical
$path setting for IDS internals to work, but you'd also need a routine
that translates that $path into what the web would see. Am I making
sense?
AMK4 - [ coming soon : PhotoCorners Theme v1.0 ]
[ preview at http://photos.yeehaw.net/ ]
--
H | Hi, I'm currently out of my mind. Please leave a message. BEEEEP!
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130
Director of Internet Operations / SysAdmin . 800.441.3873 x130
Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave, #6
http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
|
|
From: Rick B. <Ri...@Bi...> - 2001-07-07 17:06:51
|
Hello again, I really like how IDS stores album data and cache in a directory seperate from the main album. I keep all my pictures in one location on my server, and I don't want to clutter that up with stuff specific to the web-based photo album. However, I'm having problems due to IDS's usage of "../". It looks like it changes directories to the album dir and then tried to use ../ to get to the album-data directory. If I use a sym-link for the Album dir, then I get all sorts of errors like: "mkdir ../album-data/MovieParty/1024//: No such file or directory at ../idsShared.pm line 775". Am I correct in guessing that there isn't any easy way to modify ids-0.711 to either use a configured-root path or to not change its working directory to avoid the problems with ..? I played around with the code for a bit, but it didn't appear to be an easy change. Thanks, Rick |
|
From: Rick B. <Ri...@Bi...> - 2001-07-07 17:03:09
|
Hi, I'm using IDS-0.711 and its awesome! However, as with other software, I noticed its quite slow displaying an image thats already in the cache. Since this shouldn't require loading the image into memory on the server (which is understandably slow on my poor 32Mb machine), I poked around for a bit to figure out what was going on.... In generateImage (index.cgi:650), ImageMagick is used to read the image and extract any embedded comments (if displayImageData is on). This requires loading the whole image (which is huge in my case) into memory. Is there a reason Image::Info couldn't be used here instead? Neither Image::Info or ImageMagick get the embedded comments saved by my digital camera software (CAMEDIA Master), so I've just disabled that whole section and things run much quicker. Not quite sure whats wrong, but I don't use the comment field anyway (all the other Exif fields work). Thanks, Rick |
|
From: Brian W. <bwe...@xb...> - 2001-07-03 06:16:54
|
On Mon, 2 Jul 2001, John Moose wrote: > OK, you can get the untested, may-change-at-any-time, unoptimized, > developmental version of IDS 1.0 here: > > http://arwen.hn.org/~john/ids-devel/ Thanks. > There is no support for comments, no admin CGI, and the previewmaker and > updater scripts don't work. There also appears to be a problem with URL generation - clicking on links sometimes adds an extra /ids into the URL - for example, it gives an error loading: http://www.xbill.org/ids/ids/ids/data/themes/Ziggo/styles.css which should be: http://www.xbill.org/ids/data/themes/Ziggo/styles.css > I doubt you'll see good performance on a P166. ImageMagick requires a > lot of horsepower and eats quite a bit of RAM. Understandable. I wouldn't expect image manipulation to be affected, but some pages were taking multiple seconds to load when the images were already present. I assumed that this was because of the interpreter load time, and 1.0a1 does seem faster. All the same, I imagine it will be a lot better when I upgrade the machine. Thanks! Brian |
|
From: John M. <mo...@mu...> - 2001-07-02 20:44:37
|
OK, you can get the untested, may-change-at-any-time, unoptimized,=20 developmental version of IDS 1.0 here: http://arwen.hn.org/~john/ids-devel/ There is no support for comments, no admin CGI, and the previewmaker and=20= updater scripts don't work. I doubt you'll see good performance on a P166. ImageMagick requires a=20 lot of horsepower and eats quite a bit of RAM. This version of IDS runs _a lot_ faster under mod_perl=96 I think it's=20= currently slower than 0.711 when not under mod_perl. Here's the appropriate section from my httpd.conf: ________________ Alias /ids/ /usr/local/apache/ids/ PerlModule Apache::Registry <Location /ids> SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI <IfModule mod_dir.c> DirectoryIndex index.cgi </IfModule> allow from all PerlSendHeader On </Location> <Location /ids/albums> SetHandler default-handler </Location> <Location /ids/data> SetHandler default-handler </Location> <Location /ids/cache> SetHandler default-handler </Location> <Location /ids/themes> SetHandler default-handler </Location> PerlRequire /usr/local/apache/conf/startup.pl ________________ and startup.pl: ________________ #!/usr/bin/perl use strict; # Extend @INC if needed use lib qw(/usr/local/apache/ids/lib); # Make sure we are in a sane environment. $ENV{MOD_PERL} or die "not running under mod_perl!"; use Apache::Registry; use CGI::Application; use Config::General::Extended (); use POSIX (); use FileHandle (); use File::Basename (); use Time::Local (); use File::Find (); use File::Path (); use Image::Magick (); use Image::Info qw(image_info); # Tell me more about warnings use Carp (); $SIG{__WARN__} =3D \&Carp::cluck; # Load CGI.pm and call its compile() method to precompile # (but not to import) its autoloaded methods. use CGI qw(-compile :all); 1; ________________ Enjoy! John On Sunday, July 1, 2001, at 05:26 PM, Brian Wellington wrote: > Is there any chance of getting a snapshot of the IDS 1.0 rewrite? I=20= > just > found IDS today, and it looks really cool, but the current release = runs > very slowly on my old (P166) web server. I'd be very interested in=20 > trying > out the new code, even if it's not finished yet. > > Thanks, > Brian > > > _______________________________________________ > IDS-devel mailing list > IDS...@li... > http://lists.sourceforge.net/lists/listinfo/ids-devel |
|
From: Brian W. <bwe...@xb...> - 2001-07-01 21:26:48
|
Is there any chance of getting a snapshot of the IDS 1.0 rewrite? I just found IDS today, and it looks really cool, but the current release runs very slowly on my old (P166) web server. I'd be very interested in trying out the new code, even if it's not finished yet. Thanks, Brian |
|
From: Anthony A. D. T. <aa...@ve...> - 2001-06-27 19:14:45
|
Augh. I spoke too soon. previewmaker.pl has problems: lovecraftRoot=>./previewmaker.pl Locating image files... Content-type: text/html <H1>Software error:</H1> <CODE>Not a subroutine reference at /usr/local/pkg/perl/lib/5.00502/File/Find.pm line 197. </CODE> <P> For help, please send mail to this site's webmaster, giving this error message and the time and date of the error. ; [Wed Jun 27 12:14:07 2001] previewmaker.pl: Not a subroutine reference at /usr/local/pkg/perl/lib/5.00502/File/Find.pm line 197. |
|
From: Anthony A. D. T. <aa...@ve...> - 2001-06-27 19:08:32
|
Okay, I managed to bludgeon ImageMagick 5.3.6 into compiling and .711 works for me now. The problem was with @#$@# libtool using -shared instead of -G. I had to replace-shared with -G in way too many places in the script, and work around the usual failure of configure to understand how -R has worked for years. Augh. |
|
From: Anthony A. D. T. <aa...@ve...> - 2001-06-27 18:03:39
|
Sigh. Here's what happens when I try to build the latest ImageMagick
SunOS5.7 SPARC, configured with
./configure LDFLAGS='-L/usr/local/lib -R/usr/local/lib' CFLAGS=-O3
--prefix=/usr/local/pkg/imagemagick --enable-shared
gcc -shared -Wl,-h -Wl,libMagick.so.5 -o .libs/libMagick.so.5.0.36
.libs/PreRvIcccm.o .libs/animate.o .libs/annotate.o .libs/attributes.o
.libs/blob.o .libs/cache.o .libs/cache_view.o .libs/colors.o
.libs/compress.o .libs/constitute.o .libs/decorate.o .libs/delegates.o
.libs/display.o .libs/draw.o .libs/effects.o .libs/enhance.o
.libs/error.o .libs/fonts.o .libs/gems.o .libs/image.o .libs/semaphore.o
.libs/magic.o .libs/magick.o .libs/memory.o .libs/modules.o
.libs/monitor.o .libs/montage.o .libs/quantize.o .libs/segment.o
.libs/shear.o .libs/signature.o .libs/stream.o .libs/timer.o
.libs/transform.o .libs/utility.o .libs/widget.o .libs/xwindows.o
.libs/zoom.o -z allextract ../coders/.libs/libCoders.a -z defaultextract
-R/usr/local/pkg/jpeg/lib -R/usr/local/pkg/jpeg/lib -R/usr/local/lib
-R/usr/openwin/lib -L/usr/local/lib -L/usr/local/pkg/imagemagick/lib
-L/usr/openwin/lib ../coders/.libs/libCoders.a -R/usr/local/lib
-R/usr/openwin/lib -ltiff /usr/local/pkg/jpeg/lib/libjpeg.so -lpng
-ldpstk -ldps -lXext -lXt -lSM -lICE -lX11 -lsocket -lnsl -lz -lpthread
-lm -lc
Text relocation remains referenced
against symbol offset in file
<unknown> 0x38
/usr/local/lib/libz.a(compress.o)
<unknown> 0x3c
/usr/local/lib/libz.a(compress.o)
<unknown> 0xe0
/usr/local/lib/libz.a(compress.o)
<unknown> 0xe4
/usr/local/lib/libz.a(compress.o)
<unknown> 0x20 /usr/local/lib/libz.a(crc32.o)
<unknown> 0x24 /usr/local/lib/libz.a(crc32.o)
<unknown> 0x140 /usr/local/lib/libz.a(crc32.o)
<unknown> 0x144 /usr/local/lib/libz.a(crc32.o)
<unknown> 0x17c /usr/local/lib/libz.a(crc32.o)
<unknown> 0x184 /usr/local/lib/libz.a(crc32.o)
<unknown> 0x168 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x16c /usr/local/lib/libz.a(gzio.o)
<unknown> 0x1dc /usr/local/lib/libz.a(gzio.o)
<unknown> 0x1e0 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x288 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x28c /usr/local/lib/libz.a(gzio.o)
<unknown> 0x16cc /usr/local/lib/libz.a(gzio.o)
<unknown> 0x16b8 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x16c0 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x16d8 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x1758 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x1764 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x17b0 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x17b4 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x294 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x29c /usr/local/lib/libz.a(gzio.o)
<unknown> 0x2e4 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x2e8 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x290 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x34
/usr/local/lib/libz.a(uncompr.o)
<unknown> 0x38
/usr/local/lib/libz.a(uncompr.o)
<unknown> 0x4a0
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x430
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x4a4
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x7b8
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x7ec
/usr/local/lib/libz.a(deflate.o)
<unknown> 0xe34
/usr/local/lib/libz.a(deflate.o)
<unknown> 0xe3c
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x440
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x18
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x14
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x19fc /usr/local/lib/libz.a(trees.o)
<unknown> 0x16e0 /usr/local/lib/libz.a(trees.o)
<unknown> 0x16d8 /usr/local/lib/libz.a(trees.o)
<unknown> 0x16d4 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1a00 /usr/local/lib/libz.a(trees.o)
<unknown> 0x14a8 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1a0c /usr/local/lib/libz.a(trees.o)
<unknown> 0x1354 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1350 /usr/local/lib/libz.a(trees.o)
<unknown> 0x11c4 /usr/local/lib/libz.a(trees.o)
<unknown> 0x11c0 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1034 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1030 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1a10 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1b84 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1b88 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1cf8 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1cfc /usr/local/lib/libz.a(trees.o)
<unknown> 0x16d0 /usr/local/lib/libz.a(trees.o)
<unknown> 0x14a4 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1fd0 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1fd4 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1fe4 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1fe8 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1ff8 /usr/local/lib/libz.a(trees.o)
<unknown> 0x1ffc /usr/local/lib/libz.a(trees.o)
<unknown> 0x0 /usr/local/lib/libz.a(zutil.o)
<unknown> 0x8 /usr/local/lib/libz.a(zutil.o)
<unknown> 0x548
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x7d0
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x318
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x320
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x348
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x350
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x3b8
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x3c0
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x544
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x738
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x73c
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x7c0
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x274
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x278
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x120
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x124
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x714
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x710
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x540
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x53c
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x300
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x2f8
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x284
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x280
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x134
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x138
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x590
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x678
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x624
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x668
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x680
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x628
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x5a4
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x62c
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x580
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x630
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x5a8
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x57c
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x664
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x714
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x700
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x710
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x708
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x6ec
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x6e8
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x6b4
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x6a8
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x6a4
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x6a0
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x75c
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x77c
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x750
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x770
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x76c
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x778
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x754
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x760
/usr/local/lib/libz.a(inftrees.o)
<unknown> 0x370
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x21c
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x36c
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x220
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x54
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x50
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x33c
/usr/local/lib/libz.a(inffast.o)
<unknown> 0x2f8
/usr/local/lib/libz.a(inffast.o)
<unknown> 0x58
/usr/local/lib/libz.a(inffast.o)
<unknown> 0x54
/usr/local/lib/libz.a(inffast.o)
_tr_init 0x2440
/usr/local/lib/libz.a(deflate.o)
inflate_trees_bits 0x688
/usr/local/lib/libz.a(infblock.o)
z_errmsg 0x234
/usr/local/lib/libz.a(deflate.o)
z_errmsg 0x16f8 /usr/local/lib/libz.a(gzio.o)
z_errmsg 0x550
/usr/local/lib/libz.a(deflate.o)
z_errmsg 0x79c
/usr/local/lib/libz.a(deflate.o)
z_errmsg 0x230
/usr/local/lib/libz.a(deflate.o)
z_errmsg 0x574
/usr/local/lib/libz.a(deflate.o)
z_errmsg 0x210
/usr/local/lib/libz.a(deflate.o)
z_errmsg 0x58c
/usr/local/lib/libz.a(deflate.o)
z_errmsg 0x77c
/usr/local/lib/libz.a(deflate.o)
z_errmsg 0x16fc /usr/local/lib/libz.a(gzio.o)
z_errmsg 0x16e4 /usr/local/lib/libz.a(gzio.o)
z_errmsg 0x16a8 /usr/local/lib/libz.a(gzio.o)
z_errmsg 0x16a0 /usr/local/lib/libz.a(gzio.o)
z_errmsg 0x798
/usr/local/lib/libz.a(deflate.o)
z_errmsg 0x570
/usr/local/lib/libz.a(deflate.o)
z_errmsg 0x10 /usr/local/lib/libz.a(zutil.o)
z_errmsg 0xc /usr/local/lib/libz.a(zutil.o)
_tr_align 0x868
/usr/local/lib/libz.a(deflate.o)
fseek 0x11d8 /usr/local/lib/libz.a(gzio.o)
fseek 0x1be8 /usr/local/lib/libz.a(gzio.o)
rewind 0x1bf8 /usr/local/lib/libz.a(gzio.o)
fdopen 0x234 /usr/local/lib/libz.a(gzio.o)
_dist_code 0x16e0
/usr/local/lib/libz.a(deflate.o)
_dist_code 0x16dc
/usr/local/lib/libz.a(deflate.o)
_dist_code 0x1c78
/usr/local/lib/libz.a(deflate.o)
_dist_code 0x1c74
/usr/local/lib/libz.a(deflate.o)
_dist_code 0x190c /usr/local/lib/libz.a(trees.o)
_dist_code 0x1940 /usr/local/lib/libz.a(trees.o)
_dist_code 0x1910 /usr/local/lib/libz.a(trees.o)
_dist_code 0x1a08 /usr/local/lib/libz.a(trees.o)
_dist_code 0x1944 /usr/local/lib/libz.a(trees.o)
_dist_code 0x1950 /usr/local/lib/libz.a(trees.o)
_dist_code 0x1920 /usr/local/lib/libz.a(trees.o)
_dist_code 0x1954 /usr/local/lib/libz.a(trees.o)
_dist_code 0x191c /usr/local/lib/libz.a(trees.o)
_dist_code 0x1a04 /usr/local/lib/libz.a(trees.o)
inflate_blocks_reset 0x5b8
/usr/local/lib/libz.a(inflate.o)
inflate_blocks_reset 0xa30
/usr/local/lib/libz.a(inflate.o)
inflate_blocks_reset 0x8a0
/usr/local/lib/libz.a(inflate.o)
inflate_blocks_reset 0x210
/usr/local/lib/libz.a(inflate.o)
inflateEnd 0x88
/usr/local/lib/libz.a(uncompr.o)
inflateEnd 0xa94 /usr/local/lib/libz.a(gzio.o)
inflateEnd 0x68
/usr/local/lib/libz.a(uncompr.o)
crc32 0x1168 /usr/local/lib/libz.a(gzio.o)
crc32 0xdbc /usr/local/lib/libz.a(gzio.o)
crc32 0xd74 /usr/local/lib/libz.a(gzio.o)
crc32 0xd04 /usr/local/lib/libz.a(gzio.o)
crc32 0x1910 /usr/local/lib/libz.a(gzio.o)
crc32 0x19e0 /usr/local/lib/libz.a(gzio.o)
crc32 0xecc /usr/local/lib/libz.a(gzio.o)
crc32 0x78 /usr/local/lib/libz.a(gzio.o)
crc32 0x1b28 /usr/local/lib/libz.a(gzio.o)
crc32 0x1bc0 /usr/local/lib/libz.a(gzio.o)
inflateReset 0xd5c /usr/local/lib/libz.a(gzio.o)
inflateReset 0x1bd8 /usr/local/lib/libz.a(gzio.o)
vsprintf 0xe04 /usr/local/lib/libz.a(gzio.o)
zcalloc 0x60
/usr/local/lib/libz.a(deflate.o)
zcalloc 0x64
/usr/local/lib/libz.a(deflate.o)
zcalloc 0x50
/usr/local/lib/libz.a(inflate.o)
zcalloc 0x54
/usr/local/lib/libz.a(inflate.o)
inflate_blocks 0x568
/usr/local/lib/libz.a(inflate.o)
inflate_codes 0xa00
/usr/local/lib/libz.a(infblock.o)
deflateInit2_ 0x190 /usr/local/lib/libz.a(gzio.o)
deflateInit2_ 0x247c
/usr/local/lib/libz.a(deflate.o)
deflateReset 0x28c
/usr/local/lib/libz.a(deflate.o)
fprintf 0x2a4 /usr/local/lib/libz.a(gzio.o)
_tr_stored_block 0x880
/usr/local/lib/libz.a(deflate.o)
strlen 0x172c /usr/local/lib/libz.a(gzio.o)
strlen 0x1738 /usr/local/lib/libz.a(gzio.o)
strlen 0x1930 /usr/local/lib/libz.a(gzio.o)
strlen 0xe0c /usr/local/lib/libz.a(gzio.o)
strlen 0x8c /usr/local/lib/libz.a(gzio.o)
gzrewind 0x1208 /usr/local/lib/libz.a(gzio.o)
adler32 0x1270
/usr/local/lib/libz.a(deflate.o)
adler32 0x140
/usr/local/lib/libz.a(inflate.o)
adler32 0x144
/usr/local/lib/libz.a(inflate.o)
adler32 0x970
/usr/local/lib/libz.a(inflate.o)
adler32 0x2ec
/usr/local/lib/libz.a(deflate.o)
memcpy 0x8ec
/usr/local/lib/libz.a(deflate.o)
memcpy 0x6dc
/usr/local/lib/libz.a(deflate.o)
memcpy 0x128
/usr/local/lib/libz.a(infutil.o)
memcpy 0x88
/usr/local/lib/libz.a(infutil.o)
memcpy 0x328
/usr/local/lib/libz.a(deflate.o)
memcpy 0xbf0 /usr/local/lib/libz.a(gzio.o)
memcpy 0xa1c
/usr/local/lib/libz.a(deflate.o)
memcpy 0xc60
/usr/local/lib/libz.a(deflate.o)
memcpy 0xd7c
/usr/local/lib/libz.a(infblock.o)
memcpy 0xd24
/usr/local/lib/libz.a(deflate.o)
memcpy 0xd38
/usr/local/lib/libz.a(deflate.o)
memcpy 0xd4c
/usr/local/lib/libz.a(deflate.o)
memcpy 0x1428
/usr/local/lib/libz.a(deflate.o)
memcpy 0x498
/usr/local/lib/libz.a(infblock.o)
memcpy 0xd5c
/usr/local/lib/libz.a(deflate.o)
memcpy 0x1160
/usr/local/lib/libz.a(deflate.o)
memcpy 0x1284
/usr/local/lib/libz.a(deflate.o)
memcpy 0x1528
/usr/local/lib/libz.a(deflate.o)
memcpy 0x1618
/usr/local/lib/libz.a(deflate.o)
memcpy 0x1ab8
/usr/local/lib/libz.a(deflate.o)
memcpy 0x1ba8
/usr/local/lib/libz.a(deflate.o)
memcpy 0x201c
/usr/local/lib/libz.a(deflate.o)
memcpy 0x2164
/usr/local/lib/libz.a(deflate.o)
memcpy 0x2300
/usr/local/lib/libz.a(deflate.o)
inflate_codes_new 0x220
/usr/local/lib/libz.a(infblock.o)
inflate_codes_new 0x998
/usr/local/lib/libz.a(infblock.o)
strcat 0x1760 /usr/local/lib/libz.a(gzio.o)
strcat 0x176c /usr/local/lib/libz.a(gzio.o)
fread 0xcac /usr/local/lib/libz.a(gzio.o)
fread 0x584 /usr/local/lib/libz.a(gzio.o)
fread 0x14a8 /usr/local/lib/libz.a(gzio.o)
fread 0x62c /usr/local/lib/libz.a(gzio.o)
fread 0x6c4 /usr/local/lib/libz.a(gzio.o)
fread 0x778 /usr/local/lib/libz.a(gzio.o)
fread 0x1408 /usr/local/lib/libz.a(gzio.o)
fread 0x1370 /usr/local/lib/libz.a(gzio.o)
fread 0x430 /usr/local/lib/libz.a(gzio.o)
fread 0x838 /usr/local/lib/libz.a(gzio.o)
fread 0x8f4 /usr/local/lib/libz.a(gzio.o)
fread 0x12dc /usr/local/lib/libz.a(gzio.o)
fread 0x4c8 /usr/local/lib/libz.a(gzio.o)
fread 0x324 /usr/local/lib/libz.a(gzio.o)
fread 0x9ac /usr/local/lib/libz.a(gzio.o)
fread 0xc34 /usr/local/lib/libz.a(gzio.o)
zcfree 0x70
/usr/local/lib/libz.a(inflate.o)
zcfree 0x74
/usr/local/lib/libz.a(inflate.o)
zcfree 0x80
/usr/local/lib/libz.a(deflate.o)
zcfree 0x84
/usr/local/lib/libz.a(deflate.o)
strcpy 0x1750 /usr/local/lib/libz.a(gzio.o)
strcpy 0xa8 /usr/local/lib/libz.a(gzio.o)
deflateParams 0x1854 /usr/local/lib/libz.a(gzio.o)
deflateInit_ 0xe8
/usr/local/lib/libz.a(compress.o)
deflateInit_ 0x40
/usr/local/lib/libz.a(compress.o)
sprintf 0x17b8 /usr/local/lib/libz.a(gzio.o)
fflush 0xfe4 /usr/local/lib/libz.a(gzio.o)
.umul 0x364 /usr/local/lib/libz.a(trees.o)
.umul 0x25c /usr/local/lib/libz.a(trees.o)
.umul 0x234 /usr/local/lib/libz.a(trees.o)
inflateInit_ 0x3c
/usr/local/lib/libz.a(uncompr.o)
memset 0xe0c
/usr/local/lib/libz.a(deflate.o)
memset 0x8b8
/usr/local/lib/libz.a(deflate.o)
memset 0x1090 /usr/local/lib/libz.a(gzio.o)
.udiv 0x168
/usr/local/lib/libz.a(deflate.o)
fclose 0xab0 /usr/local/lib/libz.a(gzio.o)
inflate 0xce4 /usr/local/lib/libz.a(gzio.o)
inflate 0x50
/usr/local/lib/libz.a(uncompr.o)
gzseek 0x1c18 /usr/local/lib/libz.a(gzio.o)
fwrite 0x1120 /usr/local/lib/libz.a(gzio.o)
fwrite 0x182c /usr/local/lib/libz.a(gzio.o)
fwrite 0x18c8 /usr/local/lib/libz.a(gzio.o)
fwrite 0x157c /usr/local/lib/libz.a(gzio.o)
fwrite 0xf40 /usr/local/lib/libz.a(gzio.o)
fwrite 0x1998 /usr/local/lib/libz.a(gzio.o)
fwrite 0xe7c /usr/local/lib/libz.a(gzio.o)
fwrite 0x1ae0 /usr/local/lib/libz.a(gzio.o)
inflate_blocks_sync_point 0xa94
/usr/local/lib/libz.a(inflate.o)
.urem 0x16c
/usr/local/lib/libz.a(adler32.o)
.urem 0x3a0
/usr/local/lib/libz.a(inflate.o)
.urem 0x5f0
/usr/local/lib/libz.a(deflate.o)
.urem 0x15c
/usr/local/lib/libz.a(adler32.o)
gzread 0x1270 /usr/local/lib/libz.a(gzio.o)
gzread 0x1a24 /usr/local/lib/libz.a(gzio.o)
gzread 0x1b60 /usr/local/lib/libz.a(gzio.o)
fputc 0x1634 /usr/local/lib/libz.a(gzio.o)
fputc 0x165c /usr/local/lib/libz.a(gzio.o)
inflate_flush 0x494
/usr/local/lib/libz.a(infcodes.o)
inflate_flush 0x5b0
/usr/local/lib/libz.a(infcodes.o)
inflate_flush 0xc0c
/usr/local/lib/libz.a(infblock.o)
inflate_flush 0xa90
/usr/local/lib/libz.a(infblock.o)
inflate_flush 0x680
/usr/local/lib/libz.a(infcodes.o)
inflate_flush 0x7d4
/usr/local/lib/libz.a(infcodes.o)
inflate_flush 0x3dc
/usr/local/lib/libz.a(infblock.o)
errno 0x1360 /usr/local/lib/libz.a(gzio.o)
errno 0x828 /usr/local/lib/libz.a(gzio.o)
errno 0x7f8 /usr/local/lib/libz.a(gzio.o)
errno 0x13f4 /usr/local/lib/libz.a(gzio.o)
errno 0x768 /usr/local/lib/libz.a(gzio.o)
errno 0x73c /usr/local/lib/libz.a(gzio.o)
errno 0x135c /usr/local/lib/libz.a(gzio.o)
errno 0x6b4 /usr/local/lib/libz.a(gzio.o)
errno 0x1498 /usr/local/lib/libz.a(gzio.o)
errno 0x61c /usr/local/lib/libz.a(gzio.o)
errno 0x618 /usr/local/lib/libz.a(gzio.o)
errno 0x6b0 /usr/local/lib/libz.a(gzio.o)
errno 0x574 /usr/local/lib/libz.a(gzio.o)
errno 0x548 /usr/local/lib/libz.a(gzio.o)
errno 0x8b4 /usr/local/lib/libz.a(gzio.o)
errno 0x4b8 /usr/local/lib/libz.a(gzio.o)
errno 0x4b4 /usr/local/lib/libz.a(gzio.o)
errno 0x8e4 /usr/local/lib/libz.a(gzio.o)
errno 0x12cc /usr/local/lib/libz.a(gzio.o)
errno 0x12c8 /usr/local/lib/libz.a(gzio.o)
errno 0x420 /usr/local/lib/libz.a(gzio.o)
errno 0x974 /usr/local/lib/libz.a(gzio.o)
errno 0x41c /usr/local/lib/libz.a(gzio.o)
errno 0x99c /usr/local/lib/libz.a(gzio.o)
errno 0xc9c /usr/local/lib/libz.a(gzio.o)
errno 0x314 /usr/local/lib/libz.a(gzio.o)
errno 0x310 /usr/local/lib/libz.a(gzio.o)
errno 0xac0 /usr/local/lib/libz.a(gzio.o)
errno 0xc98 /usr/local/lib/libz.a(gzio.o)
errno 0x218 /usr/local/lib/libz.a(gzio.o)
errno 0x20c /usr/local/lib/libz.a(gzio.o)
errno 0xac4 /usr/local/lib/libz.a(gzio.o)
errno 0x1494 /usr/local/lib/libz.a(gzio.o)
errno 0x13f8 /usr/local/lib/libz.a(gzio.o)
inflateInit2_ 0xa54
/usr/local/lib/libz.a(inflate.o)
inflateInit2_ 0x1e4 /usr/local/lib/libz.a(gzio.o)
inflate_set_dictionary 0x9c0
/usr/local/lib/libz.a(inflate.o)
ftell 0x2bc /usr/local/lib/libz.a(gzio.o)
deflateEnd 0xd0c
/usr/local/lib/libz.a(deflate.o)
deflateEnd 0x134
/usr/local/lib/libz.a(compress.o)
deflateEnd 0x114
/usr/local/lib/libz.a(compress.o)
deflateEnd 0x90
/usr/local/lib/libz.a(compress.o)
deflateEnd 0x70
/usr/local/lib/libz.a(compress.o)
deflateEnd 0x23c
/usr/local/lib/libz.a(deflate.o)
deflateEnd 0xa7c /usr/local/lib/libz.a(gzio.o)
deflate 0x1afc /usr/local/lib/libz.a(gzio.o)
deflate 0x19b4 /usr/local/lib/libz.a(gzio.o)
deflate 0x58
/usr/local/lib/libz.a(compress.o)
deflate 0x15a8 /usr/local/lib/libz.a(gzio.o)
deflate 0x488
/usr/local/lib/libz.a(deflate.o)
deflate 0x113c /usr/local/lib/libz.a(gzio.o)
deflate 0xf6c /usr/local/lib/libz.a(gzio.o)
deflate 0xe98 /usr/local/lib/libz.a(gzio.o)
deflate 0xfc
/usr/local/lib/libz.a(compress.o)
deflate 0x18e4 /usr/local/lib/libz.a(gzio.o)
fopen 0x220 /usr/local/lib/libz.a(gzio.o)
_length_code 0x19f8 /usr/local/lib/libz.a(trees.o)
_length_code 0x18dc /usr/local/lib/libz.a(trees.o)
_length_code 0x18d4 /usr/local/lib/libz.a(trees.o)
_length_code 0x1e54
/usr/local/lib/libz.a(deflate.o)
_length_code 0x1e50
/usr/local/lib/libz.a(deflate.o)
_length_code 0x1830
/usr/local/lib/libz.a(deflate.o)
_length_code 0x19f4 /usr/local/lib/libz.a(trees.o)
_length_code 0x182c
/usr/local/lib/libz.a(deflate.o)
inflate_mask 0x48
/usr/local/lib/libz.a(inffast.o)
inflate_mask 0x40
/usr/local/lib/libz.a(infcodes.o)
inflate_mask 0x4c
/usr/local/lib/libz.a(inffast.o)
inflate_mask 0x708
/usr/local/lib/libz.a(infblock.o)
inflate_mask 0x70c
/usr/local/lib/libz.a(infblock.o)
inflate_mask 0x3c
/usr/local/lib/libz.a(infcodes.o)
inflate_codes_free 0xa2c
/usr/local/lib/libz.a(infblock.o)
inflate_codes_free 0xc6c
/usr/local/lib/libz.a(infblock.o)
inflate_codes_free 0xcf4
/usr/local/lib/libz.a(infblock.o)
inflate_blocks_new 0x150
/usr/local/lib/libz.a(inflate.o)
inflate_trees_fixed 0x208
/usr/local/lib/libz.a(infblock.o)
_tr_flush_block 0x13e8
/usr/local/lib/libz.a(deflate.o)
_tr_flush_block 0x14e8
/usr/local/lib/libz.a(deflate.o)
_tr_flush_block 0x15d8
/usr/local/lib/libz.a(deflate.o)
_tr_flush_block 0x1a78
/usr/local/lib/libz.a(deflate.o)
_tr_flush_block 0x1b68
/usr/local/lib/libz.a(deflate.o)
_tr_flush_block 0x2124
/usr/local/lib/libz.a(deflate.o)
_tr_flush_block 0x1fdc
/usr/local/lib/libz.a(deflate.o)
_tr_flush_block 0x22c0
/usr/local/lib/libz.a(deflate.o)
free 0xa54 /usr/local/lib/libz.a(gzio.o)
free 0x44 /usr/local/lib/libz.a(zutil.o)
free 0xaf4 /usr/local/lib/libz.a(gzio.o)
free 0xb0c /usr/local/lib/libz.a(gzio.o)
free 0x1724 /usr/local/lib/libz.a(gzio.o)
free 0xb38 /usr/local/lib/libz.a(gzio.o)
free 0xb24 /usr/local/lib/libz.a(gzio.o)
inflate_trees_dynamic 0x938
/usr/local/lib/libz.a(infblock.o)
inflate_blocks_free 0x108
/usr/local/lib/libz.a(inflate.o)
inflate_blocks_free 0x1a4
/usr/local/lib/libz.a(inflate.o)
inflate_blocks_free 0x90c
/usr/local/lib/libz.a(inflate.o)
inflate_fast 0xe0
/usr/local/lib/libz.a(infcodes.o)
calloc 0x30 /usr/local/lib/libz.a(zutil.o)
malloc 0x19c /usr/local/lib/libz.a(gzio.o)
malloc 0x94 /usr/local/lib/libz.a(gzio.o)
malloc 0x1c4 /usr/local/lib/libz.a(gzio.o)
malloc 0x1744 /usr/local/lib/libz.a(gzio.o)
malloc 0x28 /usr/local/lib/libz.a(gzio.o)
malloc 0x1080 /usr/local/lib/libz.a(gzio.o)
malloc 0x1240 /usr/local/lib/libz.a(gzio.o)
<unknown> 0x8c
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x88
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x84
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x78
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x74
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x68
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x80
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x170
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x16c
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x70
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x164
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x160
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x15c
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x158
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x154
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x150
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x14c
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x2c0
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x2bc
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x2b8
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x2b4
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x2b0
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x2ac
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x2a8
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x2a4
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x2a0
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x29c
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x298
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x294
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x290
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x28c
/usr/local/lib/libz.a(inflate.o)
<unknown> 0x7c
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x6c
/usr/local/lib/libz.a(infcodes.o)
<unknown> 0x168
/usr/local/lib/libz.a(infblock.o)
<unknown> 0x40
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x4c
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x58
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x64
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x70
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x7c
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x88
/usr/local/lib/libz.a(deflate.o)
<unknown> 0x94
/usr/local/lib/libz.a(deflate.o)
<unknown> 0xa0
/usr/local/lib/libz.a(deflate.o)
<unknown> 0xac
/usr/local/lib/libz.a(deflate.o)
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `libMagick.la'
Current working directory /tmp/ImageMagick-5.3.6/magick
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
|
|
From: John M. <mo...@mu...> - 2001-06-27 17:35:46
|
Usually that error message means that you need to upgrade ImageMagick and PerlMagick to version 5.3.1 or later. I don't understand why you didn't receive that error under 0.7 as well, because that was when the change went into effect. (That ImageMagick call is made when album icons are generated.) John On Wednesday, June 27, 2001, at 12:10 PM, Anthony A. D. Talltree wrote: > I'd been running the 0.7 with the site header <h2>IDS 0.7 Test Site</h2> > just fine. I stuffed in 0.711 just now, and when I try to browse the > gallery, I get: > > Software error: > > ./Barnyard: Warning 310: invalid compos value (compose) [No such file or > directory] at /idsShared.pm line 740. > > Barnyard is the name of the first directory under ids/albums. What's > going on here? > > SunOS 5.7 on SPARC hardware, perl .005_02 > > _______________________________________________ > IDS-devel mailing list > IDS...@li... > http://lists.sourceforge.net/lists/listinfo/ids-devel |
|
From: Anthony A. D. T. <aa...@ve...> - 2001-06-27 16:10:32
|
I'd been running the 0.7 with the site header <h2>IDS 0.7 Test Site</h2> just fine. I stuffed in 0.711 just now, and when I try to browse the gallery, I get: Software error: ./Barnyard: Warning 310: invalid compos value (compose) [No such file or directory] at /idsShared.pm line 740. Barnyard is the name of the first directory under ids/albums. What's going on here? SunOS 5.7 on SPARC hardware, perl .005_02 |
|
From: Paul H. <pa...@mj...> - 2001-06-25 10:41:05
|
On Fri, Jun 22, 2001 at 04:56:03PM -0400, John Moose wrote: > While on "vacation" this week, I've gotten quite a bit done on the IDS > rewrite : > This is all sounding great! > - new name? "_Image_ Display System" just doesn't seem to fit anymore > and there is the whole "Intruder Detection System" confusion. Howabout: Media Archive Retrieval System -- Regards, Paul |
|
From: John M. <mo...@mu...> - 2001-06-22 20:56:05
|
While on "vacation" this week, I've gotten quite a bit done on the IDS rewrite : http://arwen.hn.org:8080/ids/ (Under mod_perl and everything!) Updates: - home, album, and item views are fully implemented, including full support for themes and i18n - i18n support has been improved with support for formatting of dates and times - Chinese (HK ) localization file added - new navigation widget at the top and bottom of every album and item page allows users to quickly navigate to any of the preceding albums - item count, page links on album pages moved to the top of the page for increased visibility - non-image files now appear in the previous/next links and on item pages and can be commented upon Still to come: - support for comments - all-new administrative interface - previewmaker and updater tools - new name? "_Image_ Display System" just doesn't seem to fit anymore and there is the whole "Intruder Detection System" confusion. John |
|
From: John M. <mo...@mu...> - 2001-06-22 20:20:22
|
I released IDS 0.711 today. http://ids.sourceforge.net/ Changes: - Album icons are now correctly preserved across themes - Corrected a minor bug with the cookie's "path" variable - Corrected a bug with the sort by date function and images with embedded dates John |
|
From: Ashley M. K. <as...@pc...> - 2001-06-19 03:47:21
|
These are short excerpts from a conversation I had with another IDS
user, things he's wishing for:
---------------
WizJS says, "Oh: one thing I'd really like -- the ability to go back
to the main page from a picture's page."
WizJS says, "Having to go through the album is ... irritating.
Maybe put a little "Home > Album > Subalbum > Image" type thing on
there...."
-----
WizJS asks, "What about having non-directory albums?"
WizJS says, "(e.g. I've got a lot of pics of cute girls; I'd like to
have an album of them, but I also want them to show up in their original
places)."
-----
WizJS says, "Mmm. For user auth, it'd be nice if you could get the
visibility granularity to per-picture (rather than per-album). But
that's not a biggie."
-----
WizJS says to you, "Mmm. Only other thing that'd be really cool
would be having a Mason component to show images"
---------------
There ya go. One thing I'd like to see is the ability to delete
albums (with, or without content). And from the above mentioned list,
#1 seems like a good idea.
Comments anyone?
--
H | Hi, I'm currently out of my mind. Please leave a message. BEEEEP!
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130
Director of Internet Operations / SysAdmin . 800.441.3873 x130
Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave, #6
http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
|
|
From: Ashley M. K. <as...@pc...> - 2001-06-18 20:08:15
|
John Moose wrote:
> Is 300DPI a common service bureau print resolution? I imagine that it
> would vary a lot.
No it doesn't. 300 DPI is standard for photo graphic material (regular
minilab prints, dye sublimation prints, and most even light jet prints.) As
far as we know, we're the only lab (as of last month's convention in Miami)
that does Lightjet Prints at 400DPI. Everyone else does both minilab, and
lightjets at 300DPI. Inkjets, now those are a different breed all together,
however, again, our large format (52" wide) printers all do either 300, 360 or
720 DPI. Our old Xerox did 72 DPI. All of those car/bus wraps that you see,
those are done at 72 or 96 DPI.
> Are there other service bureau concerns that we should be considering?
Now you're going into custom setups, and I'd stay away from that. I'd do
the most common, general stuff, and leave the rest to which ever lab wishes to
use IDS. Considering there is no standard 'input' program to accept stuff
from the web (for example from IDS), we (as a company) have considered
creating something that we can then standardize by means of distribution to
other labs. This will help IDS in supporting more and more labs. But, that's
a long shot. And my boss is hot on it, unfortunately.
AMK4
--
W | I haven't lost my mind; it's backed up on tape somewhere.
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130
IT Director / Websmith . 800.441.3873 x130
Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave #6
http://www.pcraft.com ...... . . . Boulder, CO 80303, USA
|
|
From: John M. <mo...@mu...> - 2001-06-18 18:20:55
|
I do like the idea of making it clear what size prints people can expect from a certain image file. (Shutterfly does this when you order a print from them. Users are warned if an image is too small for a certain print size.) Its good to know about the extra cost associated with sending large images. I was unaware. IDS until now has been aimed at pro-consumer digital cameras whose max resolution topped out at around 1600x1200 (This is probably a mistake considering all of the relatively inexpensive 4 megapixel cameras that have been appearing lately). In fact, when a user clicks the "Order Print" button, IDS sends a link to the original image file to Shutterfly without even checking the size of the file. I know of several people who are using IDS to display 50MB+ scans. I'm thinking of three alternatives (in order of ease to implement): - list appropriate print sizes in the current IDS image resize menu. For example, "X-Large (1600) 8x10 print". - list the maximum recommended print size in the image info box under every image. - make the current "Order Print" button into a pop-up menu: "Order 4x6 print, Order 8x10 print, etc..." Print sizes that are too large would not be displayed. Is 300DPI a common service bureau print resolution? I imagine that it would vary a lot. Are there other service bureau concerns that we should be considering? Shutterfly is so prominent in IDS because they are the only ones I could find who accept URL's to images instead of uploading the actual image files. I would love to give people more choices. John On Monday, June 18, 2001, at 01:45 PM, Ashley M. Kirchner wrote: > "Anthony A. D. Talltree" wrote: > >> Well, numbers of pixels are absolute, while inches are relative to an >> assumed dot density, which varies widely for display devices, at least. >> Do all of the online photoprinting houses use equipment with the same >> densities and imageable regions? > > Not the same equipment, however the imageable region is pretty much > set, by the consumer market. Back in the 1980, our lab, Photo Craft, > introduced two sized to the consumer market, the 4x6 and 8x12. The 4x6 > caught on and you can now buy a 4x6 frame. Why did we introduce a 4x6? > Because a 35mm piece of film is exactly proportionate to a 4x6. At the > time, there was no size available that would print a full frame without > cropping. The 8x12 never caught on, and while it is a standard at our > lab, > and many other professional labs, you still can't (easily) buy an 8x12 > frame. > > Imageable regions are set by what people want, and the labs try to > offer those. This year we're introducing two new sizes again - we'll > see > how that goes. > > And yes, I do agree, pixel values are absolute, but ask any consumer > that gets prints made if they know their pixel values for the prints > they > just got. They'll look at you as if you're speaking Mandarin. Pixels? > What's that? I'm not proposing a rewrite to IDS to go to a different > unit > base, no. I like the fact that it IS pixel based. I'm thinking for the > average Joe getting prints made. That's our goal here. We ask what > people > want, and everyone is used to inches, not pixels. > > >> Overkill, perhaps, but wouldn't it work just fine? More information is >> better, right? > > Not necessarily. Service bureau's will charge extra if your file is > too large for what you're doing (at least, we do, and several other > professional labs will). Why? Simple, we (or our equipment) has to > downsize your file first. > > For example, a 4K 35mm film output camera has 4096 lines across: > > A 35mm's ratio is 1.5: > 4096 * (4096/1.5) * 3 (channels) => 33.5Mb > > (on an 8K film output camera, double the sizes) > > The Fuji Frontier Digital minilab does everything at 300DPI: > > A 10x15" (print's ratio is 1.5): > (10" * 300 DPI) * (15" * 300 DPI) * 3 (channels) => 40.5Mb > A 3.5x5" (print's ratio is 1.42): > (3.5 * 300) * (5 * 300) * 3 (channels) => 4.7Mb > > On any of these devices, if I feed it a 50Mb file, guess what? On > the > 10x15" print, it'll chug and chug on it because it has to read in all > the > information, and then pitch 10Mb of it because it's not being used > anyways. On the 35mm film output, it chugs even longer, and on the > 3.5x5, > it just quits. It won't do it. > > Now, while you won't see many of these (large) sizes coming from a > digital camera (unless you buy a high end professional one like I did), > anyone getting PhotoCD's will have larger files - upwards of 72Mb > (6-pac) > or 18Mb (5-pac). The same applies for folks getting CD's made from > their > 35mm or 120 film formats from labs that offer that service (like we > do) - > you're dealing with files that are upwards of 5 to 20Mb in size. It > helps > in making the pixels versus inches distinctions for people that don't > understand what they need to get. And there are many of those. > > I see IDS being used by folks downloading images from their digital > cameras into it, and then expecting to be able to get a nice looking > print, > with no pixelation from that small file. What they don't realize is, > that > image they just took with their camera, is too small for the print size > they want. This is something we as a lab deal with almost every single > day. People cram as much as they can on one memory stick, and to do so, > they set the camera to the lowest setting. Then they want 5x7, 8x10 > prints > from those files. Well, it's not going to work. > > Personally, I think if IDS can lend a helping hand, and calculate, > based on the pixel dimensions of the image uploaded, what possible size > print someone can get, that would be a great plus. Afterall, it's > already > doing something very similar with the resizing. If the image is too > small, > it just won't display the larger options. > > -- > W | I haven't lost my mind; it's backed up on tape somewhere. > +-------------------------------------------------------------------- > Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130 > SysAdmin / Websmith . 800.441.3873 x130 > Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave #6 > http://www.pcraft.com ...... . . . Boulder, CO 80303, USA > > > > _______________________________________________ > IDS-devel mailing list > IDS...@li... > http://lists.sourceforge.net/lists/listinfo/ids-devel |
|
From: Ashley M. K. <as...@pc...> - 2001-06-18 17:45:22
|
"Anthony A. D. Talltree" wrote:
> Well, numbers of pixels are absolute, while inches are relative to an
> assumed dot density, which varies widely for display devices, at least.
> Do all of the online photoprinting houses use equipment with the same
> densities and imageable regions?
Not the same equipment, however the imageable region is pretty much
set, by the consumer market. Back in the 1980, our lab, Photo Craft,
introduced two sized to the consumer market, the 4x6 and 8x12. The 4x6
caught on and you can now buy a 4x6 frame. Why did we introduce a 4x6?
Because a 35mm piece of film is exactly proportionate to a 4x6. At the
time, there was no size available that would print a full frame without
cropping. The 8x12 never caught on, and while it is a standard at our lab,
and many other professional labs, you still can't (easily) buy an 8x12
frame.
Imageable regions are set by what people want, and the labs try to
offer those. This year we're introducing two new sizes again - we'll see
how that goes.
And yes, I do agree, pixel values are absolute, but ask any consumer
that gets prints made if they know their pixel values for the prints they
just got. They'll look at you as if you're speaking Mandarin. Pixels?
What's that? I'm not proposing a rewrite to IDS to go to a different unit
base, no. I like the fact that it IS pixel based. I'm thinking for the
average Joe getting prints made. That's our goal here. We ask what people
want, and everyone is used to inches, not pixels.
> Overkill, perhaps, but wouldn't it work just fine? More information is
> better, right?
Not necessarily. Service bureau's will charge extra if your file is
too large for what you're doing (at least, we do, and several other
professional labs will). Why? Simple, we (or our equipment) has to
downsize your file first.
For example, a 4K 35mm film output camera has 4096 lines across:
A 35mm's ratio is 1.5:
4096 * (4096/1.5) * 3 (channels) => 33.5Mb
(on an 8K film output camera, double the sizes)
The Fuji Frontier Digital minilab does everything at 300DPI:
A 10x15" (print's ratio is 1.5):
(10" * 300 DPI) * (15" * 300 DPI) * 3 (channels) => 40.5Mb
A 3.5x5" (print's ratio is 1.42):
(3.5 * 300) * (5 * 300) * 3 (channels) => 4.7Mb
On any of these devices, if I feed it a 50Mb file, guess what? On the
10x15" print, it'll chug and chug on it because it has to read in all the
information, and then pitch 10Mb of it because it's not being used
anyways. On the 35mm film output, it chugs even longer, and on the 3.5x5,
it just quits. It won't do it.
Now, while you won't see many of these (large) sizes coming from a
digital camera (unless you buy a high end professional one like I did),
anyone getting PhotoCD's will have larger files - upwards of 72Mb (6-pac)
or 18Mb (5-pac). The same applies for folks getting CD's made from their
35mm or 120 film formats from labs that offer that service (like we do) -
you're dealing with files that are upwards of 5 to 20Mb in size. It helps
in making the pixels versus inches distinctions for people that don't
understand what they need to get. And there are many of those.
I see IDS being used by folks downloading images from their digital
cameras into it, and then expecting to be able to get a nice looking print,
with no pixelation from that small file. What they don't realize is, that
image they just took with their camera, is too small for the print size
they want. This is something we as a lab deal with almost every single
day. People cram as much as they can on one memory stick, and to do so,
they set the camera to the lowest setting. Then they want 5x7, 8x10 prints
from those files. Well, it's not going to work.
Personally, I think if IDS can lend a helping hand, and calculate,
based on the pixel dimensions of the image uploaded, what possible size
print someone can get, that would be a great plus. Afterall, it's already
doing something very similar with the resizing. If the image is too small,
it just won't display the larger options.
--
W | I haven't lost my mind; it's backed up on tape somewhere.
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130
SysAdmin / Websmith . 800.441.3873 x130
Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave #6
http://www.pcraft.com ...... . . . Boulder, CO 80303, USA
|
|
From: Anthony A. D. T. <aa...@ve...> - 2001-06-18 16:57:44
|
> IDS is currently based on pixel sizes. [...] Well, numbers of pixels are absolute, while inches are relative to an assumed dot density, which varies widely for display devices, at least. Do all of the online photoprinting houses use equipment with the same densities and imageable regions? >Or, someone downloading the x-large file format, when it's >overkill for a simple 3.5x5 print. Overkill, perhaps, but wouldn't it work just fine? More information is better, right? Unless the printing houses and/or their equipment use really bad sampling algorithms. |
7 messages has been excluded from this view by a project administrator.
