Re: The Agony of GMP

[Dan Kogai]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dennis & those who suffer the same prob,

If you are on Intel Macs, try recompiling & reinstalling GMP as follows:

tar jxvf gmp-4.2.1.tar.bz2
cd gmp-4.2.1/mpn/x86
rm *dive_1* */*dive_1* */*/*dive_1* */*mode1o* */*/*mode1o*
cd ../..
sh configure --build=i686-apple-darwin --enable-cxx
make
make check
sudo make install

I also blogged this issue as follows (it's in Japanese, though)

http://blog.livedoor.jp/dankogai/archives/50712932.html

Hope it helps.

Dan the Frequent User of BigNum

On Dec 19, 2007, at 23:32 , Dennis Putnam wrote:

I am trying to install Net::SFTP and it has been a major trial of  
patience. I finally get it working on one of my servers and now am  
trying to get it on another. Unfortunately I have run into a brick  
wall on the 2nd server (both are running 10.4.10) with no clue why  
they are different. The crux of the problem is that I cannot  
install Math::BigInt::GMP on this server. It appears there is a  
problem with the installer but yet this did not happen on the other  
server.


They key on the other server was to install GMP using macports  
'port' command. I did the same on this server and all seemed to go  
well until I tried to install BigInt. I am getting the following:


Running make for C/CH/CHIPT/Math-GMP-2.04.tar.gz
  Has already been unwrapped into directory /Users/admin/.cpan/ 
build/Math-GMP-2.04-nSlAjY

  Has already been made
Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"  
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/gmppm..Can't load '/Users/admin/.cpan/build/Math-GMP-2.04- 
nSlAjY/blib/arch/auto/Math/GMP/GMP.bundle' for module Math::GMP:  
dlopen(/Users/admin/.cpan/build/Math-GMP-2.04-nSlAjY/blib/arch/auto/ 
Math/GMP/GMP.bundle, 2): Symbol not found: ___gmpz_mul_2exp
  Referenced from: /Users/admin/.cpan/build/Math-GMP-2.04-nSlAjY/ 
blib/arch/auto/Math/GMP/GMP.bundle

  Expected in: dynamic lookup
at t/gmppm.t line 7
Compilation failed in require at t/gmppm.t line 7.
BEGIN failed--compilation aborted at t/gmppm.t line 7.
t/gmppm.. Dubious, test returned 255 (wstat 65280, 0xff00)
No subtests run

Can someone help me out with this? TIA.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHaS1eErJia/WXtBsRAnDCAJ9YBwhGxvfWewPEJIeC6DXouJOoxACfeDdo
okzCKgH5aVbdmBxlDnVG69g=
=yDP5
-END PGP SIGNATURE-

MacOSX::File 0.71 released!

[Dan Kogai]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Iyanaga-san,

On Aug 19, 2005, at 14:54 , Iyanaga Nobumi wrote:

Hello,

I downloaded and installed MacOS::File 0.70, but was unable to run  
psync.


[snip]

I could run psync which came with the version 0.69.  The first  
lines are different:


0.69:
#!/usr/bin/perl

eval 'exec /usr/bin/perl  -S $0 ${1+"$@"}'
if 0; # not running under some shell
#
# $Id: psync,v 0.67 2004/05/03 14:53:30 dankogai Exp $
#

[snip]

0.70:
#
# $Id: psync,v 0.70 2005/08/09 15:47:00 dankogai Exp dankogai $
#


Mia culpa.  "make test" does not check to see if shebang is rewritten.
I have just released MacOSX::File 0.71 as follows:

=pod

=head1 NAME

MacOSX::File - A collection of modules to manipulate files on MacOS X

=head1 AVAILABILITY

http://www.dan.co.jp/~dankogai/cpan/MacOSX-File-0.71.tar.gz

and CPAN near You

=head1 CHANGES

$Revision: 0.71 $ $Date: 2005/08/19 06:11:26 $
! bin/psync
  Addressed: #!/usr/local/bin/perl missing, causing unsuable
  script being installed.  Ouch!
  Message-Id: <[EMAIL PROTECTED]>
! bin/psync
  POD fixes by Jean-Louis Fuchs
  Message-Id: <[EMAIL PROTECTED]>

=head1 AUTHOR

Dan Kogai <[EMAIL PROTECTED]>

=cut

Dan the Maintainer of MacOSX::File

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDBXqzErJia/WXtBsRAu3FAJ97/g2lTfbwTC/2bf6OJLZ8syhwIQCffqB3
+yGZe4UuOMp+dY5UHF7hBYI=
=eI6r
-END PGP SIGNATURE-

MacOSX::File 0.70 released

[Dan Kogai]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Folks,

Sorry for those who waited, especially Tiger users, for MacOSX::File  
which did not make test fine.  Now it does, with version 0.70.


(I ought to have done so at OSCON but the connection there was  
sporadic and I barely released Encode-2.11 :)


=head1 AVAILABILITY

http://www.dan.co.jp/cases/macosx/MacOSX-File-0.70.tar.gz
and CPAN near you as it propagates

=head1 CHANGES

$Revision: 0.70 $ $Date: 2005/08/09 15:47:00 $
+ t/AskGetFileInfo.pm
! t/catalog.t t/info.t
  Modified so it passes under Tiger.
! File.pm bin/*
  tiger's utilities are now mentioned in pod
! bin/psync
  is now replaced with that of Jean-Louis Fuchs
  <[EMAIL PROTECTED]>
  Message-Id: <[EMAIL PROTECTED]>

=head1 Signature

Dan the Maintainer Thereof, with Round Tuit :)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFC+NSCErJia/WXtBsRAol7AJ9kSNZs5f9HeP5vLn0AjrHPnxYdHQCgiOTw
WqPtSW5XynvEA2ZAt0yqo5I=
=JSm1
-END PGP SIGNATURE-

Re: psync and MacOSX::File installing with cpan

[Dan Kogai]

Folks,

On Jul 09, 2005, at 12:56 , Chris Devers wrote:

The first failed test is:

use MacOSX::File::Catalog;
...
my $asked = askgetfileinfo("dummy");
$asked eq "avbstcLinmed" ? ok(1) : ok(0);

The second failed test is nearly identical:

use MacOSX::File;
use MacOSX::File::Info;
...
my $asked = askgetfileinfo("dummy");
ok($asked eq "avbstcLinmed");

So... something wrong with askgetfileinfo() on Tiger maybe ?


Looks like on Tiger there appeared one more attribute 'z',

man GetFileInfo

   zBusy (allowed on folders)


I will come up w/ a workaround so please wait for a while...

Dan the Maintainer Thereof

Universal Binary vs. Perl5

[Dan Kogai]

Porters,

So it happened.

I am surprisingly unsurprised at the news.  These days I hardly care  
CPUs.  I am as CPU-blind ad "Color-blind" (in a politically correct  
sense).  But as a Perl5 porter I found at least a couple of issues we  
have to care.


What's gonna happen to XS?
--

It already uses ".bundle" so in theory it can handle multiple  
architectures but in practice?


And Archname?
-

Hmm  This one may not be an issue.   Usually it is CPU-OS-misc  
(i.e. i386-freebsd-64int) but It is simply "darwin".


Any thoughts?

Dan the (Perl5 Porter|Mac User Since 1989)

Re: MacOSX::File 0.69 released

[Dan Kogai]

On Dec 04, 2004, at 08:35, Randall Perry wrote:
I get these errors on make test with v 0.69 on Mac OS 10.3.6, gcc 3.3, 
perl
5.8.5:

ld: Undefined symbols:
_FSGetCatalogInfo
_FSPathMakeRef
_FSRefMakePath
_FSpMakeFSRef
_FSSetCatalogInfo
_FSpRstFLock
_FSpSetFLock
_FSCloseFork
_FSCreateFileUnicode
_FSGetDataForkName
_FSGetResourceForkName
_FSOpenFork
_FSReadFork
_FSWriteFork
make[1]: *** [perl] Error 1
make: *** [perl] Error 2
Please read
http://www.dan.co.jp/cases/macosx/psync.html
and try again.  Especially "Building on Panther" Part.  Make sure you 
install "Cross-development".

Dan the Maintainer Thereof

Re: Mac OS X POD viewer app

[Dan Kogai]

On Nov 14, 2004, at 01:29, John Siracusa wrote:
Is there an OS X equivalent of the old Shuck POD viewer app that came 
with
MacPerl?  I know I can convert the POD to HTML and view that, but I'd 
rather
just have something like Shuck for quick "rich text" views of POD in 
OS X.
Terminal.app :)  Well, I'm quite happy w/ it.
Or you can try pod2html that comes w/ perl itself.  Just pod2html the 
document you want and put it under ~/Sites/, run httpd via Preferences 
and view via http://localhost/.

These don't quite replace good old Shuck but once again I'm quite happy 
w/ them.

Dan the BSD Chauvinist

MacOSX::File 0.69 released

[Dan Kogai]

In response to recent thread on psync/panther, I have checked the case 
and found that on Panther + preinstalled perl, make test passes fine 
but noisy w/ v-string warnings.  Version 0.69 just corrects that.  
There are no other changes so existing users don't have to update.

Availability

http://www.dan.co.jp/cases/macosx/MacOSX-File-0.69.tar.gz
or CPAN near you.
Changes
---
$Revision: 0.69 $ $Date: 2004/08/05 03:18:15 $
! File.pm Catalog/Catalog.pm Spec/Spec.pm Copy/Copy.pm Info/Info.pm
  s/use 5.6.0;/use 5.006;/ so v-string warning on 5.8.1-RC3 is quiet.
This version is tested on:
--
* Jaguar + /usr/bin/perl (5.6.0)
 + /usr/local/bin/perl (5.8.5)
* Panther + /usr/bin/perl (5.8.1-RC3)
  + /usr/local/bin/perl (5.8.5)
Dan the Maintainer Thereof

Re: pSync/Panther how?

[Dan Kogai]

On Aug 05, 2004, at 02:27, Chris Nandor wrote:
In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Dan Kogai) wrote:
I have recently found that gcc2, which is required to build
MacOSX::File on Panther's pre-installed version of perl, is not
I build MacOSX::File just fine with gcc3 on Panther.  In fact, I 
*cannot*
build with gcc2.
You need gcc2 if and only if your perl is pre-installed /usr/bin/perl 
(5.8.1-RC3).   Otherwise gcc3 is used.  Here is the exact code that is 
used in Makefile.PL

WriteMakefile
(
 # 
 ($] <= 5.008001 ? (CC => 'gcc2') : ()),
);
Dan the Maintainer Thereof

Re: pSync/Panther how?

[Dan Kogai]

Fellow users of MacOSX::File (and psync)
Hi Ingo,
I am using psync on Panther and I like it very much.  No trouble, it 
just works.
Here is my version info.

Joe.
[Abba:~] josephal% perl -v
This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
(with 1 registered patch, see perl -V for more detail)
[snip]
I have recently found that gcc2, which is required to build 
MacOSX::File on Panther's pre-installed version of perl, is not 
installed when you choose "easy install" on Xcode.  I have updated the 
document

http://www.dan.co.jp/cases/macosx/psync.html
to reflect the changes.
Dan the Maintainer Thereof

Re: Sort by Mod Date

[Dan Kogai]

On May 14, 2004, at 11:53, Ken Williams wrote:
Instead of using string-munging, you can use a real data structure:
How come no one here is using hash?

#!/usr/bin/perl -Tw
use strict;
my $dir = shift || '.';
my %mtime;
opendir my $dh => $dir or die "$dir:$!";
foreach my $f (grep !/^\./, readdir($dh)){
my $path = "$dir/$f";
# next unless -f $path and -r $path; # commented out
$mtime{$path} = (stat($path))[9];
}
closedir $dh;
foreach my $f (sort {$mtime{$b} <=> $mtime{$a}} keys %mtime){
# print "$f\n"
printf "%s $f\n", scalar(localtime($mtime{$f})); # prettier print
}
__END__
Dan the Camel (?:ab)user

P.S.  FYI ls command has -t option that does just this

Re: MacOSX::File on Panther

[Dan Kogai]

On Friday, Oct 24, 2003, at 14:58 Asia/Tokyo, [EMAIL PROTECTED] wrote:
No, it doesn't work for me.  I had tried something similar, but it 
seems that -U only affects a corresponding -D, but not #define in 
files.
Hmm  Right.  Okay.  It seems like I have to work it out which I 
will start right now.  But I have to begin w/ downloading the latest 
seed, burning the CD and install it.  It will take half a day, at 
least, to fix my testbed.  Since Panther release is so close I would 
like to use your patch for last-minute insurance;  Can I post your 
patch in my web?

Dan the Maitainer of MacOSX::File

Re: MacOSX::File on Panther

[Dan Kogai]

Panther users,

On Friday, Oct 24, 2003, at 13:41 Asia/Tokyo, Dan Kogai wrote:
On Friday, Oct 24, 2003, at 02:42 Asia/Tokyo, [EMAIL PROTECTED] wrote:
Yes, this seems to be another case of a Perl define (I_POLL) 
colliding with a Mac OS X one (in OpenTransportProtocol.h).  Panther 
now has poll() (an emulation actually), so that is why I_POLL is now 
defined.

A quick workaround is to apply the following patch:
Thank you!
If such is a deal, would somebody try

make CC='gcc2 -UI_POLL'

and see if it works?  Currently I do not have an access to the latest 
Panther and it will take a while before my Panther environment gets 
ready enough to test an official Panther-ready, Jaguar-compatible 
version.

FYI, the command line above is at least Jaguar-compatible.

Thanks in advance.

Dan the Maintainer of MacOSX::File

Re: MacOSX::File on Panther

[Dan Kogai]

On Friday, Oct 24, 2003, at 02:42 Asia/Tokyo, [EMAIL PROTECTED] wrote:
Yes, this seems to be another case of a Perl define (I_POLL) colliding 
with a Mac OS X one (in OpenTransportProtocol.h).  Panther now has 
poll() (an emulation actually), so that is why I_POLL is now defined.

A quick workaround is to apply the following patch:
Thank you!

Dan the Panther-user-to-be

Re: Installing Encode in Mac OS (Panther)

[Dan Kogai]

On Thursday, Aug 7, 2003, at 03:47 Asia/Tokyo, John Delacour wrote:
Hello Dan,

I'm having difficulty installing Encode ion the Mac.  Perl -V = 5.8.1

Can you advise me what to do?

[snip]

-bash-2.05b$ make
/usr/bin/perl /System/Library/Perl/5.8.1/ExtUtils/xsubpp 
-nolinenumbers -typemap /System/Library/Perl/5.8.1/ExtUtils/typemap 
Byte.xs > Byte.xsc && mv Byte.xsc Byte.c
cc -c  -I../Encode -g -pipe -pipe -fno-common -no-cpp-precomp 
-fno-strict-aliasing -I/usr/local/include -Os   -DVERSION=\"1.23\" 
-DXS_VERSION=\"1.23\" 
"-I/System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE" Byte.c
cc -c  -I../Encode -g -pipe -pipe -fno-common -no-cpp-precomp 
-fno-strict-aliasing -I/usr/local/include -Os   -DVERSION=\"1.23\" 
-DXS_VERSION=\"1.23\" 
"-I/System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE" > byte_t.c
Running Mkbootstrap for Encode::Byte ()
chmod 644 Byte.bs
rm -f ../blib/arch/auto/Encode/Byte/Byte.bundle
LD_RUN_PATH="" MACOSX_DEPLOYMENT_TARGET=10.3 cc  -bundle -undefined 
dynamic_lookup -L/usr/local/lib Byte.o byte_t.o  -o 
../blib/arch/auto/Encode/Byte/Byte.bundle
ld: -undefined: unknown argument: dynamic_lookup
make[1]: *** [../blib/arch/auto/Encode/Byte/Byte.bundle] Error 1
make: *** [subdirs] Error 2
It appears that you are running old cc on Panther (which does not know 
-undefined dynamic_lookup).  Make sure you install/upgrade Developer 
Tools that matches Panther.  FYI Encode builds hairlessly on my Panther.

Dan the Encode Maintainer

Re: Psync, small pseudo-bug

[Dan Kogai]

On Thursday, Aug 7, 2003, at 03:33 Asia/Tokyo, alex black wrote:
However, I have a small problem with it that is not your fault (or
necessarily even your responsibility with psync) but the fault of the
finder:
Say I have a directory on the source volume:

Blah/
stuff.txt
pic.jpg
moo.sit
And I delete that directory. I expect that Blah/ will disappear on the
target (backup) volume once I run psync. It does not. I looked at my 
logs
and realized that psync was doing a "normal" rm on the directory and 
failing
because the finder *curse it* dumps a .DS_Store file in the directory.
Therefore the directory is not empty and psync won't delete it.
Yikes.

I could have used rmtree() of File::Path to make sure it is empty (the 
obvious drawback is that it is slow).

One easy workaround is apply;

find /Volumes/Backup -type f -name .DS_Store -delete -print

before committing psync.  That ensures that .DS_Store does not exist.

So - because you are not recursively forcing an rm on the directory, 
and
because the finder litters the filesystem with trash (I have a special 
alias
called cleancrap which searches my cvs-controlled directories for 
.DS_stores
and deletes them)... My backups are littered with empty old folders 
that I
have long since thrown away.

There's no problem of disk space, .DS_Stores are never more than 8k... 
But
it bites at me :)

Is there a psync flag I'm missing to force recursive removal of 
directories?
If not, would you consider adding one?
Yes, I will but I can't make promises as to when to release the next 
version of MacOSX::File.  Unfortunately I am thrashing recently.

Dan the Man with Too Many Projects to Proceed

Re: Encode failure in conversion from MacArabic/Farsi/Hebrew

[Dan Kogai]

Kino,

On Thursday, Jul 24, 2003, at 14:39 Asia/Tokyo, Kino wrote:
Anyway, I will make mac(Arabic|Farsi|Hebrew).ucm available BEFORE 
releasing the next version of Encode so I appreciate if you test >> them.
I'll be very happy to test them.
I am sorry I forgot to report this to you but the patch is already in 
bleedperl (though 1.98 remains unrelased) I have sent the patch to jhi 
because he was in a hurry (that happened right after RC4).  You can get 
the UCMs via

http://www.dan.co.jp/~dankogai/macbidi-ucm.tar.gz

Thank you in advance for testing them.

Dan the Encode Maintainer

Re: psynch and Panther

[Dan Kogai]

On Monday, August 4, 2003, at 7:39 AM, Bill Henry wrote:
Dan

I am using Panther b21 and it does not seem to work with the psync in  
CCC from Mike Bombich, or even your stand alone psync 2.0 product

Any updates in the works?
I have finally got Panther Preview and acknowledged the problem.

% make
cp File/Constants.pm blib/lib/MacOSX/File/Constants.pm
AutoSplitting blib/lib/MacOSX/File/Constants.pm  
(blib/lib/auto/MacOSX/File/Constants)
cp File.pm blib/lib/MacOSX/File.pm
cp Catalog.pm ../blib/lib/MacOSX/File/Catalog.pm
AutoSplitting ../blib/lib/MacOSX/File/Catalog.pm  
(../blib/lib/auto/MacOSX/File/Catalog)
/usr/local/bin/perl /usr/local/lib/perl5/5.8.1/ExtUtils/xsubpp   
-typemap /usr/local/lib/perl5/5.8.1/ExtUtils/typemap  Catalog.xs >  
Catalog.xsc && mv Catalog.xsc Catalog.c
cc -c  -I../ -I/Developer/Headers/FlatCarbon -pipe -fno-common  
-DDARWIN -no-cpp-precomp -fno-strict-aliasing -Os   -DVERSION=\"0.64\"  
-DXS_VERSION=\"0.64\"   
"-I/usr/local/lib/perl5/5.8.1/darwin-thread-multi-64int-2level/CORE"
Catalog.c
In file included from  
/System/Library/Frameworks/CoreServices.framework/Frameworks/ 
CarbonCore.framework/Headers/CarbonCore.h:113,
 from  
/System/Library/Frameworks/CoreServices.framework/Headers/ 
CoreServices.h:21,
 from /Developer/Headers/FlatCarbon/Files.h:1,
 from ../common/util.c:9,
 from Catalog.xs:16:
/System/Library/Frameworks/CoreServices.framework/Frameworks/ 
CarbonCore.framework/Headers/Debugging.h:285:2: #else without #if
/System/Library/Frameworks/CoreServices.framework/Frameworks/ 
CarbonCore.framework/Headers/Debugging.h:287:2: #endif without #if
/System/Library/Frameworks/CoreServices.framework/Frameworks/ 
CarbonCore.framework/Headers/Debugging.h:301:1: missing binary  
operator before token "enum"
Catalog.c:313:1: unterminated #if
make[1]: *** [Catalog.o] Error 1
make: *** [subdirs] Error 2
As you see, the error occurs on Carbon headers so it must have  
something to do with new gcc or dev tool.  Very fortunately I have  
found a very simple workaround.  Instead of simple 'make', type 'make  
CC=gcc2' and it builds fine.  See the log right after my signature.

As you see 'make test' is noisy because we--perl5 porters have decided  
to depreciate v-string and MacOSX::File as of 0.66 does use that.  That  
will be addressed in the next release but I would like you people to  
wait until perl 5.8.1 ships (very soon, at least sooner than Panther).

If you have other wishlist (such as minor bug(s) in psync), please post  
here at [EMAIL PROTECTED] so we can share.

Oh, one more thing.  Please note that I only maintain MacOSX::File.   
CCC and PsyncX do use the psync script that comes with MacOSX::File but  
they are not works of mine.

Dan the Man with Too Many Platforms to Support

% /usr/bin/perl Makefile.PL
Checking if your kit is complete...
Looks good
Writing Makefile for MacOSX::File::Catalog
Writing Makefile for MacOSX::File::Copy
Writing Makefile for MacOSX::File::Info
Writing Makefile for MacOSX::File::Spec
Writing Makefile for MacOSX::File
[EMAIL PROTECTED]:~/work/MacOSX-File-0.66% make CC=gcc2
cp File.pm blib/lib/MacOSX/File.pm
cp File/Constants.pm blib/lib/MacOSX/File/Constants.pm
AutoSplitting blib/lib/MacOSX/File/Constants.pm  
(blib/lib/auto/MacOSX/File/Constants)
cp Catalog.pm ../blib/lib/MacOSX/File/Catalog.pm
AutoSplitting ../blib/lib/MacOSX/File/Catalog.pm  
(../blib/lib/auto/MacOSX/File/Catalog)
/usr/bin/perl /System/Library/Perl/5.8.1/ExtUtils/xsubpp  -typemap  
/System/Library/Perl/5.8.1/ExtUtils/typemap  Catalog.xs > Catalog.xsc  
&& mv Catalog.xsc Catalog.c
gcc2 -c  -I../ -I/Developer/Headers/FlatCarbon -g -pipe -pipe  
-fno-common -no-cpp-precomp -fno-strict-aliasing -Os
-DVERSION=\"0.64\" -DXS_VERSION=\"0.64\"   
"-I/System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE"
Catalog.c
In file included from  
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h: 
13,
 from  
/System/Library/Frameworks/CoreFoundation.framework/Headers/ 
CoreFoundation.h:8,
 from  
/System/Library/Frameworks/CoreServices.framework/Frameworks/ 
CarbonCore.framework/Headers/CarbonCore.h:20,
 from  
/System/Library/Frameworks/CoreServices.framework/Headers/ 
CoreServices.h:21,
 from /Developer/Headers/FlatCarbon/Files.h:1,
 from ../common/util.c:9,
 from Catalog.xs:16:
/usr/include/gcc/darwin/2.95.2/g++/../stdbool.h:10: warning: empty  
declaration
Catalog.xs: In function `XS_MacOSX__File__Catalog_xs_setcatalog':
Catalog.xs:263: warning: assignment makes pointer from integer without  
a cast
Running Mkbootstrap for MacOSX::File::Catalog ()
chmod 644 Catalog.bs
rm -f ../blib/arch/auto/MacOSX/File/Catalog/Catalog.bundle
LD_RUN_PATH="" MACOSX_DEPLOYMENT_TARGET=10.3 cc  -bundle  
-flat_namespace -undefined suppress -framework Carbon Catalog.o  -o  
../blib/arch/auto/MacOSX/File/Catalog/Cata

Re: Encode failure in conversion from MacArabic/Farsi/Hebrew

[Dan Kogai]

On Wednesday, Jul 23, 2003, at 23:20 Asia/Tokyo, Kino wrote:
I remember someone has already brought this issue up several months 
ago. As I'm just a newbie in perl, I'm hesitating in reporting this. 
I'm not 100% sure if it is a bug. Anyway...
Obviously I have overlooked and thanks for rehashing me.


3. Terminal showed

MacArabic "\x20" does not map to Unicode.
MacArabic "\x21" does not map to Unicode.
MacArabic "\x22" does not map to Unicode.
These are easy to fix;  Just copy the missing parts from ASCII.

4. In result.txt, those characters, i.e. \x20-\x2F, \x3A-\x3F, 
\x5B-\x5F, \x7B-\x7D, \x81, \x8C, \x93, \x98, \x9B, \xA0-\xA4, 
\xA6-\xAB, \xAD-\xBA, \xBC-\xBE, \xC0, \xDB-\xDF, \xFB-\xFD have not 
been converted to appropriate characters but changed to hexadecimal 
notation.
I am not sure if I can fix these by simply reapplying ARABIC.TXT 
because of BIDI issues.

I think those characters should be converted properly since they are 
mapped in


Similar results with conversion from MacFarsi and MacHebrew.


Anyway, I will make mac(Arabic|Farsi|Hebrew).ucm available BEFORE 
releasing the next version of Encode so I appreciate if you test them.

Dan the Encode Maintainer

Re: Pantherbites

[Dan Kogai]

On Thursday, Jul 24, 2003, at 01:18 Asia/Tokyo, Edward Moy wrote:
Did you file a bug report?  Don't worry, I already did (#3340036).
I was about to do but I am a Perl5 Porter before OS X user so @perl.org 
had precedence.  Plus it is in the middle of the change of the season 
(rainy -> summer) and I always get cold during then. Cold won before I 
file the report.  Thanks for moving so quickly.

Do you think I did this on purpose?  I hope not.
Not at all.  If I were you I'd have fallen in the same pit.  And I am 
rather glad we have found this problem before Panther matures to 
adulthood.

Do you think this has never happened before?  No, Perl 5.6.0 on Jaguar 
and previous had the same problem with CVS (no -ko option) and only 
now was it ever noticed.  And in the several months since I inherited 
Perl (actually asked for it), I would have fixed it if I had known.
That was the conclusion I have reached;  Perl 5.6.0 has far less 
modules and most modules hardcoded $VERSION so it went unnoticed.

I think it is a good timing to introduce what Ilya has mentioned.

On Wednesday, Jul 23, 2003, at 23:34 Asia/Tokyo, Ilya Martynov wrote:
Better solution is to use FreeBSD's patches for CVS to support custom
revision tags. This solves this problem nicely by allowing several
maintainers to have their own revision tags in same source code.
For examples snippet from /usr/src/crypto/openssh/ssh-agent.c

RCSID("$OpenBSD: ssh-agent.c,v 1.97 2002/06/24 14:55:38 markus Exp $");
RCSID("$FreeBSD: src/crypto/openssh/ssh-agent.c,v 1.2.2.8 2002/07/03 
22:11:43 des Exp $");
I would love to see the $Darwin$ tags!

Back to emoy
Sorry, I don't usually get personal, but tone of this message seemed 
inappropriate to me.
And here is my apology for the tone of my voice.  Well, I have cold to 
blame (my nasal cavity is so stuffy that I should have literally stood 
in a way of frontal lobe of my cerebrum).

Nevertheless, consider this problem fixed for final Panther.
I am 80% proud and 20% scared to see my codes become a part of the most 
popular *NIX available today.  Keep going!

Dan the (Encode Maintainer|Panther-user-to-be)

Re: Pantherbites

[Dan Kogai]

Hmm  Mail 1.3 seems to need some more work (back in Jaguar)

On Wednesday, Jul 23, 2003, at 21:32 Asia/Tokyo, Dan Kogai wrote:

I have finally gotten an access to Panther so here is my preliminary 
report on it as a Perl5 Porter.  Let me begin with pros

* It is good looking
* And fast
* I love Expos~{(&~}.
I meant Exposé or qq(Expos\x{00e9}).

* took 15 minutes to find how to enter '\' (backslash) instead of 
~{#$~} (yen) ONCE Kotoeri is
And ￥ (FULLWIDTH YEN: \x{ffe5}.

Content-Type: text/plain; charset=HZ-GB-2312; format=flowed
Content-Transfer-Encoding: 7bit
Mail 1.3 was obviously out of mind!

Dan the Perl5 Porter

Pantherbites

[Dan Kogai]

I have finally gotten an access to Panther so here is my preliminary 
report on it as a Perl5 Porter.  Let me begin with pros

* It is good looking
* And fast
* I love Expos~{(&~}.
Now cons

* input method is a mess!  I like the old one ("disintegrated") better.
* took 15 minutes to find how to enter '\' (backslash) instead of ~{#$~} 
(yen) ONCE Kotoeri is enabled.  Once Kotoeri is enabled, '\' key 
refuses to backslash and yens yens yens!  Solution: Add "US Extended" 
via [Input Menu] tab of [International] Preference Panel and use it.
* And... Perl 5.8.1 which I will discuss a little deeper.

Yes.  As announced earlier Panther Preview comes w/ Perl 5.8.1-tobe 
(MAINT19524 to be exact) so I hope we will make Perl 5.8.1 a reality 
before Panther is.  Anyway, As an Encode Maintainer I naturally typed

perl -MEncode -le 'print Encode->VERSION'

and here is what Panther said

1.04

Ohmygod!  Even Perl 5.8.0 comes with Encode ver. 1.75.  WHAT HAS 
HAPPEND!?  So I 'perldoc -m Encode' and found this.

#
# $Id: Encode.pm,v 1.4 2003/05/20 22:49:15 emoy Exp $
#
package Encode;
use strict;
our $VERSION = do { my @r = (q$Revision: 1.4 $ =~~ /\d+/g); sprintf 
"%d."."%02d" x $#r, @r };
Aha!   Now I see.  emoy has checked in MAINT19524 source and RCS 
retagged $Revision$.  I'm sorry emoy but this is NOT THE RIGHT THING 
(TM).

Perl module infrastructure depends heavily upon version numbers and 
auto-versioning via RCS/CVS as above is a common technique in perl.

I surely hope this will be fixed in real Panther...

Dan the Encode Maintainer Just gotten a first bite by the baby Panther

Re: Japanese + Encode::Guess

[Dan Kogai]

On Friday, June 20, 2003, at 05:40  PM, Robin wrote:
I'm trying to find out what encoding has been used on a file. It was 
created in a text editor under OS9, but edited also under OSX, the 
scripe below outputs:

Encode::XS=SCALAR(0x94a2c), which when de-reffed is '2421076'
Looks like it is Encode::Guess is working right since it returns a 
object reference.  Now all you have to do is

#!/usr/bin/perl -w
use Encode::Guess qw/euc-jp shiftjis 7bit-jis /;
$enc = guess_encoding($data, qw/euc-jp shiftjis 7bit-jis MacJapanese 
utf8 /);
ref($enc) or die "Can't guess: $enc"; # trap error this way

print ${enc};
print $enc->name;

That will tell you the name of encoding found and

my $utf8 = $enc->decode($data);

will decode $data.

Dan the Encode Maintainer

Re: Few questions about psync

[Dan Kogai]

On Saturday, June 7, 2003, at 11:37  AM, Scott Haneda wrote:
I have a few q's about psync, do you have time?

I use as root
psync -d / /Volumes/backupplace/daily
psync -d / /Volumes/backupplace/weekly
Cron triggers them accordingly...
I can not seem to get the Startup Disk Pref Pane to see either of the 2
directories as bootable, played a little with the bless command, but 
still
no go.
That is the difference between a volume and a directory.  Volume must 
be the physical root of where all other subdirectories reside and 
Startup Disk does see the difference.  It only checks volumes, not 
directories in general.

Does psync not work unless I point it to /Voume/volumename and not to a
sundirectory thereof?  In the even I needed to boot, could I just mv * 
up
one directory?
psync does back up right but when the target is a subdirectory of a 
volume it does not work as a startup volume.

If you want BOTH 'daily' and 'weekly' bootable, partition your drives.

Dan the Man with Too Many Volumes to Backup

Re: [MacOS X] consider useshrplib='false' by default

[Dan Kogai]

On Wednesday, June 4, 2003, at 08:03  PM, Chris Nandor wrote:
In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Dan Kogai) wrote:
As you see ${ldflags} is injected into $lddlflags but in case of
-prebind we need to avoid that.  $ldflags is for perl linking while
$lddlflags is for XS.  Since -prebind and -bundle are mutually
exclusive, we do not want -prebind in $lddlflags (though CC on darwin
is smart enough to ignore -prebind when -bundle, it still issues
warnings and I don't want to see that warning for each XS gets built).
Another question is whether to use something other than bundle for XS, 
to
allow prebinding.  I have a patch to dl_dyld.xs that seems to work; it
allows both bundle and dyld (thanks to some pointers from wsanchez).
That's a great work but with all due respect I do not think making XS 
prebindable a good idea.  Correct me if I am wrong but my understanding 
on prebinding is that it is a technique that makes dynamic libraries 
behave like static ones by predetermining ALL ADDRESSES IN NEED A 
PRIORI.

With -Uuseshrplib, the only dynamic library you need is libSystem 
(which is what libc and libm really are).  So it is safe to assume that 
no addresses would collide.
% otool -L ./perl
./perl:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 63.0.0)
But to make XS prebindable you have to make sure that addresses never 
collide FOR ALL MODULES.  When that fails XS may still work (so far as 
I see dyld is smart enough to make sure to to collide symbols and 
addresses and diverts that when it needs but when that happens a 
warning is issued).

Since no one knows how many XSes a particular user needs, I think we 
should leave -bundle for XS.

Theoretically, however, we can still resolve this by keeping a symbol 
table handy somewhere and use that during XS builds but that I consider 
a too much work.

Dan the Prebound Man

Re: [MacOS X] consider useshrplib='false' by default

[Dan Kogai]

On Wednesday, June 4, 2003, at 04:01  PM, Dan Kogai wrote:
I think we should but the biggest problem on slow startup was 
primarily libperl.dylib (too may symbols for fix_prebinding daemon to 
tweak).  I am now working on benchmarking the difference but even 
without -prebind flag the launch speed increase was significant.
And here is the benchmark.

with the new default as of 19681
% otool -hv ./perl
./perl:
Mach header
  magic cputype cpusubtype   filetype ncmds sizeofcmds  flags
   MH_MAGIC PPCALLEXECUTE 9   1604   NOUNDEFS 
DYLDLINK
% redo_prebinding ./perl
redo_prebinding: file is not prebound: ./perl
% time /usr/bin/perl -le 'for (1..$ARGV[0]){system $ARGV[1], qw(-e 
1)}' 1000 ./perl
2.860u 6.680s 0:12.75 74.8% 0+0k 0+4io 0pf+0w
with -Dldflags='-prebind' -Dlddflags='-bundle -undefined dynamic_lookup'
% otool -hv ./perl./perl:Mach header
  magic cputype cpusubtype   filetype ncmds sizeofcmds  flags
   MH_MAGIC PPCALLEXECUTE12   1884   NOUNDEFS 
DYLDLINK PREBOUND TWOLEVEL
% redo_prebinding ./perl
% time /usr/bin/perl -le 'for (1..$ARGV[0]){system $ARGV[1], qw(-e 
1)}' 1000 ./perl
2.290u 6.490s 0:11.59 75.7% 0+0k 0+3io 0pf+0w
As you see -prebind does help though not as significant as -Uuseshrplib.

man 8 fix_prebinding
hese hints are used by the dynamic loader to launch processes prebound,
 eliminating the need to look up dynamically linked symbols.  If 
these
 hints are out-of-date, the dynamic linker instead must lookup 
referenced
 symbols.  As a result, the application may launch from 10-30% 
slower.
So this still holds true at least for user time.  Though the time 
saving might not be significant for ordinary users,  Busy web sites 
with lots of CGIs should definitely benefit.

Dan the Benchmarker of Yours

P.S.  Here is the comparison against our "competitors" and the script I 
used to benchmark. see we compare by cusr and csys, not usr and sys.  
Anything other than perl are pre-installed version.

#
use strict;
use Benchmark qw/:all/;
my $null = '/dev/null';
my $count = shift;
my %benches = map {  $_ => eval qq/sub{ system '$_'=>'$null' }/ } @ARGV;
my $results = timethese($count => \%benches, 'all');
# Since we are benchmarkning system, we swap (usr,sys) and (cusr,csys)
# to get a correct values for cmpthese or the value gets bogus
#  0  1  23   4 5
# ($real, $user, $system, $children_user, $children_system, $iters)
for my $k (keys %$results){
my $v = $results->{$k};
@$v[1,2,3,4] = @$v[3,4,1,2]
 }
cmpthese($results, 'all');
__END__
Ratepython  ruby tclsh./perlsh 
perl5.6.0
python16.7/s--  -29%  -77%  -82%  -85%  
-87%
ruby  23.6/s   41%--  -67%  -74%  -79%  
-81%
tclsh 71.4/s  327%  202%--  -23%  -38%  
-43%
./perl92.6/s  454%  292%   30%--  -19%  
-26%
sh 115/s  587%  386%   61%   24%--  
 -8%
perl5.6.0  125/s  647%  429%   75%   35%9%  
  --

We are doing great!  Note ./perl is compiled with full of options like 
-DDEBUGGING and -Dusethreads.

P^2.S.  jhi, is there an option to make (time|cmp)these to compare by 
cusr and csys so I don't have to tweak like the script above?

Re: [MacOS X] consider useshrplib='false' by default

[Dan Kogai]

On Wednesday, June 4, 2003, at 03:33  PM, Jarkko Hietaniemi wrote:
Sounds reasonable to make the useshrplib to default to false (because
of the significant startup slowness otherwise) and at the very least
make it conditional (and I got a nod from Ed Moy of Apple, too).
So I did (change #19681).
Thank you.

How about the -prebind flags et alia?  Should they be made default, 
too?
I think we should but the biggest problem on slow startup was primarily 
libperl.dylib (too may symbols for fix_prebinding daemon to tweak).  I 
am now working on benchmarking the difference but even without -prebind 
flag the launch speed increase was significant.

One more caution if we want to make -prebind a default is here.

hints/darwin.sh
122:case "$osvers" in
123:1.[0-3].*)
124:   lddlflags="${ldflags} -bundle -undefined suppress"
125:   ;;
126:1.*)
127:   ldflags="${ldflags} -flat_namespace"
128:   lddlflags="${ldflags} -bundle -undefined suppress"
129:   ;;
130:[2-6].*)
131:   ldflags="${ldflags} -flat_namespace"
132:   lddlflags="${ldflags} -bundle -undefined suppress"
133:   ;;
134:*) lddlflags="${ldflags} -bundle -undefined dynamic_lookup"
135:   case "$ld" in
136:   *MACOSX_DEVELOPMENT_TARGET*) ;;
137:   *) ld="MACOSX_DEPLOYMENT_TARGET=10.3 ${ld}" ;;
138:   esac
139:   ;;
140:esac
As you see ${ldflags} is injected into $lddlflags but in case of 
-prebind we need to avoid that.  $ldflags is for perl linking while 
$lddlflags is for XS.  Since -prebind and -bundle are mutually 
exclusive, we do not want -prebind in $lddlflags (though CC on darwin 
is smart enough to ignore -prebind when -bundle, it still issues 
warnings and I don't want to see that warning for each XS gets built).

Dan the "Prebound" Man

[MacOS X] consider useshrplib='false' by default

[Dan Kogai]

Porters,

  I would like to propose that we make useshrplib='false' default for  
darwin to resolve prebinding woes.

I said "update_prebinding -root /" should resolve the problem but only  
temporarily.  perl is in fact not prebind.  This is what is actually  
happning.

% env DYLD_PREBIND_DEBUG=1 /usr/local/bin/perl -e 1
dyld: perl: prebinding disabled because library:  
/usr/local/lib/perl5/5.8.0/darwin-thread-multi-64int/CORE/ 
libperl.dylib got slid
dyld: in notify_prebinding_agent() determined the system shared  
regions are NOT used
dyld: 2 two-level prebound libraries used out of 3
At this stage no "/usr/libexec/fix_prebinding: /usr/local/bin/perl  
couldn't be prebound in the past, and probably can't be prebound now."  
is issued.  But as time goes by and more system gets used, "dyld: 2  
two-level prebound libraries used out of 3" stops working and the  
(in)?famous fix_prebinding warning starts appearing in your  
/var/log/system.log.

When you attempt to compile perl with -prebind switch, however, this is  
what happens
DYLD_LIBRARY_PATH=/Users/dankogai/work/perl-5.8.0 cc -prebind -o  
miniperl \
miniperlmain.o opmini.o libperl.dylib -lm -lc
cc: unrecognized option `-prebind_allow_overlap'
ld: warning multiple definitions of symbol _Perl_listkids
opmini.o definition of _Perl_listkids in section (__TEXT,__text)
[lots of similar ld warnings to follow]
So it does not work in practice.  But when you turn off useshrplib,  
prebinding works beautifully.
To test that for yourself, just Configure with

-Dldflags='-prebind' -Dlddflags='-bundle -undefined dynamic_lookup'  
-Uuseshrplib

And the change? Significant!  See this

Reference: bundled version
% time /usr/bin/perl -le 'for (1..$ARGV[0]){system $ARGV[1], qw(-e  
1)}' 1000 /usr/bin/perl5.6.0
1.560u 4.680s 0:07.46 83.6% 0+0k 0+0io 0pf+0w
-Duseshrplib
% time /usr/bin/perl -le 'for (1..$ARGV[0]){system $ARGV[1], qw(-e  
1)}' 1000 /usr/local/bin/perl
21.490u 8.690s 0:33.22 90.8%0+0k 0+1io 0pf+0w
-Uuseshrplib and prebinding
%time /usr/bin/perl -le 'for (1..$ARGV[0]){system $ARGV[1], qw(-e 1)}'  
1000 /usr/local/bin/perl
2.190u 5.810s 0:10.42 76.7% 0+0k 0+0io 0pf+0w
As we all know many systems now support -Duseshrplib but not many make  
it a default.

% egrep "useshrplib='?true'?" hints/*.sh
hints/bsdos.sh:useshrplib='true'
hints/darwin.sh:useshrplib='true';
hints/openbsd.sh:   useshrplib=true
hints/os2.sh:useshrplib='true'
hints/os390.sh:'') useshrplib='true' ;;
hints/rhapsody.sh:useshrplib='true';
hints/svr5.sh:  useshrplib='true'
and those listed usually make useshrplib=true conditionally.  It seems  
only darwin makes it unconditionally true.

shared libperl save disk space and memory ONLY WHEN you have many apps  
liked to libperl.  In most cases, however, you have only perl itself  
and mod_perl.  So I suggest that we make useshrplib="false" for darwin.

I know you all know but XS are still dynamically loaded.  So there is  
not much point for -D useshrplib.

Dan the Man too Tired of Unprebindable Camels

Re: psync question

[Dan Kogai]

On Monday, June 2, 2003, at 05:24  AM, J.C. Wren wrote:
Dan,

	I'm a Mac owner, running OSX, but I'm not "into" OSX.  I'm more a 
Linux
person.  What I'm looking for is a solution to backup the complete OSX
volumes, including resource forks (what ever they are, but apparently I
*really* want to keep those...) to a remote server on my network.  
psync
looks like a solution, but the documentation is a little non-specific. 
 Since
I don't want to wipe anything before I go to town, I thought I'd ask 
this
question.  The docs say:

	sudo psync -d / /Volumes/I

	Why 'I'?
That's a document bug.  POD renders I to italic but that was in 
verbatim section so it does not get rendered.  Will be fixed in future. 
 Sorry.

And more importantly, is the software smart enough to skip over the
volume, and not incorporate the work done to this point back into the
archive?
Yes.  Just like -xdev option of find(1).  Unlike find(1) and cp -r 
cross-device copying is suppressed by default.  But just make sure that 
/ and /Volumes/backup reside on different devices.  If they were on the 
same volume this safety feature does not work (just like -xdev).

Can I NFS mount a volume at /Volumes/remote, and
Yes.  But in which case note that some files with unicode names might 
not be copied properly (many fonts under /Library/Fonts do have those 
"unsafe" names.

	psync -d / /Volumes/remote/Ibackup

	And similiarly, what would a restoration process be like?  Can I NFS 
mount
this image (once I've resinstalled OSX), and do a full restore from the
image?  And is there anyway to extract single files from the backup 
set?
The most similar one must be rsync.  And to extract single files you 
don't need to because psync is NOT an archiving utility.  You just copy 
one from backup via cp and such.

	Any help/advice you can provide would be greatly appreciated.  Oh, 
and I
looked at rsync_hfs, and talk about about ZERO documentation...  In 
fact, the
docs in the CVS tree just refer to it as 'rsync', so I'm not sure 
what's
supposed to make rsync_hfs more better.  I would theorize it's HFS 
support,
but there's no discussion about interoperability when moving to remote 
file
systems (like are attributes and these resource fork things preserved?)
That's why it is on CVS only :)   If it were considered stable, there 
should've been binary distributions already.

Dan the Man with Too Many Codes to Maintain

Re: "safe" system()?

[Dan Kogai]

On Saturday, Mar 29, 2003, at 03:23 Asia/Tokyo, Rich Morin wrote:
Let's say that I want to use a command (e.g., md5) on a file.  No
problem; just use:
  system("md5 $file");

Except that the file name could contain all manner of white space
characters, shell wildcard characters, etc.  Is there a module that
deals with this sort of thing (e.g., wrapping each argument in the
appropriate kinds of quoting)?
This is definitely one of the areas where TMTOWTDI blesses you and 
curses you the most.  There are just too many ways to do this kind of 
things to come up with idioms.  But there are rules of thumb;

* Let perl or module do it

Instead of system("md5"...) (Well, I think it is more like open MD5, 
"md5 ... |" if you want to reuse the result in perl), you can use 
Digest::MD5.  Perl itself is versatile enough to do away with the need 
of such commands as grep, sed, and awk.  And with so many modules that 
does shell commands, it is usually much easier to find the module and 
use it than resort to system() or open().

* When you have to, use taint mode and untaint with care

There are still some cases where external commands are (better| the 
only choice).  But just because you decided to use them don't blindly 
system() or open().   Use taint mode.  With taint mode on (via -T 
switch), system("md5 $file") simply dies if $file is set by external 
data.  You have to untaint it to use it. i.e.

my $file = shift; # tainted
$file =~ m/([\w\.\-\+]+)/o; # $1 is not tainted
system("md5", $1); # okay;
See "perldoc perlsec" for details.

* when you system(), do not let shell stand in a way

system("md5 $file") and system("md5", $file) looks the same but they 
are treated completely differently by camel,  The first one is fed to 
the shell (/bin/sh for most cases) but the second one is directly 
invoked by perl so wild cards are not expanded, resulting much safer 
codes.  Not only is it safer but also faster. So when you want to do 
the following,

my $cmd = "command arg1 arg2";

Do

my (@cmd) = split /\s+/ => $cmd;
system(@cmd);
instead of "system($cmd)".

Of course there are still in need of shell, such as cases like below 
when you have to use redirections therein.

$cmd = "command arg1 > out.txt 2> error.txt";

But these cases are much rarer and can usually cope with different 
techniques.  See
"perldoc perlfaq" and "Perl Cookbook".

Dan the Man with Too Many Ways to Do It

Re: [MacPerl] Re: problem with Japanese text

[Dan Kogai]

On Friday, Mar 28, 2003, at 11:37 Asia/Tokyo, Joel Rees wrote:
Not sure if my comments are relevant, just feeling inclined to expose 
my
ignorance --
And here is mine.

Japanese is one of those languages that has relatively few specifically
plural forms. To get the pluralizations right in Japanese, the program
would have to consult a dictionary.
More exactly speaking, Japanese has no plural form in a sense of 
Indo-European languages.  Japanese totally lacks subject-verb agreement 
so you don have to delete the "es" in "does" when you change the 
subject form "s/he" to "they".

On the other hand, counting can be tricky even for natives.  The very 
name of numbers changes depending on what you count.  When you count 
people it goes hito-ri, futa-ri, san-nin but when you count object it 
goes hito-tsu, futa-tsu (or ik-ko, ni-ko,) and the list goes on (I 
think this "number-object agreement" came from Chinese).

But when the number is not an issue, you can totally forget if a 
subject is singular or plural.

Pluralization could probably be ignored for this purpose for Japanese,
but, if the purpose is to produce text that the technically un-inclined
can parse reasonably effortlessly, there are all sorts of other context
related issues, most of which would require not just vocabulary
dictionaries, but idiom dictionaries as well. And your locale 
machinery would
have to include some sensitivity to dialect issues and social status
issues, to make the generated text natural and non-offending.
I feel Japanese is a hard language to compose because of that but that 
also makes Japanese easier to read because Japanese tend to include not 
only "what to say" but also "in what situation by what kind of person 
says".  In English the singular nominative pronoun is nothing but "I", 
no matter how old or young you are or whether you are a boy or a girl 
(or a computer).  But in Japanese it can be "Watashi" or "Boku" or 
"Ore" or "Maro" or "Warawa" or "Sessha" or "Jibun" or "Ware"  even 
English "me" can be used.

Maybe to compensate this complexity, Japanese grammar seems much 
simpler.   No subject-verb agreement, very few irregular verbs   It 
is far easier to compose a grammatically correct Japanese.  It gets 
darn hard once you aim for social and political correctness.

Japanese is becoming more egalitarian, more homogenized, and less
colorful, so those who work on such things are aiming at a moving 
target.
Less colorful I am not sure because at the same time the newer, simple, 
and more boring expressions are pervasive, the old and more complex 
expressions hardly die.  So in total Japanese is getting richer.  Well, 
the total richness of Japanese is I believe is increasing but 
ironically "per-capita" richness might not be.  But I believe this 
phenomenon is not unique to Japanese; could be even more prevalent in 
English.  If you don't believe me just compare the Two Bushes in White 
House :)

Thinking about the recognizer side, did anyone mention that Japanese
text does not use word delimiters? Space has a somewhat different
meaning for Japanese.
Japanese tokenization is nothing but a trivial issue.  In Japanese the 
very notion of "a word" is often moot.  Nevertheless, we do have good 
enough tokenizers to implement input methods and search engines.  Of 
course they are not perfect but the Japanese are very frank about the 
lack of perfection.  After all we don't even have "de jure standard 
Japanese" to compare.

Dan the Man with Too Many Languages to Deal with

Re: [MacPerl] Re: problem with Japanese text

[Dan Kogai]

On Thursday, Mar 27, 2003, at 01:31 Asia/Tokyo, Chris Nandor wrote:
Is there a reason for MacJPerl when MacPerl 5.8.x is released?
I thought none but the second thought;  The built-in text editor that 
many not support multibyte characters.  But even that is moot since 
there are many text editors which can use MacPerl, some of which even 
free (I use mi when I have to type in Japanese 
, free, perl-savvy, and 
supports all major Japanese encodings including UTF-8).

I wonder how many of you have ever tried 5.8 features such as Encode 
and PerlIO in MacPerl (besides "make test", of course).  I don't even 
lauch Classic these days...

Dan the ex-user of MacOS

Re: DynaLoader and prebinding

[Dan Kogai]

pudge,

On Saturday, Mar 22, 2003, at 13:10 Asia/Tokyo, Chris Nandor wrote:
So I have this problem: Mac::Carbon takes a long time to load.

$ time perl -Iblib/arch -Iblib/lib -MMac::Carbon -e1

real0m2.923s
user0m2.570s
sys 0m0.160s
Profiling the run showed that over 80% of that time is taken by dyld, 
so I
wondered if prebinding could solve the problem.  However, perl uses 
.bundle
files for DynaLoader, and .bundle files cannot be prebound.

Drat.
Does your /var/log/system.log say something like the following?

Mar 23 04:51:05 dan-pbg4 /usr/libexec/fix_prebinding: 
/usr/local/bin/perl couldn't be prebound in the past, and probably 
can't be prebound now.
Mar 23 04:51:05 dan-pbg4 /usr/libexec/fix_prebinding: 2003-03-23 
04:51:05 +0900: prebinding for perl done.
If so, try

sudo update_prebinding -force -root /

This AT LEAST makes that system warning go away and perl launches 
faster (sometimes significantly, sometime just slightly).  At least it 
saves disk access by reducing the need to log the warnings.

You may know that Apple's Software Updates does this update_prebinding 
but without -force and without it that syslog warnings will not go 
away. Drat.

And I am not sure how much time you can save by converting .bundle to 
.dylib

man fix_prebinding
These hints are used by the dynamic loader to launch processes 
prebound,
 eliminating the need to look up dynamically linked symbols.  If 
these
 hints are out-of-date, the dynamic linker instead must lookup 
referenced
 symbols.  As a result, the application may launch from 10-30% 
slower.
10-30% seems a lot but that still does not explain the time it takes to 
load your module.  I've tested a few biggies but even such big modules 
as Encode::JP and POSIX take less than 0.1s to load on my TiBook 
(800MHz).  It seems that the size of module does not matter much.  
Maybe the number of symbols therein?

IMHO, there is a good reason why Wilfredo Sanchez chose not to prebind 
XS

http://developer.apple.com/tools/projectbuilder/Prebinding.html
Requirements for Prebinding

To work properly, libraries and executables must meet several 
important requirements:

   1. Libraries must not have overlapping preferred addresses. For 
each release of Mac OS X the Apple-supplied libraries are all prebound 
and do not have overlapping addresses. Your libraries must not overlap 
with any of your own libraries, and also must not overlap with any of 
the Apple-supplied libraries that are installed with Mac OS X. There 
is currently no way to automatically select an address for a library 
to ensure that it does not overlap the addresses of other libraries. 
Non-Apple libraries can use any address in the range 0xto 
0x3FFF. For the Mac OS X 10.0 release, all addresses above 
0x9000 are also available. To set the address of a library, pass 
either the -seg1addr flag or the -seg_addr_table flag to ld(1). All 
executables should be at the default address, 0x. The default 
address is 0x. When selecting addresses for libraries, the 
address range of the largest executable using the libraries should be 
avoided.
   2. There can be no undefined symbols. In most cases, this means 
that you must link against your dependent libraries. It also means 
that there can be no circular dependencies (cases where library A 
calls a function in library B, and a function in library B also calls 
a function in library A). Circular dependencies can be removed by 
changing the code to dynamically look up the function instead of 
directly referencing it.
   3. You cannot override symbols that are referenced in flat 
namespace images used by the dependent libraries. For example, you 
can't define your own malloc and then prebind using flat namespace 
libraries.
Simply put, it is just too darn hard to prebind all XS without address 
overlaps, especially when CPAN modules are concerned.  On the other 
hand, libperl is .dylib already so it may be able to take advantage of 
prebinding.

You should also note that launching takes much longer when perl is 
built w/ -DDEBUGGING is on.

Dan the Man with Too Many Files to Prebind

#!/usr/local/bin/perl

Re: found bug in psync

[Dan Kogai]

On Friday, Mar 7, 2003, at 03:31 Asia/Tokyo, charlie strauss wrote:
Psync has a 100% reproducible bug
it fails to correctly handle filenames with parethesis in them
example:
Documents (charles) /somedof.doc
Thanks for the report but I could not reproduce the error.

give the error
 err=-43,file=filecopy.c,line=54 at /usr/local/bin/psync line 172.
I think something else is standing in a way.  Did you check the 
permission of "Documents (charles) /somedof.doc" ? what does 'ls -l 
"Documents (charles) /somedof.doc"' say ?

Dan the Man with Too Many Modules to Check

_  Dan Kogai
  __/    CEO, DAN co. ltd.
 /__ /-+-/  2-8-14-418 Shiomi Koto-ku Tokyo 135-0052 Japan
   /--/--- mailto: [EMAIL PROTECTED] / http://www.dan.co.jp/ -
__/  /Tel:+81 3-5665-6131   Fax:+81 3-5665-6132
 GPG Key: http://www.dan.co.jp/~dankogai/dankogai.gpg.asc

Re: man psync

[Dan Kogai]

On Friday, Feb 28, 2003, at 05:52 Asia/Tokyo, Brad Schonhorst wrote:
Silly question-

After installing MacOSX::File in order to gain access to psync
I cannot seem to bring up the man page for it.  I am using mac
10.2.4.  Any suggestions or is there a way to get at the man page
somewhere else (online perhaps?)
try

perldoc psync

If your $MANPATH setting is appropriate, 'man psync' should suffice but 
perldoc is smarter at locating the document.

Dan the MacOSX::File Maintainer

Re: Psync and Perl 5.8.0.

[Dan Kogai]

On Monday, January 27, 2003, at 01:14 PM, J. Charles Holt wrote:

 Any idea what the trouble might be? Any thoughts would be 
appreciated!

[snip]

In file included from Catalog.xs:16:
../common/util.c:9:19: Files.h: No such file or directory

Do you have Developer Tool installed?  It appears that Carbon 
framamework, needed to compile MacOSX::File, is missing.

Dan the Father of MacOSX::File.

MacOSX::File updated to 0.65

[Dan Kogai]

Folks,

  I just updated MacOSX::File to 0.65.  This is mainly thanks to a bug 
report from  Guy Sabourin that addresses a minor typecast bug in 
Catalog/Catalog.xs that copies creator improperly when compiled in 
certain condition (the condition I could not duplicate; I suspect the 
compiler difference).
  Since Guy's version is definitely less evil and far portable I 
replaced the code in question with Guy's version.

On Monday, Jan 20, 2003, at 02:02 Asia/Tokyo, Guy Sabourin wrote:
(from: catalog.xs, line 77, source version 0.62 (from 
MacOSX-File-0.64)):

finderInfo[0] = sv_2mortal(newSVpv((char *)fip, 4));  /* type 
*/
    finderInfo[1] = sv_2mortal(newSVpv((char *)(fip+4), 4));  /* 
creator */   <--- Should work, but does not!
   finderInfo[2] = sv_2mortal(newSVuv(fip->fdFlags));

