Re: [ANN] update: apache-1.3.24-3
On Mon, Apr 29, 2002 at 08:04:42PM +0200, Stipe Tolj wrote: Hi there, please upload the latest binary build for 1.3.24-3 from http://apache.dev.wapme.net/support/cygwin-packages/apache/. Please provide the full paths to the archives, including the filename. It allows me conveniently just to copy/paste them into a command line. Other than that, I can't copy the files due to a permission problem on cygwin.com. We'll have to wait for Chris to wake up, today. I have added this time a flag -k for no-detach (keep attached) mode. Hence if httpd is invoked without any flags it detaches, which is the normal behaviour for other UNIX flavors and -k may be used to run it using cygrunsrv. This change in behaviour needs some and in the announcement. Hmm, forget it, people will ask clueless questions anyway... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
setup.exe exception handling guidelines
I've reviewed the use of threads, and I believe the following guidelines will provide safe exception handling without stomping across threads. Exception handling guidelines: For 100% message based windows, exceptions in code will get caught by the same thread that handles window messages - which means the propertysheet thread. The catch routine here can only catch exceptions within a message. for thread based windows (i.e. site, or the current chooser, or download), the thread reflector can catch() whatever it wants to... AS LONG AS the window message routine does not do any exception processing (ie , try catch or throw). What does this mean? Well things like the nio code can throw an authentication exception, to separate out the functional code and the UI. This will let Pavel Tsekov's URL class get added to setup in the near future, and will also allow some more cleanups leading up to a command line version and or more split out support libraries. Of course, if the gcc library (mingw or cygwin) was built with --with-threads, this would be simpler. Exceptions that can be thrown: I'm going to create a base Exception class, from which all thrown exceptions should derive. No char/string or String exceptions are allowed. This allows a generic catch-all Exception handler, and by subclassing, more specific handlers can sit in front of it. Cheers, Rob
Re: setup.exe exception handling guidelines
Hello Robert, Tuesday, April 30, 2002, 1:09:48 PM, you wrote: [snip] RC Exceptions that can be thrown: RC I'm going to create a base Exception class, from which all thrown RC exceptions should derive. No char/string or String exceptions are RC allowed. This allows a generic catch-all Exception handler, and by RC subclassing, more specific handlers can sit in front of it. What about the standard C++ library exception class ? In the recent threads regarding setup and libgetopt++ I red that we libstdc++ can be used now ?
time stamp printing for ssp
Hi,
for application debugging I had the need to see the elapsed time for any step in
ssp, so I've added time stamp printing.
$ cvs diff -p ssp.c
Index: ssp.c
===
RCS file: /cvs/src/src/winsup/utils/ssp.c,v
retrieving revision 1.3
diff -u -3 -p -B -p -r1.3 ssp.c
--- ssp.c 27 Feb 2002 16:10:17 - 1.3
+++ ssp.c 30 Apr 2002 15:30:23 -
@@ -20,6 +20,7 @@
#include time.h
#include ctype.h
#include windows.h
+#include sys/time.h
#ifdef __GNUC__
const char *help_text = \
@@ -326,6 +327,8 @@ run_program (char *cmdline)
int tix, i;
HANDLE hThread;
char *string;
+ long long int starttime,ctime;
+ struct timeval time;
memset (startup, 0, sizeof (startup));
startup.cb = sizeof (startup);
@@ -376,6 +379,13 @@ run_program (char *cmdline)
}
}
+ if (verbose)
+ {
+/* init timecounter */
+gettimeofday(time,NULL);
+starttime = time.tv_sec * 100 + time.tv_usec;
+ }
+
running = 1;
while (running)
{
@@ -407,10 +417,24 @@ run_program (char *cmdline)
printf (\n);
#endif
+if (verbose) {
+ /* print current time */
+ gettimeofday(time,NULL);
+ ctime = time.tv_sec * 100 + time.tv_usec - starttime;
+ {
+ int min = (int) (ctime /6000);
+ int sec = (int) (ctime /100);
+ int millisec = (int) ((ctime /1000) %1000);
+ printf(%02d:%02d.%03d ,min,sec,millisec);
+ }
+ }
+
switch (event.dwDebugEventCode)
{
case CREATE_PROCESS_DEBUG_EVENT:
+ if (verbose)
+ printf(create process at
%08x\n,event.u.CreateProcessInfo.lpStartAddress);
break;
case CREATE_THREAD_DEBUG_EVENT:
@@ -653,6 +677,10 @@ run_program (char *cmdline)
running = 0;
break;
+
+ default:
+ if (verbose)
+printf(unknown event\n);
}
set_steps ();
-
2002-04-30 Ralf Habacker [EMAIL PROTECTED]
* ssp.c (run_program): Added time stamp printing in verbose mode.
Regards
Ralf
Re: MD5 support
On Tue, Apr 30, 2002 at 12:40:43PM +1000, Robert Collins wrote: I've uploaded a snapshot (bin src) that detects corrupt files based on md5. It's backward compatible with the current .ini format. The code needs reorganising before I commit it, this is simply for folk to play and test with. There is -no- UI change at this point. The md5 corruption is silently detected (and that will have to change before committing too). I have upset ready to go for this. Will it actually break setup.exe if I check in my changes? I'm away from a Windows system right now so I can't check myself. cgf
Re: RFC: setup.ini change
On Mon, Apr 29, 2002 at 12:17:54PM -0400, Charles Wilson wrote: Oh yeah -- speaking of changes to setup.ini: Chris, can we get that external-src: other-pkg-name thing into upset? (or other-src or whatever) Reminder: It's pretty complicated to add. If you specify external-src it will potentially have to add test, prev, curr entries for the packages. However, IMO, it makes sense for this option to actually be passed into setup.ini so that setup.exe can understand that this is basically a symbolic link rather than a copy. So, if I just add this as a pass-through, it is a no-brainer. If I add it as a fill in the blanks in setup.ini, it's more complicated. It's not hellishly more complicated but I'd rather not do the work if it makes sense for the logic to live in setup.exe. I don't remember if Robert already indicated which method he'd prefer. Maybe he already has plans to do the right thing when multiple packages refer to the same source tar ball. I seem to recall that this came up before but I don't remember what the decision was. cgf
