Date: Wed, 6 Jul 2005 00:05:17 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 577 ************************************************** Tuesday 05 July 2005 Number 577 ************************************************** Subjects for today 1 Re: CC1.EXE hanging processing the exit list : Dave Yeo" 2 Re: gzip (was: The OS/2 and eCS Ecosystem) : Andreas Buening 3 Re: gzip (was: The OS/2 and eCS Ecosystem) : Andreas Buening 4 Re: gzip (was: The OS/2 and eCS Ecosystem) : Dave Yeo" 5 Re: SETMOZENV & UX2BS : Dave Yeo" 6 Re: Debugging Perl code : Steven Levine" 7 Re: Subversion : Nicholas Sheppard **= Email 1 ==========================** Date: Mon, 04 Jul 2005 07:30:05 -0800 From: "Dave Yeo" Subject: Re: CC1.EXE hanging processing the exit list On Mon, 04 Jul 2005 14:59:10 +0200, Knut St. Osmundsen wrote: > > >Dave Yeo wrote: >> Went to work leaving a long compile happening. Came home and it had >> died due to an out of memory error. Killed emxload and sent a break >> to the hung CC1 process and now its sitting processing its exit list. >> Newest Innotek_libc, any one else had this? >I've seen something similar this weekend but haven't been able to >reproduce it properly and at the time it happend attaching a debugger to >the process wasn't helping much in seeing the real cause. >In my case I didn't see any out of memory messages though. Do you >remember any of the wording of that message? It was a simple CC1 out of memory message with various levels of make exiting but the command prompt not coming back. > >Did you get any messages of the !!!deadlock!!! type? No > >> I never have, usually killing emxload is enough, occasionally a >> ctrl-c as well. >There are a few really important locks which also include entering a >must complete section. If the app should hang while inside such a >section it's rather difficult to kill it using signals since those are >not delivered to the process. I'm try my best not to do anything which >would require blocking and trying to catch faults using special >exception handlers while inside a must complete section. I might have >overlooked something, somewhere. > Well I have experienced this sort of error before, CC1 has always been killable and it seems to happen when Mozilla (or Firefox) has been open for a few days. Usually have to close Mozilla before things work again. More often I get can not fork errors when some resource runs out. Watchcat this time reported that CC1 was exiting and looking at process details reported it was processing the exit list. >Kind Regards, > knut > Dave **= Email 2 ==========================** Date: Mon, 04 Jul 2005 22:43:21 +0200 From: Andreas Buening Subject: Re: gzip (was: The OS/2 and eCS Ecosystem) Dave Yeo wrote: > Does it support EAs? I don't think so. What would the EAs of a .gz file supposed to be? The same as those of the uncompressed file? Bye, Andreas **= Email 3 ==========================** Date: Mon, 04 Jul 2005 22:43:42 +0200 From: Andreas Buening Subject: Re: gzip (was: The OS/2 and eCS Ecosystem) John Poltorak wrote: > > On Sun, Jul 03, 2005 at 12:32:29PM +0200, Andreas Buening wrote: > > John Poltorak wrote: > > The file/shell/text utilities are (at least) a two day full time job, > > I guess. > > You already did a port of the text utilities (v2.0) nearly four years ago. Because they were easier than the shell/file utilities. > I wonder if all the same changes would be required now that automake and > autoconf have been updated... If you have chnace can you have a quick look > at your patches to see if you would still do everything the same way? 95% of them, yes. > > For gzip I just had to add a missing header, change some shell > > code twice which relied on a case sensitive file system, remove > > some duplicate defines and add a test for a missing function > > to have a define for it. Nothing that could be called "real" > > porting. > > You are far too modest, Andreas ;-) Really, I just fixed the configure stuff until it ran through. According to the docs KUR did the porting 12 years ago. Bye, Andreas **= Email 4 ==========================** Date: Mon, 04 Jul 2005 17:24:02 -0800 From: "Dave Yeo" Subject: Re: gzip (was: The OS/2 and eCS Ecosystem) On Mon, 04 Jul 2005 22:43:21 +0200, Andreas Buening wrote: >Dave Yeo wrote: > >> Does it support EAs? > >I don't think so. What would the EAs of a .gz file supposed to be? >The same as those of the uncompressed file? Hmm, I thought KURs port supported keeping EAs, but on testing I guess it doesn't. I'd say that ideally when compressing a file it should keep its EAs and restore them when uncompressing them but it is not too important Dave **= Email 5 ==========================** Date: Mon, 04 Jul 2005 21:54:14 -0800 From: "Dave Yeo" Subject: Re: SETMOZENV & UX2BS On Mon, 4 Jul 2005 10:45:28 +0100, John Poltorak wrote: >although I'm not sure that specific version of SED (v4.05) and MAKE (v3.81) >are required. Maybe they were picked because the were the most recent >versions... Definatly fails to produce good def files without SED(v4.05). Make most likely just has to be a recent one. Andreas new build works fine, configure does test the make version. > >> Then setting some enviroment settings such as perl. > >Why is this required? My view is if it isn't needed on Unix, then we >should be able to use the same defaults under UX2BS. Or am I missing >something? Yes your missing the fact that we have drive letters unlike Unix. Anyways the ux2bs build of perl is broken when it comes to drive letters so everything needs to be on the same partition and the perl settings aren't important. Using ux2bs the firefox build did end up dieing without producing a firefox.exe. I did accidently update the tree while experimenting so I'll try again. Dave **= Email 6 ==========================** Date: Mon, 04 Jul 2005 22:51:15 -0700 From: "Steven Levine" Subject: Re: Debugging Perl code In <20050704095008.A61 at warpix.org>, on 07/04/05 at 09:50 AM, John Poltorak said: >I would if I understood Perl, but my efforts to tweak the lines above >resulted in:- >Trying with "g:/wget.exe -O" to get This is fine as long a you supply the filename later, which you try to do. > >ftp://ftp.mirror.ac.uk/sites/ftp.funet.fi/pub/languages/perl/CPAN/modules/03 >modlist.data.gz >System call "g:/wget.exe -O >"ftp://ftp.mirror.ac.uk/sites/ftp.funet.fi/pub/langu >ages/perl/CPAN/modules/03modlist.data.gz" > >g:/home/root/.cpan/sources/modules/ >03modlist.data" >returned status 1 (wstat 256) >Warning: expected file >[g:/home/root/.cpan/sources/modules/03modlist.data.gz] do >esn't exist > my($system) = "$funkyftp$src_switch \"$asl_gz\" $devnull $url.gz"; It's acting like you mistyped $asl_gz, but I sure don't see it in the above, so I have to assume that $asl_gz is empty for some reason. >Obviously something wrong... True. You can help yourself by noting that the next line reads: $self->debug("system[$system]") if $CPAN::DEBUG; This says that the module can generate nice debug output for you. Using this feature is easier than inserting your own debug code. Use "o debug" in interactive mode to set the debug options. Also, you might want to learn to use the Perl debugger to set breakpoints and display variables. Again very handy when things don't work as expected. Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 7 ==========================** Date: Tue, 5 Jul 2005 20:52:58 +0000 (GMT) From: Nicholas Sheppard Subject: Re: Subversion On Sun, 3 Jul 2005, Brian Havard wrote: >> Does anyone know how to get it working in INETD mode? > > I doubt that's going to work without significant mods to svnserve as it > expects to communicate using stdin/stdout when started in inetd mode and, > if I remember correctly, OS/2's inetd works a bit differently due to the > fact that sockets and file handles aren't interchangable. The inetd shipped with OS/2 passes the socket handle as the first argument to the daemon. You can use _impsockhandle() to convert this into an EMX socket, then use dup2() to re-name the imported handle to stdin and stdout. Something like: ibmso = atoi(argv[1]); /* or wherever it comes from */ emxso = _impsockhandle(ibmso,0)); dup2(emxso,0); /* connect to stdin */ dup2(emxso,1); /* connect to stdout */ close(emxso); For a quick hack you might just be able to add the above to the top of main() if your original programme doesn't have command-line arguments of its own. Of course, if your original programme expects something else as its first argument then you have some work to do. IMAPD uses a script to save the socket handle to an environment variable that is then read by the programme (this is an artefact of the way in which OS-dependent routines are coded in IMAPD). Nick S.