Because I kept getting garbage in MacOSX::File::Catalog, but 
MacOSX::File::Info would return a correct creator, I suspected some 
form of incorrect pointer calculation. I therefore tried the following 
changes:

finderInfo[0] = sv_2mortal(newSVpv((char *)&fip->fdType, 4)); 
 /* type */
finderInfo[1] = sv_2mortal(newSVpv((char *)&fip->fdCreator, 4)); 
 /* creator */
finderInfo[2] = sv_2mortal(newSVuv(fip->fdFlags));

And here is the Changes.

$Revision: 0.65 $ $Date: 2003/01/19 17:53:21 $
! common/util.c
  s/strcpy/strncpy/  I though I fixed it :)
! Catalog/Catalog.xs
  Guy Sabourin <[EMAIL PROTECTED]> has reported that an evil 
typecast
  found in the code above was preventing MacOSX::File::Catalog from
  copying creator properly.  Though I could not duplicate his claim
  on my environment (compiler difference?), his version is 
definitely
  better.
  Message-Id: <[EMAIL PROTECTED]>
  FYI, psync and other scripts that come with this package use
  MacOSX::File::Info rather than MacOSX::File:Catalog in favor of 
speed
  and memory so they are unaffected as of this release.

As described above, psync and other popular scripts REMAIN unaffected.  
Enjoy.

