This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: 1.5.x goes current on 2003-08-23?
Gerrit P. Haase wrote:
Hallo Nicholas,
[SNIP]
Perl-5.8 is not working at all on WinME and, despite my best efforts, I
am unable to debug the problem because the "race" condition happens
before the dubugger can hook. As Jason points out in the release notes,
even after being rebased, Python cannot pass any of the threads or
^^^^^^ Python also cannot be built with
Cygwin 1.5.1?
No, I *was* referring to Python-2.2.x, please see the release notes for
what tests failed on which platform.
<flame>
Why not upgrading to W2K or XP?
You can get W2K really cheap at second hand shops;)
Last time I was at microsfot.com I saw that they don't support
Internet Explorer 5 and 5.5 any longer. That means that the support
for Win98/ME will also be dropped soon as it already happens now for
Win95 (you cannot install IE6 on W95). I cannot believe that there
are some users out there who still work with their first, ten years
old, Pentium I, 90Mhz box which cannot run W2K because their 4 GB
harddisk is too small and they cannot upgrade the hardware because the
BIOS is too old to recognize some hardisk larger than 4 GB and are
really happy that they could install Win98 because it gives you the
look and feel of a real system.
</flame>
<flame>
Thank you for informing about something I'm already aware of, but I do
not feel like upgrading to XP (yet). Frankly, I shouldn't have to! If
anything, I'd rather *downgrade* to Windows98se. To me there are
NT'isms which are just a big PITA. My notebook won't work with Win2000,
so I'm forced to go to XP if I upgrade. Plus, I don't care *at all* for
all that colorful shit in XP. It looks like that stuff is part of the
new UI, so the prospects of getting rid of that crap looks slim. I
could be wrong, because I haven't bothered to even investigate it. As
for IE, well I could care less, since as you can tell from my X-Mailer,
I use Netscape/Mozilla. Anyhow, the point of the matter is:
Perl is required for many operations, and (as I'm sure Chuck will agree)
having to rebase a *critical* core application *just* to get it work is
unacceptable. The question is: What has changed in perl to make it so
problematic? No offense to Jason, but rebase is really just "papering"
over a much bigger infrastructure problem which isn't going away. The
problem is that "rebase all" only takes into account the dll's installed
by the installer. It certainly doesn't take into account dll's which
aren't named ".dll" (like in Ruby which leaves them named *.so). It
also won't take into account user-installed dlls or perl modules. I've
managed to work around this on my Win2k machine by modifying rebase all
to use `locate` and to run rebase on any ".so"'s it finds in the Ruby
dir. I don't have a solution, but I think it is something which needs
to be kept in mind when talking about these "issues" which are starting
to become more and more prevelant. Another thing to consider is: Why
doesn't UWIN experience the same problem? IIRC, they use a system
driver to interface with the windows kernel and to manage memory. Maybe
the solution requires a more lowlevel approach (leveraging the
interfaces provided by the ddk), rather then trying to use conventional
means? It might even provide greater performance if could bypass some
of the upper layers of windows API.
I know you don't care about the Windows ME users, but the fact of the
matter is that the new perl makes Cygwin almost useless as a development
tool on WinME since it breaks autoconf/libtool/automake to name a few.
Soon it may be said that: Cygwin will not work on WinCE and WinME :-(.
If my remarks seem petulant, Good! Don't tell me to read the f*&king
FAQ or to search the archives [which use that useless htdig engine]!
And I'm sick and tired of hearing that cliche "Use the source, Luke", so
don't even go there... Sorry if this offends anyone, but all's fair
between the the "flame" delimiters...
</flame>
Also, for 5.8.1, can you turn back on MakeMaker's bzipping of manpages,
like you had during the 5.8.0RC's? You might also considier targeting
/usr/share/man, as that is what we are hoping to transition to...
1.
IIRC, I compressed the manpages manually, but if there is a feature in
perl that allows to do this automagically, I can turn it on.
I might be confused, but I swear you had flipped it on for 5.8.0-RC2.
Maybe I'm thinking about my linux-from-scratch box...
2.
I thought we allow /usr/man and /usr/share/man to coexist?
Why not transition now, now is as good a time as any...
And:
$ ( cd /usr/man ; du -hs )
9.9M .
$ ( cd /usr/man ; df -h . )
Filesystem Size Used Avail Use% Mounted on
H: 60G 29G 31G 49% /
And: Hardisks are really cheap, 120GB -> $100.
And if that all doesn't help:
$ (cd /usr/man ; find . -name "*.3pm" | xargs bzip2 -9 )
At least for the perl modules manpages it is easy to maintain this
manually.
That's not the point, you assume that I have a desktop, which is not
true in one case for me. Laptop hard drives were and still are
prohibitively expensive and their controllers don't always allow for
greater capacities. When making an application, would you use a long
double when a char is all you need? Little things add up, and I think
our goal should be to save space when possible without sacrificing
performance. Reducing the size of the install base, even by 10-20mb is
a good thing. Otherwise, why do we even bother stripping binaries?
Cheers,
Nicholas
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/