* On Thu, Aug 07, 2003 at 08:42:57PM -0700, Andrew DeFaria <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
[You weren't responding to Brian message, but mine.]
> >>It has already been acknowledged several times over that it is not a
> >>problem of Cygwin's rather a problem of Windows.
> >I think we all agree to that. But unfortunatelly, so far, only Cygwin
> >seems affected by that problem.
>
> Funny I don't see the problem. (Anybody else?)
May be I was mistaken and I was thinhing to another problem, but I'm
definitively not the only person who have notice a problem when running
cygwin.
Check the threads around:
http://www.cygwin.com/ml/cygwin/2003-03/threads.html#01510
(about fork and ressources unavailable and jamming cygwin in 10 minutes)
Why are you playing dumb and denying some of us see the problem only
with cygwin ?
BTW, I respond to a remark from Christopher. Yes, probably other
programs are affected by this bug from Windows (/some of its functions).
But I haven't noticed any clear indication in this direction.
However I have no doubt there is a problem the 100th time I run my
bash-wrapper (that launches gVim), or when I try to compile GNU program
like mutt -- I need to reboot three times and delete lines already
executed if I want to have mutt-1.5 with some specific patches.
So far, cygwin is the ultimate "developer" for this bug.
> >I guess cygwin is using a library not always correctly implemented.
> >"Isn't there any workaround cygwin could use ? " is a typical question
> >for many of us.
> Your asking for workarounds to another party's code. Personally I would
> rather Cygwin folks focus more on functionality and genuine Cygwin
> problems than fixing somebody else's problem.
I'm asking a workaround to another party code used by cygwin. If I know
that a particular function (from a third) is buggy/non portable, I won't
use it in my code, or at least, I'll try to be sure I use it under the
best conditions.
Unfortunatelly, it seems nobody knows which third party function is
buggy in that particular case.
> >>What else do you want?
> >Personnally, I hope, as the question will be raised again and again,
> >that an expertise will emerge. Just knowing why there is a problem
> >will be a big step ahead -- ie: which library/service pack/... is faulty.
>
> And what are you doing to help identify the problem (seeing as YOU are
> seeing the problem, YOU have the code and others have no clue what you
> are doing exactly that might even cause your problem)?
I'm doing approximatelly:
tar xvf mutt-1.5.1.tar.gz | gzip -cd -
cd mutt-1.5.1
./configure
make
But what will be more interresting is: what is installed on the
system/how the system was installed. Because if some people are not
seeing the problem, it means THERE IS a solution.
> >This time, someone told us about a freeware that collects "forgotten"
> >memory.
> Who "forgot" the memory? Right Windows - not Cygwin.
Did I said the contrary ?
I can also play dumb: "do you call buggy functions in your code ?"
> Is THAT the memory intensive process that you are running every 5
> minutes?!? Again, others do not have the problems that you have. I run
> Cygwin processes on Windows 2000 Servers and they stay up for months
> (Unfortunately sometimes one still needs to reboot servers for service
> packs, security fixes, etc).
I'm not Brian. My intentive process is named bash, and I don't run it
every 5 minutes.
> >BTW, if this program is an effective workaround, I think this will
> >merit a topic in the FAQ.
> You speak as if everybody is experiencing this problem - we aren't!
If ten people are experiencing the problem, it worths fix it. Because
what the ten people will first think is: "damn! cygwin is buggy and
cannnot fork anymore". You and I know it's untrue. The unfortunate new
user of Cygwin won't.
> >Could we say that cygwin relies on a faulty library developped by
> >Microsoft? And that nobody has identified the faulty library?
> You could - but that would be a guess. And it is not Cygwin developers
> responsibility to figure out which library that is.
We don't feel the same. When I program a() that uses b(). If b() is
buggy under certain condition, i usually try to find/program b'() that
will ensure that my a() will always work as expected. That's _my_
responsability to use 3rd party code/library/API that works correclty.
May be there is a b'() in that case, may be not. I don't know yet. In a
month or two, I'll try to remember how gdb works and check this out --
I'll probably need assitance from people not having the problem as I'm
not able to compile big program.
By the mean, time I have some open-source stuff I've developped to fix
before unhappy users ask for refund.
And by an hour or two, i'll check if RAMpage is of any help.
> With this, and all other open source software, I suggest that if you are
> unhappy with the product then return it and demand a fully refund :-) !
> Good luck!
--
Luc Hermitte
--
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/