Dan the Man with Too Many Modules to Maintain

Re: unix or mac-style text files?

[Dan Kogai]

On Monday, Nov 25, 2002, at 01:05 Asia/Tokyo, Chris Nandor wrote:

The bottom line was that it'd be nice to have a PerlIO filter for perl
5.8.x, so that MacPerl can execute Unix and Windows text files, and 
Mac OS X
perl can execute Mac OS text files, etc.  Patches are surely welcome!  
:-)

One good question may be how to handle newlines in heretext, the only 
part that really matters because that's the only exception to the fact 
that newlines are nothing but whitespace from perl compiler's point of 
view -- oops, shebang is another.  When you feed MacPerl *.pl to MacOS 
X, should linefeeds in heretext emit \015 or \012?

I am not sure which is lazier to simply apply

# Any -> Unix
perl -i.bak -ple 's/\015\012|\015|012/\012/g' *.pl
# Any -> Mac
perl -i.bak -ple 's/\015\012|\015|012/\015/g' *.pl

or teach camel the same trick

Dan the Man with Too Many Kinds of Line Endings to Deal With

Re: psync groups?

[Dan Kogai]

On Tuesday, Nov 5, 2002, at 03:08 Asia/Tokyo, Ronald Florence wrote:

Dan,

I have installed and used your excellent psync to backup an HFS+ 
partition on MacOS 10.2.1.  It works flawlessly, using the command 
line you suggest, with one exception:

  Every file in the backup has group `unknown' instead of the group in 
the original filesystem.

Is there a way to fix this so that psync will backup the filesystem 
with the original groups?  Thanks,

psync DOES preserve group attributes whenever possible but the very 
group attribute is simply a 32 bit integer that is mapped to its name 
by NetInfo (/etc/groups in ordinary Unixen) so if the NetInfo database 
is different the group may appear in different names.

Another possibility that the groups are not preserved is that the use 
privilege when psync was run was insufficient (I suspect this is more 
likely).  Did you 'sudo'?

Dan the Maintainer MacOSX::File

[OT] That annoying yen mark! [Was: Re: [Encode] ...]

[Dan Kogai]

On Friday, Oct 18, 2002, at 22:25 Asia/Tokyo, Nicholas Clark wrote:

On Fri, Oct 18, 2002 at 10:21:07PM +0900, Dan Kogai wrote:


AFAIK, CP¥d+ should be avoided for any data exchanged in the Net so 
you
   ^
Yen sign? That should be a backslash, as in CP\d+  ?


Right.  The smart-ass Mail.app (among other *.app) does this to me when 
your input method is Japanese and '\' is typed.  I have configured 
Kotoeri (the input method) to be English-friendly --does Kana-Kanji 
conversion when and only when caps lock is set (much more convenient 
than toggling Keyboard script with command-space) but even that won't 
stop replacing slashes with yen mark.  You have to get Kotoeri out of 
picture, something you would so easily forget in apps like Mail.

[I seem to remember something about some Japanese character sets 
swapping
\ and ¥ so that the Yen sign had a 7 bit value.

As you see now '\' appears correctly because I now toggled off Kotoeri 
now.  I usually notice this on Terminal.app because the difference is 
critical but not Mail.app

Well, at least with MacOS X you can TELL THE DIFFERENCE even though it 
is sometimes annoying;  Win* won't even let you notice that and you are 
trapped in "Yen jail" :)

Dan the Man with Too Many (Script|Encoding|Charset)s to Fiddle With

Re: Parsing JIS X 0208 & Shift JIS with 5.8.0

[Dan Kogai]

On Tuesday, Oct 1, 2002, at 18:47 Asia/Tokyo, Dan Kogai wrote:
>   my $utf8 = decode('shift-jis', $string/;
 my $utf8 = decode('shift-jis', $string); # of course.

.I need to get to bed, which I have not for last couple of Earth 
rotation

Dan the Insomniac

Re: Parsing JIS X 0208 & Shift JIS with 5.8.0

[Dan Kogai]

On Tuesday, Oct 1, 2002, at 18:16 Asia/Tokyo, Robin wrote:
> Is anyone else doing/done this? Care to share notes?

Too brief a comment to grok what your point is.

If all you need is (en|de)code Shift_JIS, all you have to do is;

   use Encode qw/encode decode/;
   #...
   my $utf8 = decode('shift-jis', $string/;

just perldoc Encode && perldoc Encode::JP.

Dan the Encode Maintainter

dot files in Jaguar

[Dan Kogai]

On Sunday, Sep 29, 2002, at 00:33 Asia/Tokyo, Gero Herrmann wrote:
> Jordan Hubbard explained the decision in a posting to the Mac OS X TeX
> mailing list.
>
> http://www.esm.psu.edu/mac-tex/MacOSX-TeX-Digests/2002/MacOSX- 
> TeX_Digest_09-11-02.html

Thanks.  But why not plain-old README that comes with the OS itself?

>>   Now you have to work on your own .tcshrc to have your shell behave
>> decently.
>
> The file is still there; it just has to be activated.
>
>   echo "source /usr/share/tcsh/examples/rc" > ~/.tcshrc

I do carry my own dot files so it is not the problem for me and I  
second jhk.  The problem is that for many MacOS X Terminal is the first  
encounter to Unix shell.  And we all know how dangerous vanilla shell  
can be to novices.  It doesn't even 'alias rm rm -i'.  I would hate to  
hear "hey, Linux distro A is much user-friendlier than OS X".

I think the best solution would be to auto-create .t?cshrc when an  
account was issued, like what many other OSes when you adduser(8).   
This is both novice-safe and poweruser-happy.

Otherwise, it's people like me, not apple, who get messages like "file  
not found" ;)

Dan the Man with Too Many Questions Redirected in Vain

Jaguar, Psync and tcsh in Jaguar

[Dan Kogai]

On Saturday, Sep 28, 2002, at 14:41 Asia/Tokyo, Jeff Yana wrote:
> Hi Dan-
>
> After recently updating to Jaguar I decided it was high time to run a 
> back-up using your wonderful little Psync utility. Problem is that it 
> does not run. The Terminal returns the error "command not found." Do 
> you have any thoughts? This would not have anything thing to do with 
> Apple moving over to the GCC would it?

try

/usr/local/bin/psync

first.  If that works, add

set path = ($path /usr/local/bin)

to ~/.tcshrc

It is just do to the fact that on Jaguar Apple has removed system-wide 
tcsh initialization scripts by Sanchez, former head of Darwin Project 
(though convoluted that was one of the most elaborate initialization 
scripts I've ever seen.  Why gone, Apple?).

   Now you have to work on your own .tcshrc to have your shell behave 
decently.

Dan

psync vs. Jaguar [Was: Re: search.cpan.org: Dan Kogai]

[Dan Kogai]

On Friday, Sep 20, 2002, at 04:31 Asia/Tokyo, Erik J. Barzeski wrote:
> Hi,
>
> I upgraded Perl on Mac OS X (10.2.1 now) to 5.8.0 as per the 
> instructions at
> Apple's site.
>
> Unfortunately... This seems to have caused some trouble with psync.

Hmm...  I have numerous reports that MacOSX::File and psync are working 
fine w/ Jaguar and Perl 5.8.0 (it does on my own envoronment).

> [3:29pm iacas@Gaia:~] % psync
> dyld: perl Undefined symbols:
> _Perl_sv_2pv
> _perl_get_sv
> Trace/BPT trap
> [3:29pm iacas@Gaia:~] %
>
>
> Do you have any idea what I might do to fix this? I am grateful to you 
> for
> all your work on psync, and would like to continue using it. Have I 
> done
> something wrong here, or is psync in need of a slight tweak to work 
> with
> 5.8?

I don't know exactly how you configured perl 5.8.0 ('per the 
instructions at Apple's site' is hardly descriptive enough.  Did you do 
so in a manner that replaces /usr/bin/perl (not recommended)?  Here is 
my perl 5.8.0 config

sh Configure -Dprefix=/usr/local -DDEBUGGING -Uinstallusrbinperl -desO

The point is to preserve preinstalled perl (/usr/bin/perl) so 
-Uinstallusrbinperl is set.

Dan the Man with Too Many perls installed

Re: Problems install Text::Iconv

[Dan Kogai]

On Thursday, May 2, 2002, at 11:21 , Ward W. Vuillemot wrote:
> I am trying to get, ultimately, XML::SAX and some of its own supporting
> modules (e.g. XML::SAX::ParserFactory which needs XML::SAX::Writer which
> needs Text::Iconv).  How how the merry nymphs dance and prance on m'
> forehead.  Argh!
>
> Has anyone encountered this?  Here is the output from an install.

Naturally, you have to install iconv BEFORE Text::Iconv.

FYI, Iconv capabilities are all added in Perl 5.8 via Encode (and 
XML::SAX is already designed to use it if Encode is available) so if you 
are patient enough to wait for 5.8, Text::Iconv will no longer be a 
prereq.

Dan the Encode Maintainer

Re: MacOSX-File-0.50.tar.gz uploaded to CPAN

[Dan Kogai]

On Friday, April 26, 2002, at 06:28 , Vonleigh Simmons wrote:
> Hello,

Hi there.

>   Dan, you are the man for making psync. I just tried it to backup 
> my main drive and it works exactly as advertised. One question though, 
> how would I go about restoring a drive? Should I just boot from the 
> copy and copy back to the main drive, or is there a niftier restore 
> feature? (didn't quite understand the -r flag in the man pages).

Suppose you've backed up your drive with something like;

psync / /Volume/backup

If you are booting from the same drive, you can intuitively

psync /Volume/backup / # it won't mangle /Volue/backup like cp

Or, if you are booting from the volume you just backed up, you can

psync / /Volume/newdrive

to do so.  As for -r option, not all 'Volumes' can store all the 
necessary file metadata (such as Apple Share volumes; you'll lose file 
ownership) so when you use -r, an extra database is created and used 
when you restore.

>   In any case, thanks a bunch for making psync, awesome job. I'm 
> trying to figure out if maybe I could make a cocoa front end for it, so 
> that it would backup on a repeating basis (user defined), plus being 
> able to restore. I'd do a cron job for it, but maybe it would be better 
> to get it out to the less unix-savvy user.

For the time being I am too occupied with Perl 5.8 but when it settles I 
would like to work further on with MacOSX::File.  Thanks for your input.

FYI, MacOSX::File is now 0.64.  Use the latest one.

Dan the Man with Too Many Modules to Manage
--
_  Dan Kogai
   __/    CEO, DAN co. ltd.
  /__ /-+-/  2-8-14-418 Shiomi Koto-ku Tokyo 135-0052 Japan
/--/--- mailto: [EMAIL PROTECTED] / http://www.dan.co.jp/ -
__/  /Tel:+81 3-5665-6131   Fax:+81 3-5665-6132
  GPG Key: http://www.dan.co.jp/~dankogai/dankogai.gpg.asc

Re: Permanently add INC directory?

[Dan Kogai]

On Monday, April 22, 2002, at 11:50 , Levan, Jerry wrote:
>> Is there any way to globally add an INC directory to Perl after
>> compilation?
>>
>> I know about setenv PERLLIB5 and do that in my .cshrc.
>>
>> But it doesn't get set when I run Perl from within BBEdit or cron.
>> Is there any way to do this so it is truly global (it can just be
>> across me as the user or for all users, since I'm the only user
>> anyway, as long as that will work with things like BBEdit and cron).
>>
>> Thanks,
>>   Peter.
>
> In a pinch you could do something like:
>
>push @INC , "Pathtofile"
>
> At the top of your program, you might have to use
> A Begin block to enclose the push for "use" access
> Rather than "require" access.


More elegant solution;

use lib qw(/your/directory);

Dan the Man with Too Many perlvar manglings these days

Re: BSD::stat - and Mac OS X

[Dan Kogai]

Willam,

On Tuesday, April 16, 2002, at 04:55 , William H. Magill wrote:
> I'm not a programmer, so I may simply be mis-interpreting things.
>
> I was hunting for a way to display the "flags" found in OS X in a 
> rational
> manner. (ie not having to "get info" for every bloody file.)
> So I found your contribution to CPAN.
>
> [My goal was to write an "ls -l" equilivant which would display the 
> flags
> information as well. If you know of such a critter, that would be a 
> great
> time saver.]
>
> Under Mac OS X, the /usr/include/sys/stat.h struc looks like this below.
> Which appears to be different than the field sequence in the man page 
> for
> BSD::stat for fields 13/14/15. Am I simply interpreting things 
> incorrectly?
>
> Is Darwin/NeXT different from the BSD in this?

Though each BSD differ from one another on st_flags, important fields 
remain compatible.  I do use BSD::stat on MacOS X (in fact my main 
client machine is PowerBook G4 Ti).  So you can still rely on the value 
of stat()->flags but you may find some of the predefined constants may 
not work.  I borrowed from FreeBSD which appears to have more flags 
switches than any other.

Maybe it is not a good idea to predefine FLAGS constants there after 
all.  I will check to see if Fcntl module can be used for that purpose.

But for the time being, please give me more time than usual;  I am doing 
Encode, the largest module (in size) in the upcoming perl 5.8.

Dan the Man with Too Many Modules to Manage

--
_  Dan Kogai
   __/    CEO, DAN co. ltd.
  /__ /-+-/  2-8-14-418 Shiomi Koto-ku Tokyo 135-0052 Japan
/--/--- mailto: [EMAIL PROTECTED] / http://www.dan.co.jp/ -
__/  /Tel:+81 3-5665-6131   Fax:+81 3-5665-6132
  GPG Key: http://www.dan.co.jp/~dankogai/dankogai.gpg.asc

mod_fcgi recipe for MacOS X

[Dan Kogai]

On 2002.03.11, at 06:32, Bruce A. Burdick, Jr. wrote:
> Thanks for the great suggestion. But in this case I'm trying to 
> install a
> local working copy of a client's application that depends on FCGI.pm,
> CGI::Fast.pm, and, of course, mod_fastcgi.

Out of curiosity I have tested FastCGI myself;  I never had a chance to 
use it in details except when I installed on a FreeBSD box for one of my 
customers.  I didn't even write a script for FastCGI myself.

It turned out to be pretty easy.  Here is the recipe I gathered.

Precondition


MacOS X version: 10.1.3
Apache Version:  1.3.22 (The one that comes with 10.1.3)
Developer Kit installed (Required!)

Build:  mod_fcgi


You can use apxs so you don't have to build whole apache.

0.  get http://www.fastcgi.com/dist/mod_fastcgi-2.2.12.tar.gz
and untar the dist.  on HFS+ volume 'tar zxf' may complain
but you can happily ignore that.
1.   build with apxs
% apxs -o mod_fastcgi.so -c *.c 
when mod_fastcgi.so gets linked, cc complains like

>   /usr/bin/ld: warning unused multiple definitions of symbol _regerror
>   /usr/sbin/httpd definition of _regerror
>   /usr/lib/libSystem.dylib(regerror.o) unused definition of _regerror

but your work directory should contain mod_fastcgi.so
2.  Install the module
% sudo apxs -i -a mod_fastcgi.so

Build: FCGI.pm
--
% wget http://www.cpan.org/authors/id/SKIMO/FCGI-0.65.tar.gz
% tar zxf  FCGI-0.65.tar.gz
% cd FCGI-0.65
% perl Makefile.PL
% make
% sudo make install

Configuration
-
Since I only wanted a quick test,  I made a configuration as follows;

 
   AddHandler fastcgi-script .fcgi
 

Enjoy
-
And all you have to do is to (re)start apache.  Note that you have to 
stop then start since you have added a new DSO.
% apachectl configtest
% sudo apachectl stop
% sudo apachectl start

I have also added a simple script which just shows you queries and envs 
(anologous to /Library/WebServer/CGI-Executables/printenv but based upon 
mod_perl-safe version) after the signature

Foreword


I find mod_perl much easier to use and more versatile.  Unlike FCGI 
which demands event loops, mod_perl's Apache::Registry lets you run most 
of the "well-behaved" CGI (that is, with taint checks and 'use strict') 
completely unmodified.  mod_perl also appears faster (but I confess I 
have never stress tested FCGI).

Well, FCGI has its strength, too.  FCGI is not limited to perl but also 
for C, Phython and Ruby to name a few.

Dan the Man with Too Many Modules Everywhere

#!/usr/bin/perl

use strict;
use CGI::Fast;
use File::Basename;

my $Me = basename($0);
my ($Queries, $Envs);

while (my $q = new CGI::Fast){
 my @k = $q->param;
 for my $k ( @k ){
 my @v = $q->param($k);
 $Queries .= qq($k);
 if (@v){
 my $ev = escape_string(join("(J\(Bn", @v));
 $Queries .= qq($ev);
 }
 $Queries .= "(J\(Bn";
 }
 for my $k (sort keys %ENV){
 my $ev = escape_string($ENV{$k});
 $Envs .= qq($k);
 $ev and $Envs .= qq($ev);
 $Envs .= "(J\(Bn";
 }
 print <<"EOT";
Content-type: text/html




$Me


$Me
Queries

$Queries

Environment Variables

$Envs


EOT
}

sub escape_string{
 my $str = shift;
 my %escape = (
   '&'  => 'amp',
   '<'  => 'lt',
   '>'  => 'gt',
   '(J\(B"' => 'quot',
   );

 $str =~ s/([<>&(J\(B"])/'&' . $escape{$1} . ';'/eog;
 $str;
}
1;
__END__

how about mod_perl? [Was: Re: Fast CGI]

[Dan Kogai]

On 2002.03.10, at 21:24, Bruce A. Burdick, Jr. wrote:
> Anyone have any significant experiences with Fast CGI on OS X? Any 
> trouble
> with mod_fastcgi? Any trouble with CGI::Fast?
>
> -B...

   mod_perl works fine and comes with every single copy of MacOS X 
(Unless you choose not to install "BSD subsystems").  Just edit 
/etc/httpd/httpd.conf to load mod_perl.
   Sample diff to /etc/httpd/httpd.conf agains 
/etc/httpd/httpd.conf.prefix is right after my signature.

Dan the Camel Addict

% diff -u httpd.conf.prefix httpd.conf
--- httpd.conf.prefix   Sat Feb 17 12:33:37 2001
+++ httpd.conf  Sun Mar 10 01:27:03 2002
@@ -237,6 +237,8 @@
  LoadModule setenvif_modulelibexec/httpd/mod_setenvif.so
  #LoadModule dav_module libexec/httpd/libdav.so
  #LoadModule ssl_module libexec/httpd/libssl.so
+LoadModule perl_modulelibexec/httpd/libperl.so
+

  #  Reconstruction of the complete module list from all available modules
  #  (static and shared ones) to achieve correct module execution order.
@@ -276,6 +278,7 @@
  AddModule mod_setenvif.c
  #AddModule mod_dav.c
  #AddModule mod_ssl.c
+AddModule mod_perl.c

  #
  # ExtendedStatus controls whether Apache will generate "full" status
@@ -416,18 +419,24 @@
  # Control access to UserDir "Sites"
  # for a site where these directories are restricted to read-only.
  #
-#
-#AllowOverride FileInfo AuthConfig Limit
-#Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
-#
-#Order allow,deny
-#Allow from all
-#
-#
-#Order deny,allow
-#Deny from all
-#
-#
+
+AllowOverride FileInfo AuthConfig Limit
+Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec 
ExecCGI
+AddHandler cgi-script .cgi
+
+ PerlSendHeader On
+ PerlHandler Apache::Registry
+ AddHandler perl-script .pm
+
+
+Order allow,deny
+Allow from all
+
+
+Order deny,allow
+Deny from all
+
+

  #
  # DirectoryIndex: Name of the file or files to use as a pre-written HTML
@@ -1022,4 +1031,11 @@
  #CustomLog logs/dummy-host.example.com-access_log common
  #

-Include /private/etc/httpd/users
+#Include /private/etc/httpd/users
+
+
+PerlModule Apache::Registry
+PerlModule CGI
+PerlTaintCheck On
+PerlFreshRestart On
+

PAUSE bug leads to LWP bug

[Dan Kogai]

On 2002.03.08, at 08:28, Elaine -HFB- Ashton wrote:
> I would think it's in the filename itself since PAUSE fetches the URL 
> you
> feed it and the fetch would fail if it had a gremlin on the end. I don't
> see how it could be anywhere else but the filename.

Negative.  See

http://www.cpan.org/modules/by-authors/id/D/DA/DANKOGAI/

now and see what's going on.  I have uploaded MacOSX-File-0.64.tar.gz 
again but this time with a different browser, Netscape 6.  I DID NOT 
CHANGE THE FILENAME OF THE ORIGINATING URI.
   As for the possible cause of URL-filename inconsistency,  I can guess 
various reasons, like passing the query straight to LWP and 
basename($url) for file name.  Speaking of that, I have found something 
really interesting.
   Now I have found a (bug|undocumented feature) in LWP, too (Adding 
Gisle's address to the recipients) .

perl -MLWP::Simple -e 'print get("$ARGV[0](J\(Bn")' 
http://www.dan.co.jp/cases/

   gives the same result as

perl -MLWP::Simple -e 'print get($ARGV[0])' http://www.dan.co.jp/cases/

   that is, fetches the content, despite the fact the first one is fed 
with bogus URI.

perl -MLWP::Simple -e 'print get("$ARGV[0] ")' 
http://www.dan.co.jp/cases/
perl -MLWP::Simple -e 'print get("$ARGV[0]\t")' 
http://www.dan.co.jp/cases/

  or any whitespace will do.  I am not sure if I should call this a bug 
because this is a kind of nice.  But it is certainly undocumented and 
definitely confusing.

For MacOSX Folks, I have made MacOSX-File-0.64.tar.gz (source 
distribution) also available via

http://www.dan.co.jp/cases/macosx/MacOSX-File-0.64.tar.gz

so you don't have to wait till PAUSE is fixed.

Dan the Man with Too Many Programs to Manage

Re: PAUSE bug discovered?

[Dan Kogai]

On 2002.03.08, at 04:03, Elaine -HFB- Ashton wrote:
> This has happened only one other time that I can recall and I think that
> Randal somehow added a LF to his html file. Double check your file name
> before you upload it this time around. I don't know that this is a bug 
> but
> it's not a feature.
>
> e.

   Or it could be web browser that has caused this.
   At any rate, I consider this kind of  behavior for a CGI/mod_perl or 
any web program too goofy for a site like PAUSE (PAUSE is no Matt's 
script archive!).  I want it fixed ASAP.
   FYI I used a browser called iCAB, available only for Macs (what a 
shame it is darn best browser available to date; it is even lighter than 
Opera yet handles multilingual text correctly.  It even filters ads!).  
You can get more info on this browser via

http://www.icab.de/

   and here is its (default) Agent: header (it is customizable but I 
leave it as default) is

"Mozilla/4.5 (compatible; iCab 2.7.1; Macintosh; I; PPC)"

Dan the Man with Too Many Web Browsers

PAUSE bug discovered?

[Dan Kogai]

On 2002.03.08, at 03:04, Elaine -HFB- Ashton wrote:
> www.cpan.org updates from PAUSE hourly so if it doesn't have the latest
> version it is unlikely any of the other mirrors will either.
>
> e.

   I find it strange that MacOSX-File remains 0.61 for so long so I 
checked

http://www.cpan.org/modules/by-authors/id/D/DA/DANKOGAI/

   And found something really strange.  When you check the link under 
what appear to be MacOSX-File-0.64.tar.gz is really

http://www.cpan.org/modules/by-authors/id/D/DA/DANKOGAI/MacOSX-
File-0.64.tar.gz%0A

   See the trailing %0A !  That is LF.  I have no idea how pause wound up 
in appending LF to file name but this is obviously a bug that needs to 
be fixed.
   I may have fed an extra LF when submitting a URL (I always upload my 
file to my server at first and give that URL to PAUSE) but if the form 
check is not done at all, it would have fetched so accordingly.  But see 
this.

 > HEAD 'http://www.dan.co.jp/~dankogai/MacOSX-File-0.64.tar.gz%0A'
404 Not Found
Connection: close
Date: Thu, 07 Mar 2002 18:14:53 GMT
Server: Apache/1.3.22 (Unix) mod_perl/1.26
Content-Type: text/html; charset=iso-8859-1
Client-Date: Thu, 07 Mar 2002 18:14:53 GMT
Client-Response-Num: 1

 > HEAD 'http://www.dan.co.jp/~dankogai/MacOSX-File-0.64.tar.gz'
200 OK
Connection: close
Date: Thu, 07 Mar 2002 18:14:59 GMT
Accept-Ranges: bytes
ETag: "ba36-74c7-3c8722a6"
Server: Apache/1.3.22 (Unix) mod_perl/1.26
Content-Encoding: x-gzip
Content-Length: 29895
Content-Type: application/x-tar
Last-Modified: Thu, 07 Mar 2002 08:19:50 GMT
Client-Date: Thu, 07 Mar 2002 18:14:59 GMT
Client-Response-Num: 1

   So I am still puzzled why that happened.
   For the time being, I will release version 0.65 shortly, maybe with 
some (little) improvement.  I will leave my repository untouched so 
PAUSE maintainer can work on it.

Dan the PAUSE pauser

When your CPAN mirror appears stale

[Dan Kogai]

On 2002.03.08, at 00:55, Jonathan Baumgartner wrote:
> Dan, I tried to install via CPAN, and it told me MacOSX::File was up to 
> date without installing anything new.

   Depending on the mirror server you are using, CPAN site may not 
contain the most recent version of your software.  If such is the case 
you can override your setting temporarily via

 > o conf urllist [ url:/to.your.cpan.site/

notice '[' is necessary.

   I just checked http://www.cpan.org/ and the version there was still 
0.61.  Give it half a day or so before the latest one appears.

> How do I find out what version I have? I'm especially curious about 
> psync.

One Liner:
perl -MYour::Module -ne 'print $Your::Module::VERSION, "\n"'

via CPAN shell:
m Your::Module

Dan the Man with Too Many Modules to Manage

MacOSX-File-0.64 binary distribution is now available

[Dan Kogai]

as

http://www.dan.co.jp/cases/macosx/MacOSX-File-0.64.dmg

   Use it you don't have Developer CD.  I still recommend installation 
via CPAN, however.

Dan the Man with Too Many Modules to Maintain

MacOSX-File-0.64 released. Build on UFS volume now works

[Dan Kogai]

On 2002.03.06, at 18:55, PD Miller wrote:
> Lovely module by the looks of it, and very useful. Thank you for 
> providing a much-needed module to the Perl community. There is one 
> little caveat though, which I encountered and which you might consider 
> for future versions.
>
> I do a lot of *nix work and so use a UFS volume for most compiling. 
> When creating this UFS volume, OS9 support was not incorporated (I'm 
> not even sure that it can). Since I also do a lot of Perl work, my 
> .cpan directory is on this UFS volume.
>
> Now, if you perl -MCPAN -eshell >install MacOSX::File and your build 
> directory is on a UFS volume, the tests all fail.

The latest version fixes this problem.  I also got the same report from 
Randal the JAPH.  Sorry it took a little while.

Dan the Man with Too Many Modules to Manage

P.S.  Speaking of UFS, UFS on MacOS X is agonizingly slow.  So slow I 
can't help believing Apple has done so on purpose (or is it simple the 
result of the fact that all operations appear to be done 
synchronously).  I REALLY, REALLY WANT SOFTUPDATES on OS X!  Now OS X is 
the only BSD without it.  Should we call for petition?

Re: Creating a Bootable Backup Copy of Your System Drive Problem

[Dan Kogai]

On 2002.03.05, at 04:13, Michael Stearne wrote:
> Same results using psync -r -d  except some files are copied, but many 
> still get.
>  ...
> /Volumes/fireblaster/Backups/imacIndigo//Applications/AppleWorks 
> 6/AppleWorks 6.app/Contents/Resources/AppleWorks 
> Help/ch/gfx/chLgdBx.gif : err=-43,file=filecopy.c,line=54 at 
> /usr/local/bin/psync line 172.
>  ...

   This error implies that the destination directory is nonexistent;  For 
some reasons psync fails to create the distination directory.
   I need more detailed information to help you out.

* the EXACT command you tried
* what kind of volume (HFS+? UFS?) 
'/Volumes/fireblaster/Backups/imacIndigo' is.

Dan

Re: psync questions

[Dan Kogai]

On 2002.03.05, at 04:34, Hugh Harris wrote:
> just a PS to my last message - I know the backup won't be bootable but I
> don't mind

   Contrary to what you think, the backup WILL BE BOOTABLE so far as the 
source volume is bootable.  Just open Startup Disk via System Preference 
and wait a while and the backup disk will appear on the list of disks.

Dan

Re: psync questions

[Dan Kogai]

On 2002.03.05, at 03:07, Hugh Harris wrote:
> Intuitivey it seems that the command
>  
> sudo psync / /Volumes/backup
> would try to backup /Volumes/backup to /Volumes/backup hence creating a 
> nasty loop - why doesn't this happen?

   You can find the answer by looking at the source but I will answer 
anyway.  Before psync  begins the directory traversal, it checks the 
device ID (stat->dev) of the directory where the traversal begins.  When 
it hits anything which device ID is differenct it simply skips.
   Same mechanism do exist for most other backup commands such as tar, 
pax and rsync (usually with -x switch) but for some reason "do not 
traverse different volume" is not default.

> How do you go about doing a restore?

   There are many ways but here is the simplest;

0)  boot from /Volume/backup
1)   run psync / /Volume/original where original is the name of the 
volume you backed up

   In other words

> I would think booting from another drive then doing
>  
> sudo psync /Volumes/backup /Volumes/restore_destination_volume/
>  
> would work - what do you think?

   You've got it correct.

> Thanks,

Dan the Man with Too Many Volumes to Backup

Re: Newline independence?

[Dan Kogai]

On 2002.02.18, at 16:11, Peter N Lewis wrote:
>>   If you still care, all you have to do is a simple (and famous even) 
>> one liner to convert'em all.  Works on virtually any given platform.
>>
>>  perl -i.bak -ple 's/(\012\015|\012|\015)/\n/g' files 

First, Correction.  It would've been

perl -i.bak -ple 's/(\015\012|\012|\015)/\n/g' files 

> Yeah, that's fine - converting them is easy (heck the little tool, 
> DropText will do that easily enough).  But I'd rather just have my Perl 
> script handle whatever it gets.  I used to just write:
>
> while (<>) {
>   tr/\015\012//d;
>   ...
> }
>
> And that would work with CR or CRLF (or under unix with LF or CRLF).

   you should instead

while(<>){
chomp;
}

   Takes care of any combination of CRLF, CR and LF.

> But it doesn't work with CR or LF (only one works).  It's that sort of 
> trick I'm looking for, something simple I can add which will make Perl 
> work properly.
>
> Failing that, some sort of extension to Perl to set $/ such that it 
> handles CR or LF or CRLF would be useful, especially while we have some 
> many of both CR and LF files on Macs...


   Unfortunately $/ trick doesn't work on all combination of CRLF, CR and 
LF.  One possible solution would be as follows;

undef $/;   # enable "slurp" mode
my $content = ; # whole file now here
chomp $content; # trailing CRLF would be gone.
for my $line (split /\015\012|\015|\012/, $content){
# now process $line one by one.
}

   Of course this demands more memory since it reads file all at once.  
But with memory so cheap this approach is good enough for most cases 
(unless you want to handle httpd log, for instance.  But for that case I 
don't ask for general purpose solution).

> I guess I could always get the perl source and bash the readline 
> command, or write some sort of external command to do it, but neither 
> of those are particular good solutions.

   I think the best approach toward this is to write a module that does 
that.  IO::Handle::AnyNewline?

>Peter.
> --   
> 

Dan the Man with Too Many File Formats to Take Care

P.S.  Thank you for great products like anarchy and Interarchy.  Though 
I am not a user myself my customers have benefit a lot.

Re: Newline independence?

[Dan Kogai]

On 2002.02.18, at 14:47, Chris Devers wrote:
> On Mon, 18 Feb 2002, Peter N Lewis wrote:
>
>> Does anyone know a good trick?
>
> Would it be worth skimming over the source code for a text editor for
> ideas? Vim can handle pretty much any line endings scheme you throw at
> it, and I'd assume Emacs can too. Maybe it would help you to look over
> what those editors are doing to see if you can get any ideas there.

   If you still care, all you have to do is a simple (and famous even) 
one liner to convert'em all.  Works on virtually any given platform.

perl -i.bak -ple 's/(\012\015|\012|\015)/\n/g' files 

Dan the Man with Too Many Architectures to Handle

CPAN configuration [Was: Re: psync screw]

[Dan Kogai]

On 2002.02.16, at 04:01, Roland Silver wrote:
> Dan,
> I was following your directions for installing psync 
> , but ran into a 
> problem. The programs gzip, tar, unzip, and make were indeed in my 
> /usr/bin, but not lynx. A
>  sudo find / -name lynx -print
> revealed nothing!
>
> I have the Sept and Dec 2001 Developer Kits installed from CD, with Mac 
> OSX 10.1.2.
>
> Can you suggest where I should go from here?

It appears that your CPAN configuration is mangled.  You can reconfigure 
CPAN settings via

perl -MCPAN::FirstTime::init() -e 'CPAN::FirstTime::init'

When you reconfigure CPAN, make sure your setting looks like this;

> The CPAN module will need a few external programs to work
> properly. Please correct me, if I guess the wrong path for a program.
> Don't panic if you do not have some of them, just press ENTER for
> those.
>
> Where is your gzip program? [/usr/bin/gzip]
> Where is your tar program? [/usr/bin/tar]
> Where is your unzip program? [/usr/bin/unzip]
> Where is your make program? [/usr/bin/make]
> Warning: lynx not found in PATH
> Where is your lynx program? []
> Warning: ncftpget not found in PATH
> Where is your ncftpget program? []
> Where is your ncftp program? [/usr/bin/ncftp]
> Where is your ftp program? [/usr/bin/ftp]
> What is your favorite pager program? [/usr/bin/less]
> What is your favorite shell? [/bin/tcsh]

   See lynx is empty.  This is how CPAN tries to fetch the files needed

* use LWP if LWP is installed
* use libnet if libnet is installed
* try external commands in the order below
   lynx
   ncftpget
   ncftp
   ftp

   lynx has higher precedence.
   As you see CPAN uses libnet when installed.  The first thing you 
should do is

 >install Bundle::libnet

   So that CPAN gets independent of external commands.

Dan the Man with Too Many Modules to Install

Re: psync question

[Dan Kogai]

On 2002.02.08, at 07:08, Mark Edwards wrote:
> Okay, I've finally got psync humming along quite nicely every morning at
> 4am, backing up my whole drive.  Thanks to your help!
>
> I'm curious about one last thing.  psync, and pretty much every other
> utility I've tried, can't seem to correctly copy a locked file (locked 
> from
> the Finder).  It copies it as locked, but it changes the permissions to
> system.unknown.
>
> I'm running psync as root, by the way.  Is this just not possible to 
> do, or
> is it something you are going to add?

   Would you give me a result of 'ls -l file_in_question' and 'pgetfinfo 
file_in_question'?  "Permission to system.unknown" doesn't make sense to 
me.  Do you mean "OWNERSHIP to system.unknown?"
   One known feature of MacOS X is that it ignores chown() on AFP and 
disk images (Owner will be whoever mounted that volume).  Though this is 
understandable, this stands in a way when you want to backup system 
files.
   To overcome this feature psync comes with an option '-r'.  When this 
is specified psync makes a file called .psync.db and stores ownerships 
there.
   More pod polishing is needed, maybe

Dan

Re: psync question

[Dan Kogai]

On 2002.02.07, at 09:09, Mark Edwards wrote:
> Just checking in with you.  Does psync indeed ignore files such as:
>
> .FBCIndex
> .FBCLockFolder
>
> Should I expect it to copy everything except:
>
> .FBCIndex
> .FBCLockFolder
> ._*

   For the time being, yes.  You can customize which files to ignore via 
variables below;


my $IgnorePat =
 qr[
^/(?:
 tmp/.*
   | dev/.*
   | private/var/tmp/.*
   | private/var/vm/.*
   | private/var/run/.*
   | Temporary(J\(B Items/.*
   )
]xo;

my $Psync_DB = '.psync.db';

my %IgnoreFiles = map { $_ => 1 }
(
  $Psync_DB,
  '.DS_Store',
  '.FBCIndex',
  '.FBCLockFolder',
  '.Trashes',
  'AppleShare PDS',
  'Desktop DB',
  'Desktop DF',
  'TheFindByContentFolder',
  'TheVolumeSettingsFolder',
  );

The difference between IgnorePat and IgnoreFiles is that IgnorePat is 
tested agains full path while IgnoreFiles is tested against basename 
thereof.

You can also use pcpmac.  Or you can even write programs with 
MacOSX::File to your likings...

Dan the Man with Too Many Files To Copy.

Re: psync fails with 5.7.2

[Dan Kogai]

On 2002.02.06, at 08:52, Randal L. Schwartz wrote:
> Are you testing on UFS or HFS+?  I'm on UFS.  It also leaves behind a
> "dummy" file that is locked, that I couldn't figure out how to unlock
> using your tools (psetfinfo has very broken docs) but luckily I had
> FileBuddy-X around to fix.

   My development environment is HFS+.  However, psync and other commands 
are tested on HFS+, UFS, NFS and AFP.
   I will check to see if build environment works on UFS also.
   As for psetfinfo, yes,  pod needs some polishing.  Pod-linting is very 
welcome (But I have to tell you, too that SetFile, which functionalities 
psetfinfo based upon, doesn't even come with manpage!)
   As for the locking on UFS, it may be due the fact that Carbon's 
FSpSetLock() not only changes nodeFlag but also sets uchg of st_flags 
(it was interesting).  So you can use chflags(1) or my humble BSD::stat 
to unset the locking

Dan

Re: psync fails with 5.7.2

[Dan Kogai]

On 2002.02.06, at 05:00, Randal L. Schwartz wrote:
>> "Rick" == Rick Frankel <[EMAIL PROTECTED]> writes:
>
> Rick> Running 5.6.1 here, but I think it may be a permission problem in 
> the
> Rick> distrib directory,
> Rick> The test scripts should probably copy, etc. in /tmp instead of the
> Rick> current tree.
>
> I ran the tests as merlyn, with merlyn owning the build tree.
> What more permission is needed?

   Hmm  I don't know.  I confess I didn't bother check with perl 
5.7.2 because I consider perl 5.7.2 too unstable (for one thing, it 
didn't even build on FreeBSD 4.x.  The latest breadperl does, however).  
And I only have breadperl installed with prefix=$HOME.
   So I checked with breadperl to see if it compiles fine.  It did warn 
but all tests passed (I consider these warning too much because they all 
trap 'use 5.6.0;').
   Randal, would you also try

/usr/bin/perl Makefile.pl

   if you have preinstalled version of perl untouched?
   FYI MacOSX::File is developed under perl 5.6.1 on G4 Ti and tested 
under preinstalled 5.6.0 on G3 pismo.

Dan the Man with Too Many Generations of Camels to Shepherd

PERL_DL_NONLAZY=1 /Users/dankogai/bin/perl5.7.2 -Iblib/arch -Iblib/lib 
-e 'use Test::Harness qw(&runtests $verbose); $verbose=0; runtests 
@ARGV;' t/*.t
t/catalogv-string in use/require non-portable at 
blib/lib/MacOSX/File/Catalog.pm line 25.
t/catalogok
t/copy...v-string in use/require non-portable at 
blib/lib/MacOSX/File/Copy.pm line 22.
t/copy...ok
t/file...v-string in use/require non-portable at 
blib/lib/MacOSX/File.pm line 3.
t/file...ok
t/info...v-string in use/require non-portable at 
blib/lib/MacOSX/File/Info.pm line 23.
t/info...ok
t/spec...v-string in use/require non-portable at 
blib/lib/MacOSX/File/Spec.pm line 3.
v-string in use/require non-portable at blib/lib/MacOSX/File.pm line 3.
t/spec...ok
All tests successful.
Files=5, Tests=29,  9 wallclock secs ( 1.51 cusr +  0.36 csys =  1.87 
CPU)

Re: psync question

[Dan Kogai]

I finally got the picture!

On 2002.02.05, at 16:45, Mark Edwards wrote:
> The directory that caused problems was a standard ~/Sites/images 
> directory.
>
> Here is the file list of the source directory:
>
> -rwxr-xr-x  1 mark  staff 82 Feb 13  2001 ._apache_pb.gif
> -rwxr-xr-x  1 mark  staff 82 Feb 13  2001 ._macosxlogo.gif
> -rwxr-xr-x  1 mark  staff 82 Feb 13  2001 ._web_share.gif
> -rwxr-xr-x  1 mark  staff   2326 Feb 13  2001 apache_pb.gif
> -rwxr-xr-x  1 mark  staff   2829 Feb 13  2001 macosxlogo.gif
> -rwxr-xr-x  1 mark  staff  13370 Feb 13  2001 web_share.gif
>
> And here is the file list of the psync copy:
>
> -rwxr-xr-x  1 mark  staff   2326 Feb 13  2001 apache_pb.gif
> -rwxr-xr-x  1 mark  staff   2829 Feb 13  2001 macosxlogo.gif
> -rwxr-xr-x  1 mark  staff  13370 Feb 13  2001 web_share.gif

   Yes indeed psync DELIBERATELY ignores files that start with "._", not 
just "."  with a good reason.  It is a FEATURE.
   Files that start with '._' is RESERVED BY APPLE to store finder info 
and resource fork.  See

http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Finder/
The_Finder___Operations.html

   to get the picture.
   It appears that your '._' files exist on HFS+ volumes.  Though 
possible it is not recommended.  Try copying these files to UFS volume 
via cp command (you can create UFS file image via Disk Copy) then try 
psync again.  Your destination files will be one piece.
   With a UFS volume you can try backwards -- HFS+ to UFS copy.  In that 
case '._' files gets created for each file copied.

Dan the Man with a Mistery Solved

Re: psync question

[Dan Kogai]

On 2002.02.05, at 15:13, Mark Edwards wrote:

> That didn't work either.  See, I didn't actually install a previous 
> version.
>   I've only done a make install with .61
>
> I cleared every single file and directory that .61 installed, and I 
> re-installed and got the same problem.
>
> I'm attaching the output of the install I just did, just in case you 
> can see anything amiss there.

   I've seen your attachment and it looks all right.  Here is what I want 
you to do.

* instead of 'psync /from /to', try 'perl bin/psync /from /to' from 
MacOSX-file directory.
* send /usr/local/bin/psync as is.  I want to check to see if regexp is 
correct or gets mangled when it gets installed.

   What I don't understand is that there is no other report with the same 
symptom...  I use it over and over on my platforms with no problem and 
got the same reports from everywhere...

Dan

Re: psync question

[Dan Kogai]

On 2002.02.05, at 09:23, Mark Edwards wrote:

> I don't know why I would have an old version.  I downloaded the .61 
> source code and compiled it with
>
> perl Makefile.PL
> make
> make test
> make install
>
> I did compile version .41 earlier, but I never did make install, and I 
> deleted the directory before doing anything with .61.
>
> Any suggestions?


   I think I got it.  maybe you have to

make install UNINST=1

   to overwrite previously installed version.  If the worse gets the 
worst, you can try

rm -f `cat /Library/Perl/darwin/auto/MacOSX/File/.packlist`

   to delete the old files first then install 0.61 again.

Dan

Re: One more psync question

[Dan Kogai]

On 2002.02.05, at 07:38, Mark Edwards wrote:
> I've also noticed that some of the directory sizes do not match between 
> the psync copy and the original.
>
> This may be due to .* files not being copied, but in one case the 
> directory was actually larger in the copy than in the original, despite 
> containing fewer items (no .* files)

   This one I don't quite understand.  On HFS+ directory size Always 
appears 0 (in blocks.  Though ls -l shows something different).  Maybe 
this is due to the fact that psync always copies finfo of the directory 
as well.  Remeber on HFS+ directory is not a distinct file like UFS.  
Directory is just a catalog entry so the very size of the directory 
seems irrelevant.
   Well, I don't know what

0 drwxr-xr-x   2 dankogai dankogai   24 Feb  5 08:26 foo/
^ This is # of blocks it takes.  ^^This figure exactly mean 
myself.

Because no matter how large a directory is, the number of blocks it 
actually takes is always 0 (or it is part of the catalog).

Dan

Re: psync question

[Dan Kogai]

On 2002.02.05, at 07:16, Mark Edwards wrote:
> In my testing of it, it doesn't appear to copy files that start with . 
> (invisible files).  The directories I've copies with psync are 
> identical except they are missing anything .*

   It appears you are running an older version.  That was the bug until 
ver. 0.41 which is fixed in later version.  The latest version is 0.61 
and it backs up dot files as well.
   See

http://search.cpan.org/doc/DANKOGAI/MacOSX-File-0.61/Changes

   for details.

Dan the Man with Too Many Files to Back Up.

Re: psync

[Dan Kogai]

Ulrich,

  Hi.

On 2002.02.01, at 21:02, Ulrich auf dem Keller wrote:
> thanks for providing information on the useful psync command. I already 
> tried it successfully for backups of entire partitions with a firewire 
> drive as target directory. Since I would like to use it routinely on 
> our institute MacOS X server I tried to include it into the root 
> crontab file. Therefore I wrote a small script that only includes the 
> path to psync and the psync command itself (I am a quite UNIX newbie).

   The problem was simple after all.  See below.

> When I run the script as root from the command line being logged in as 
> administrator and using sudo everything goes fine except that the 
> finder is not able to display the icons before I logout and login again 
> (this is no problem for me since I see everything correctly when 
> browsing in the terminal). But when the cron job runs while nobody is 
> logged in some files and directories are missing in the backup. Do you 
> have any idea what is going wrong ?

   As for the icons psync does not backup Desktop (DB|DF) so simple 
desktop rebuilding will fix it (I deliberately did so but this can be 
altered very easily.  Future version may include commandline switch to 
control which files/directories to ignore).
   And now for the cron

> Here is the little script for running psnyc:
>
> #!/bin/sh -
> #
> PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin
>
> sudo psync /Volumes/Data /Volumes/d-backup

   No.  the trick is that you can't use sudo in cron.  Remember you have 
to type in your password before you 'initialize' sudo?  Anything that 
demands tty (that is, Terminal or any interactive commandline interface) 
will fail in cron.  So here is what you should do in the script.  And 
since you are already running as root via cron, there is no point 
sudoing;

#!/bin/sh

PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin ; export PATH

psync  /Volumes/Data /Volumes/d-backup > /var/tmp/psync.out 2>&1

# put all output to /var/tmp/psync.out
#end

> and here my crontab entry:
>
> 15  1  *   *   *   rootsh /etc/backuptest

This can stay as is.

Dan

Re: MacOSX-File-bindist

[Dan Kogai]

On 2002.01.31, at 07:17, James Reynolds wrote:
> On http://search.cpan.org/search?dist=MacOSX-File in the section titled 
> DEPENDENCIES you say:
>
>This module requires MacOS X. Develper kit is needed to "make 
> install".
>To get binary distribution, check MacOSX-File-bindist via CPAN.
>
> I can't find the binary anywhere.  Can you help me out.  I can't 
> install the Dev Tools on the target Mac because it is going to be used 
> in a disk image that is going to be distributed in a public lab (so 
> size and security are the reason).

   The answer is simple.  It has not been uploaded yet since MacOSX::File 
is still development phase.  But it is faily stable now so I should 
upload it soon.

Dan

Why not MacPerl X [Was: Re: Please DON'T]

[Dan Kogai]

On 2002.01.25, at 01:17, Cranz, Gregory wrote:
>> Please, pretty please, carbonize MacPerl.
>
> I shudder to think of having to differentiate between both versions when
> debugging or having a conversation on this thread.
>
> IMHO, MacPerl was a stopgap that kept the Mac in the game until we've 
> got
> OS/X i.e. Un*x to work with.  It was wonderful & I used it profusely.  
> Hell
> I still do, with my older machines, but mixing both of them in one
> environment is asking, no begging for trouble.

   I am not in need of "MacPerl X" or "Carbonized MacPerl" myself, too.  
Still I find no reason for objecting MacPerl X.  Windoze come w/ cygwin 
perl and ActivePerl.  MacPerl X for OS X can be what ActivePerl is for 
Windoze.
   Or how about ProjectBuilder support Perl for those who are in need of 
IDE?
   As Larry Wall says, there are more than one way to do it.

   Well, for me Emacs is quite enough (caveat broken VC mode of 
preinstalled version).

Dan the Man with Too Many Platforms to Support

MacOSX-File-0.50.tar.gz uploaded to CPAN

[Dan Kogai]

Folks,

   I just uploaded MacOSX-File-0.50.tar.gz to CPAN.  It now comes with 
psync, a very simple utility that does update copy.  With this, you can 
simply

sudo psync / /Volumes/backup

   to get the full backup of your boot volume while listening to iTunes 
and surfing the web and writing this very mail.  Utility like this was 
the very reason I wrote this module.

see also:  http://www.dan.co.jp/cases/macosx/backup-volume.html

Dan


PSYNC(1)   User Contributed Perl Documentation   PSYNC(1)

SYNOPSIS
 psync [-n][-q|-vI] source_items ... target_directory

DESCRIPTION
psync does an update copy.  It compares source directory
and target directory at first, then erases items that are
nonexistent on source directory and finally copies every-
thing on source directory.  Items items with the same mod-
ification date and (data fork) size remain untouched, sav-
ing time on operation.

Currently psync supports options below

-n  "Simulation mode".  It prints what it would do on
standard output but does nothing thus far.

-vn Sets verbose level.  Default verbose level is 1;  It
prints only items that are changed.  Level 2 prints
unchanged files also.  Level 3 and above are practi-
cally debugging mode.

-q  Quiet mode.  Sets verbose level to 0.

EXAMPLE
To backup everything in startup volume, all you have to
say is

  sudo psync / /Volumes/I

And the resulting backup volume is fully-bootable copy
thereof.  Note "sudo" or root privilege is necessary to
restore file ownership.

PERFORMANCE
On PowerBook G3 (pismo) with G3/400, 384MB Memory,  I
tested with "/usr/bin/time -l sudo psync / /Vol-
umes/backup".  The boot volume contains no more than
vanilla OS X 10.1.2 and Developer kit.  It had a little
over 85000 items and 1.5 GB of used space.  Here is the
result;

 1st run
 2539.48 real   121.97 user   290.78 sys
 Following run
  452.98 real47.29 user39.38 sys

Note screensaver was on with some other background pro-
grams.  I used this program happily with my PowerBook G4
while I am surfing the web and listening to iTunes at the
same time letting SETI@Home search for cosmic programmers
:)  With MacOS X, background backup is no problem

BUGS
Using this utility over network such as AFS and NFS don't
work well because of file permissions.  There are several
ways to overcome this problem but for the time being it is
not implemented.

On the other hand this utility works very well on not only
HFS+ but also UFS.  It even works with on disk images so
backup over AFS is still possible in theory by making a
huge disk image on an AFS volume.

DISCLAIMER
The author of this utility will be held no responsibility
for possible damages and losses of data and/or files
caused by the use thereof.  Use me at your own risk.

AUTHOR
Dan Kogai <[EMAIL PROTECTED]>

SEE ALSO
the 1 entry in the pcpmac manpage

hfstar http://www.geocities.com/paulotex/tar/

hfspax http://homepage.mac.com/howardoakley/

"The Finder and File Operations"

http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Find
er/The_Finder___Oper-
        ations.html

COPYRIGHT
Copyright 2002 Dan Kogai <[EMAIL PROTECTED]>

This library is free software; you can redistribute it
and/or modify it under the same terms as Perl itself.

Re: Namespace [Was: Re: MacOSX::File]

[Dan Kogai]

On 2002.01.15, at 02:05, Chris Devers wrote:
>>> Yes, I agree it is confusing.  I am not crazy about MacOSX,
>>> but can think of nothing better, so I am not objecting.
>>
>> I have a feeling that "MacOSX" is not future-proofed.
>
> That's true, but it might work in the same way that "Win32" does. There,
> of course, is no Windows 32 product, but rather a family of them that 
> can
> be described as Win32. Mac OS X is clearly a big break with what 
> preceded
> it, and presumably Mac OS XI (or whatever it will be) will evolve from
> what we have now, rather than be another fundamental break. For lack 
> of a
> better generic name for this new family of Mac systems, MacOSX might 
> have
> to do -- though I'd be interested in better suggestions. Aqua? Darwin?

   FYI Here is the reason why I picked MacOSX:: RELUCTANTLY.  Mac:: 
should work on both world but mine does not.  Aqua:: is the Name of UI 
so it should belong to modules that does things like Tk:: or Qt::.
   The biggest contender was Darwin:: but BSD world of MacOS X is the 
prime example that's wrong.  If Darwin:: were appropriate, native /bin/ 
commands would have treated resource fork like MacOS. Oh well

Dan the Man with Too Many Acronyms to Grok

Re: installscript='/usr/bin' !? [Was: Re: HFS+ and directory layout]

[Dan Kogai]

On 2002.01.14, at 18:39, Ken Williams wrote:
> As far as I can tell (which isn't very far, since the Config.pm 
> documentation is rather terse), /usr/bin is the correct value.  I just 
> checked a couple other perl installations (5.6.0 and 5.005_03, both on 
> Linux) and they both have 'installscript' set to /usr/bin.

   That's one of the reasons why I choose BSD over Linux (To be more 
exact, most of Linux distributions especially Redhat).  They use /usr/* 
too casually.
   Well, here I am not talking about correctness.  I just hate to see 
beginners clobbering files.  Consider the general public of Mac users.  
Now that MacOS X is default boot OS even for a lamp shade called iMac,  
we should make perl layouts more goof-proof.

> Try poking around - can you find any perl installations that have 
> 'installscript' set to /usr/local/bin , as you claim it should be?  A 
> quick way to check is with the command 'perl -V:installscript' at the 
> command line.

A lot.  Most post-installed perl built w/ 'sh Configure -des' use 
/usr/local/bin as default.  (Also note without hints file Configure's 
$prefix is /usr/local by default).  As for pre-installed, perl,  Here is 
an example of FreeBSD.

/usr/libdata/perl/5.00503/Config.pm
> installarchlib='/usr/libdata/perl/5.00503/mach'
> installprivlib='/usr/libdata/perl/5.00503'
> installbin='/usr/local/bin'
> installman1dir='/usr/local/man/man1'
> installman3dir='/usr/local/lib/perl5/5.00503/man/man3'
> installscript='/usr/local/bin'
> installsitearch='/usr/local/lib/perl5/site_perl/5.005/i386-freebsd'
> installsitelib='/usr/local/lib/perl5/site_perl/5.005'
> installusrbinperl='undef'

   Though perl itself is on /usr/bin, FreeBSD carefully layouts directory 
so that anything post-intalled direct to /usr/local.  And here is 
NetBSD.  Though perl is not pre-installed,  It's avaiable via package.  
Note prefix is /usr/pkg instead of /usr/local

> installarchlib='/usr/pkg/lib/perl5/5.6.0/powerpc-netbsd'
> installprivlib='/usr/pkg/lib/perl5/5.6.0'
> installbin='/usr/pkg/bin'
> installman1dir='/usr/pkg/man/man1'
> installman3dir='/usr/pkg/man/man3'
> installprefix='/usr/pkg'
> installprefixexp='/usr/pkg'
> installscript='/usr/pkg/bin'
> installsitearch='/usr/pkg/lib/perl5/site_perl/5.6.0/powerpc-netbsd'
> installsitebin='/usr/pkg/bin'
> installsitelib='/usr/pkg/lib/perl5/site_perl/5.6.0'
> installstyle='lib/perl5'
> installusrbinperl='undef'
> installvendorarch=''
> installvendorbin=''
> installvendorlib=''

   The point is clear.  Any pre-installed (or package-distributed) perl 
that come with any BSD except MacOS X use different directory for 
post-installed files.

   Isn't Darwin supposed to be a family member of BSD?

Dan the Man with Too Many Directory Layouts to Poke Around.

Re: Namespace [Was: Re: MacOSX::File]

[Dan Kogai]

Chris,

   Sorry for not responding.

On 2002.01.11, at 08:37, Chris Nandor wrote:
>>   Anyway, since then my policy to upload a module is as follow;
>>
>> 0)  Make sure it does not exist yet.
>> 1)  Upload and see what happens.
>
> Well, I am a member of the [EMAIL PROTECTED] cabal; the general practice
> is that if something is OK, we don't necessarily respond.  If no one
> responds after a week or so, you're probably fine.  But that doesn't
> mean you shouldn't ask first.  I don't necessarily think that your name
> is wrong, but I do think you should post to [EMAIL PROTECTED] first for
> such things as new top-level namespaces.  Maybe Mac::X would be better,
> I dunno.  That's why it is discussed first.  :)

   Okay, I will.  I heareby request namespace

MacOSX

   for the use by modules that are platform-specific to MacOS X.

   As for the replies (or lack there of) from [EMAIL PROTECTED], 0 reply 
for OK is pretty much like Unix commands.  But for administrative this 
is terribly wrong.  Simple autorespond like that of CPAN would be 
welcome.
   As for the namespace Mac::X, I object because this is confusing with X 
window.

> My problem is that I think this module should have the same interface as
> Mac::Files and should be called Mac::Files and then programmers on both
> platforms can "use Mac::Files" and just have it work.

   Mine does not have the same interface.  That's why I picked the 
different name space to begin with.  After XS (therefore C compiler) is 
imperative for make install MacOSX::File (though binary distribution is 
considered when it gets stable) something you can't expect of MacOS 9 
and below.
   Oh, that reminds me.  Is there a canonical way to upload BINARY 
version of the module?  I can make it so that Makefile.PL works like an 
installer rather than Makefile generator but is it the way?

> Well, OK, maybe not.  But I do want *A* module called "Mac::Files" on
> Mac OS X that has the same interface as Mac::Files on Mac OS, though,
> and what I don't want is for there to be confusion in the long run as to
> what these modules should and shouldn't do ...

   It would be nice, too but that requires more than my share of work.  
Resorting to reinventing a wheel is a pain enough.

> What I really should do is just port the Mac:: modules, but I don't have
> the time to do that work.  :/

   Yes, that's always the problem.  As for MacOSX::File, I was too lazy 
to use Finder to backup a hundred of thousand of files (vanilla MacOS X 
with Developer Kit well exceeds 100,000 files).  I was too impatient to 
wait for someone come of a module like this.  And I was too hubristic to 
wait for the verdict of [EMAIL PROTECTED]
   What other virtues do I need :)

Dan the Man with Too Many Namespaces to Browse

installscript='/usr/bin' !? [Was: Re: HFS+ and directory layout]

[Dan Kogai]

On 2002.01.09, at 09:02, Wilfredo Sánchez wrote:
>   Perl built into the system uses /usr/bin as installbin.  This is the 
> correct setting; the system perl does not belong in /usr/local/bin.  If 
> LWP uses the wrong install path, there is nothing I can do about that, 
> since I don't touch LWP.  The same is true for the rest of the 
> iceberg.  You should complain to the LWP maintainers.  And maybe 
> mention that HEAD may be a poor naming choice for a command that 
> regularly gets put onto a Unix system.

No.  It is not LWP's fault.  See this.  I just found out that default 
installscript is /usr/bin, not /usr/local/bin.

/System/Library/Perl/darwin/Config.pm (The one that comes with the 
system)
> installarchlib='/System/Library/Perl/darwin'
> installprivlib='/System/Library/Perl'
> installbin='/usr/bin'
> installman1dir='/usr/share/man/man1'
> installman3dir='/usr/share/man/man3'
> installprefix='/usr'
> installprefixexp='/usr'
> installscript='/usr/bin'
> installsitearch='/Library/Perl/darwin'
> installsitebin='/usr/local/bin'
> installsitelib='/Library/Perl'
> installstyle='lib/perl5'
> installusrbinperl='undef'
> installvendorarch='/Network/Library/Perl/darwin'
> installvendorbin='/usr/local/bin'
> installvendorlib='/Network/Library/Perl'

   LWP just uses installscript via MakeMaker.  So does many that use 
ExtUtils::MakeMaker.
   As for installperlbin directory, I think /usr/bin/perl is right SO 
LONG AS IT IS PREINSTALLED or is the part of the system.  It should not 
be confused with the versions that are later installed by users later 
on.  Take FreeBSD.  FreeBSD COMES with /usr/bin/perl but the default 
hints file uses /usr/local/bin/perl (Also true if you used ports to 
install one).
   With all due respect the person who made Darwin possible,  I have to 
say it is you, not LWP or others, who is off the de-facto standard of 
perl community and it is your hints file that needs to be fixed.

Dan the Man with Too Many hints Files to Tweak

What causes loginwindow.app to start Startup Assistant?

[Dan Kogai]

Hi.

   My MacOSX::File is near completion.  Now MacOSX::File::Copy copies 
files w/ Unicode names without a hitch.  It is even slightly faster than 
MoreFile-based routine thanks to more elaborate copy buffer mechanism.  
And most of all, it successfully restored root volume! -- well, almost.
   I wrote a script called pcpmac, which does what CpMac do but with more 
care like avoiding cross-device traversal (so pcpmac -R /* 
/Volumes/backup will not clobber).  It successfully copied everything on 
root volume.
   Then I switched startup volume to backup disk.  MacOSX boots smoothly 
and... Startup Assistant appears.  You can ssh to the machine with the 
same account and same key, every file is there.  It's just Startup 
Assistant;  Until you create a new account w/ that, it won't get me to 
Finder.
   The backup volume right after the copied is in the state that was not 
shut down.  Is that the reason why?  but if so, how loginwindow.app 
tells if Startup Assistant needs to be run?  Is there anyone who nows 
about it?  Fred?

Dan the Man with Too Many Files to Browse

MacOSX-File-0.30.tar.gz uploaded to CPAN

[Dan Kogai]

On 2002.01.08, at 03:17, Dan Kogai wrote:
>   I just uploaded a module called MacOSX::File, which allows you to 
> write programs like the ones on /Developer/Tools.  You can now copy() 
> with resource fork and finder info, gets and sets finder flags, etc.  
> Hope you guys like it.  Any comments are welcome.

   I just uploaded ver.0.30 to CPAN.  There are many enhancements and 
bugfixes, especially possible memory leaks of MacOSX::File::Info.  If 
you are already using it, be sure to upgrade it.
   It also comes with pgetfinfo and psetfinfo, which names I think are 
self-explanatory.
   In a course of writing these modules I found a bug which is left to be 
fixed.  Files w/ Unicode names don't copy well.  This is due to the fact 
that MoreFiles, a library from Apple, supports only FSSpec-based 
operations while FSRef-based, FSSpec-free operation is required to fully 
support Unicode names.
   To achieve that I have to reimplement (some parts of) MoreFiles but it 
won't be so easy.  So I decided to release preliminary version since 
0.10 had a fatal bug of possible memory leaks

Dan the Man with Too Many APIs to refer to

Re: MacOSX::File uploaded to CPAN

[Dan Kogai]

Fred,

on 02.1.9 9:12 AM, Wilfredo Sánchez at [EMAIL PROTECTED] wrote:
> Have you considered adding this functionality into existing File I/O
> code (possibly with some new options) instead of adding whole new API?

Do you mean that I modify File::Copy?  That's a possibility but as I
answered in MacOSX::File::Copy vs. File::Coply, I believe File::Copy should
behave like /bin/cp (actually, copy() does cp -p because it copies mtime and
atime) while MacOSX::File::Copy behaves like /Developer/Tools/CpMac.  No one
knows if someone wants to explicitly copy("._file", "elsewhere/._file")

Other modules in question might BSD::stat, yet another module by me that
works like CORE::stat and File::stat combined with BSD-specific fields.
That one works perfectly fine on MacOSX as well (Not to mention FreeBSD and
NetBSD.  I'm yet to test that on OpenBSD but I believe it works).  Darwin is
surprisingly BSD maybe except for directory layouts.

Dan the PM Writer

File::Copy vs. MacOSX::File::Copy [Was: Re: MacOSX::File uploadedto CPAN]

[Dan Kogai]

Now let me answer the 2nd question of Chris

> 2. Did you look at the modules in MacPerl that do the same thing, with
> an eye toward compatability of interfaces?

  Yes I did and I did check File::Copy myself as well.  As a matter of fact
File::Copy appears to be MacPerl-compliant already.  In a course of writing
MacOSX::File, 95% of the time is spent on research and just 1% is spent on
actual coding (Don't you think this retio, research vs. coding is getting
worse as time goes by?)

on 02.1.9 8:44 AM, Ken Williams at [EMAIL PROTECTED] wrote:
> Also, File::Copy should copy files correctly on MacOS (X and otherwise),
> though I'm not sure whether it currently does so.  Do you know the
> situation?

  The fact remains that /bin and /usr/bin ignores Carbon world.
  My understanding is that Darwin does not have to care MacOS world; it is
left to Carbon that does.
  Therefore I belive File::Copy should do what /bin/cp does while mine does
what /Developer/Tools/CpMac does.
  IMHO, a module like this should have been done by Apple...

Dan the PM Writer

Namespace [Was: Re: MacOSX::File]

[Dan Kogai]

Hi Chris.  Long time no see.

on 02.1.9 7:46 AM, Chris Nandor at [EMAIL PROTECTED] wrote:
> Hi Dan.  Two comments:

Okay let me answer one by one.

> 1. Did you ask [EMAIL PROTECTED] about the namespace?  I am not sure
> MacOSX is a good top-level namespace.

  Maybe I should have and I did think over this issue.  But I can tell you
what happened when I did ask for a namespace to [EMAIL PROTECTED] before.
  Back then when there was no 5.6 (and not even 5.005) I made a module
called Jcode, which allows you to handle varios Japanese charset
(en|de)coding.  The name came from jcode.pl, a (very, very) popular package
that existed before Perl5.  Since this 'taints' top-level module namespace I
did RFC in [EMAIL PROTECTED] and I got no response for a long time.  Since
that namespace was empty I did upload it and now Jcode is one of the most
widely-used perl module in Japan (it's now a part of FreeBSD ports and many
Linux packages).  When it comes this far even I cannot change the situation.
  Anyway, since then my policy to upload a module is as follow;

0)  Make sure it does not exist yet.
1)  Upload and see what happens.

  So far so good.  But of course, I am open to opinions.  If enough number
of you (well, even I am not sure how many would be enough.  Say if my
mailbox gets flooded with complaints) don't like it I am happy to change
that.
  As for the toplevel 'MacOSX',  I first considered 'Darwin' but Dawin's own
/bin/cp and /bin/mv ignore Resource fork.  Then I considered 'Carbon' but
What actually my module does is to bridge both worlds.  So I picked MacOSX,
the name that contains both worlds.

Dan the PM Writer

Re: HFS+ and directory layout

[Dan Kogai]

on 02.1.8 6:12 PM, Ken Williams at [EMAIL PROTECTED] wrote:
>> * perl itself requires UFS to compile because of this
> 
> No it doesn't - see the archives of this list for directions for
> compiling on HFS+.  It's pretty easy.

  When I say easy, it has to be as easy as

../Configure -des
make test
make install

  is it *that* easy?

>> installbindir and installscriptdir should've been /usr/local/bin, not
>> /usr/bin.
> 
> Probably so, but shouldn't LWP be using 'installsitebin' instead of
> 'installbin' anyway?  Seems like there's joint blame here.

  I partly agree with that.  But LWP is just tip of the iceburg.  Consider
an average user.  I think they would hit nothing but return keys when
configuring CPAN.pm (except for download site selection, of course).  The
layout should be set so that it keeps from "rogue" modules form clobbering
the original system.

Dan the Man with Too Many Layouts to Deal with

HFS+ and directory layout

[Dan Kogai]

On Tuesday, December 25, 2001, at 03:25 AM, [EMAIL PROTECTED] wrote:
 > The second part was changing every occurrence of
 > 'parrot' to 'test_prog' in every Test.pm file
 > that is part of the test suites. This is what I
 > was missing. Now my Parrot 0.0.3 installation works.

Yow, that's not fun.  The parrot distribution should be corrected so
that it can compile more easily on platforms like this.

Maybe.  this case-preserving, yet case-insensitive nature of HFS(+) 
sometimes bites you when you are used to ffs and its variants (including 
UFS).

* perl itself requires UFS to compile because of this
* HEAD command of LWP command clobbers /usr/bin/head when you blindly 
install LWP via CPAN

The first one comes with an easy solution.  You simply make a UFS disk 
image and use it when you compile.

* Second one is more of the problem of how you configure Perl 
installation.  I consider standard "layout" for Perl on MacOS X too 
dangerous (do you hear me, Sanchez?)

installbindir and installscriptdir should've been /usr/local/bin, not 
/usr/bin.

For the time being I replace the layout of perl-related directory like 
FreeBSD convention, with "i368-freebsd" replaced with "darwin".  But I 
would appreciate if the standard hint file is updated...

Dan the Man with Too Many Camels to Breed on too Many Platforms

MacOSX::File uploaded to CPAN

[Dan Kogai]

Hi all,

   My name is Dan Kogai and this is my first time to drop a message 
here -- maybe with a good reason.
   I just uploaded a module called MacOSX::File, which allows you to 
write programs like the ones on /Developer/Tools.  You can now copy() 
with resource fork and finder info, gets and sets finder flags, etc.  
Hope you guys like it.  Any comments are welcome.

Yours,

Dan the JAPHOMOX
--
_  Dan Kogai
   __/    CEO, DAN co. ltd.
  /__ /-+-/  2-8-14-418 Shiomi Koto-ku Tokyo 135-0052 Japan
/--/--- mailto: [EMAIL PROTECTED] / http://www.dan.co.jp/ -
__/  /Tel:+81 3-5665-6131   Fax:+81 3-5665-6132
  PGP Key: http://www.dan.co.jp/$B!1(Bdankogai/dankogai.pgp.asc