Hi Daniel,
[...]
Well, beside the fact that you don't provide a patch to restore the
original source archive. This is the main (?) reason to provide the
patch, it is there to get back the official sources.
Grr @!%$, forgot to put it into the source archive again :) Fixed.
The original source
Hi Volker,
I got my source archive from a server in France, but I just noticed,
that the author's original site is up again:
http://knackered.knackered.org/angus/psutils/
Here you can download the source, and it does *not* contain the
Makefile. You probably have the Debian patched version.
Another cleanup patch. The remaining user of next_dialog, do_fromcwd,
requires slightly more invasive refactoring, hence is not included with
these changes.
2003-07-25 Max Bowsher [EMAIL PROTECTED]
Based on a patch by Gary R. Van Sickle.
* download.cc (do_download_thread): Return int.
Max Bowsher wrote:
Robert Collins wrote:
On Mon, 2003-07-28 at 04:20, Max Bowsher wrote:
We seem to have consensus that this error condition cannot occur,
therefore
no complex retry loop is required.
OK to commit now?
Not as it was. Just remove the check and make the dang thing tidy...
Robert Collins wrote:
On Mon, 2003-07-28 at 19:46, Max Bowsher wrote:
Another cleanup patch. The remaining user of next_dialog, do_fromcwd,
requires slightly more invasive refactoring, hence is not included with
these changes.
I think this is the wrong way to solve both these issues.
I'd
On Mon, 2003-07-28 at 20:07, Max Bowsher wrote:
I don't think that the fact that a big cleanup is possible should prevent a
small cleanup from being done.
I agree. But as the larger will involve reversing this specific small
cleanup. Secondly creating a couple of classes with a static member
I just found this, thought it might be fun to package
http://cronus.comp.utas.edu.au/~thsutton/computing/wtf.html
and add the cygwin specific acronyms :)
http://cygwin.com/acronyms/
snip from=the man page
wtf - translates acronyms and filename suffixes for you.
The wtf program looks-up the
On Mon, 28 Jul 2003, Morrison, John wrote:
I just found this, thought it might be fun to package
http://cronus.comp.utas.edu.au/~thsutton/computing/wtf.html
and add the cygwin specific acronyms :)
http://cygwin.com/acronyms/
snip from=the man page
wtf - translates acronyms and filename
Igor Pechtchanski wrote:
On Mon, 28 Jul 2003, Morrison, John wrote:
I just found this, thought it might be fun to package
http://cronus.comp.utas.edu.au/~thsutton/computing/wtf.html
and add the cygwin specific acronyms :)
http://cygwin.com/acronyms/
snip from=the man page
wtf -
Robert Collins wrote:
On Mon, 2003-07-28 at 20:07, Max Bowsher wrote:
I don't think that the fact that a big cleanup is possible should prevent
a
small cleanup from being done.
I agree. But as the larger will involve reversing this specific small
cleanup. Secondly creating a couple of
On Tue, 2003-07-29 at 02:13, Max Bowsher wrote:
If we do add a class, it should probably be a thread class from which all of
our threaded tasks can derive. Regardless, I don't see that any further
cleanup will reverse these changes. I can see how it may involve changing
the same lines to a
Robert Collins wrote:
On Tue, 2003-07-29 at 02:13, Max Bowsher wrote:
If we do add a class, it should probably be a thread class from which all
of
our threaded tasks can derive. Regardless, I don't see that any further
cleanup will reverse these changes. I can see how it may involve changing
Gary,
If I understand the Microsoft Docs, this is only necessary if a WndProc will
receive SendMessages from other threads in the same app. None of our
secondary threads call SendMessage - are you just adding it on a better
safe than sorry basis, or is there something I've overlooked?
Max.
As per John Morrison's suggestion, I would like to contribute and maintain
wtf (http://cronus.comp.utas.edu.au/~thsutton/computing/wtf.html).
wtf(6) is a utility provided by some UNIX and UNIX-like systems including
Slackware Linux and NetBSD. It translates acronyms and filename suffixes
by
Robert Collins wrote:
On Tue, 2003-07-29 at 02:13, Max Bowsher wrote:
If we do add a class, it should probably be a thread class from which all
of
our threaded tasks can derive. Regardless, I don't see that any further
cleanup will reverse these changes. I can see how it may involve
On Mon, 28 Jul 2003, Gary R. Van Sickle wrote:
Robert Collins wrote:
On Tue, 2003-07-29 at 02:13, Max Bowsher wrote:
If we do add a class, it should probably be a thread class from which all
of
our threaded tasks can derive. Regardless, I don't see that any further
cleanup will
On Mon, 28 Jul 2003, Gary R. Van Sickle wrote:
Robert Collins wrote:
On Tue, 2003-07-29 at 02:13, Max Bowsher wrote:
If we do add a class, it should probably be a thread class
from which all
of
our threaded tasks can derive. Regardless, I don't see that any further
Here at last... OnAcceptActivation!
Great day in the morning!
Extracted from the bulk of Gary's changes, bugfixed (the DWL_MSGRESULT logic
was inverted),
Well, that's being kind ;-). I had that way out-of-whack. Late-night coding,
you know.
and also removing the bumper code in
Gary,
If I understand the Microsoft Docs, this is only necessary if a WndProc will
receive SendMessages from other threads in the same app. None of our
secondary threads call SendMessage - are you just adding it on a better
safe than sorry basis, or is there something I've overlooked?
Another cleanup patch. The remaining user of next_dialog, do_fromcwd,
requires slightly more invasive refactoring, hence is not included with
these changes.
Huh??? Doesn't this straightforward patch do it?:
2003-07-28 Gary R. Van Sickle [EMAIL PROTECTED]
* fromcwd.cc (do_fromcwd):
...this straightforward patch:
2003-07-28 Gary R. Van Sickle [EMAIL PROTECTED]
* dialog.h (do_fromcwd): Change function declaration.
* fromcwd.cc (do_fromcwd): Change return type to bool. Eliminate
use of next_dialog, return true or false instead.
* localdir.cc
I just did a quick unofficial scan of my /bin area and unearthed
the following dlls using fdopen, making them potential candidates
for rebuilding under 1.5.1.
cygXpm-X4.dll
cygXpm-noX4.dll
cygbz2-1.dll
cygbz21.0.dll
cygguile-12.dll
cygguile-14.dll
cygguilereadline-14.dll
On Mon, Jul 21, 2003 at 03:08:19PM +0200, Corinna Vinschen wrote:
Hi,
I've uploaded the 64 bit version of patch, 2.5.8-4, marked as test.
I've rebuilt Corinna's version of patch using 1.5.1 import libraries
so it should now work correctly with a 1.5.1 or greater DLL.
It is patch-2.5.8-5.
cgf
I thought Cygwin1.dll was the main dll.
Should it not have already been rebuilt?
I'll check out the sources tonight and look into this.
Could have sworn you built the 1.5.1 cygwin1.dll.
Robert McNulty Junior
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
24 matches
Mail list logo
