April 2003 - Wine-Devel - list.winehq.org

Re: Avoid non-portable signal(SIGCHLD, SIG_IGN)

by Joerg Wunsch

[Sorry for the late reply.] As Alexandre Julliard wrote: > > Unfortunately, a general patch for this is beyond my (current) > > capabilities, so I'd really appreciate could the two of you agree on > > a general fix for this. > > Does this do the right thing on FreeBSD? > + struct sigaction sig_act; > + > + sig_act.sa_handler = SIG_IGN; > + sig_act.sa_flags = 0; > + sigemptyset( &sig_act.sa_mask ); ... > +#ifdef SA_NOCLDWAIT > + sig_act.sa_flags |= SA_NOCLDWAIT; > +#endif > + sigaction( SIGCHLD, &sig_act, NULL ); I didn't test that yet, but i think that should work. If SA_NOCLDWAIT is set (in a call for SIGCHLD), sa_handler ought to be ignored anyway. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)

April 25, 2003

Re: cvs hangs

by MichaelGuennewig＠gmx.de

Ferenc Wagner <wferi(a)tba.elte.hu> writes: > Hello, > > since the crash, every cvs operation I do hangs at the end. > [Concurrent Versions System (CVS) 1.11.1p1 (client/server)] ... > <wait for a very long time, then get bored and press ^C> > cvs [status aborted]: received interrupt signal > > The same for an update, too. It seems to do a perfect job, > though. cvs is sleeping in tcp_data_wait indefinitely. I > have no idea what can cause this. Any advice? I had this problem also, but only when using ':ext:'. After an update to the newest version ov CVS (1.11.5) the problem was solved. Michael

April 25, 2003

cvs hangs

by Ferenc Wagner

Hello, since the crash, every cvs operation I do hangs at the end. [Concurrent Versions System (CVS) 1.11.1p1 (client/server)] For example: tba:/usr/local/src/wine/ $ cvs status configure.ac =================================================================== File: configure.ac Status: Up-to-date Working revision: 1.151 Repository revision: 1.151 /home/wine/wine/configure.ac,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) <wait for a very long time, then get bored and press ^C> cvs [status aborted]: received interrupt signal The same for an update, too. It seems to do a perfect job, though. cvs is sleeping in tcp_data_wait indefinitely. I have no idea what can cause this. Any advice? Feri.

April 25, 2003

RE: Debugging

by Ann and Jason Edmeades

> In general, I don't think it's such a good idea to just dump > memory. Most of the time the data is typed, so outputing > something more meaningful is better. Well, my main reason was while debugging its useful to dump storage to see what is going on, not so much to dump anything on a regular basis in trace. Sometimes its useful to dump structures etc esp if corruption is occuring, and a pre-supplied macro would have been very useful. I was just suprised I couldnt find anything which actually did it already! >Not to mention that such a dump might interfere with the terminal. I dont understand this? Any dump would go as tracepoints, formatted to only print out hex and printable characters, and nowhere near the screen. Anyway, I'll put it in a local private header and noone will ever need see it - Should keep everyone happy. Regards, Jason

April 25, 2003

Re: New Server?

by Jeremy White

Well, I'll let Jer tell you about the box he speced out that we authorized him to buy. It was very nice... Yesterday I went to a local dealer and said: I need a server, and I have to walk out of here with it in 1 hour. So what I got was the best of what they had. Which was a dual Athlon MP/2000 system, with a 36Gig SCSI drive (they didn't have the hardware raid card, so it's not raided yet), and 2 Gig of RAM. Truthfully, our old box (dual Intel 800's) was plenty fast; it's never really had much trouble keeping up. Linux is a remarkably efficient server OS <grin>. We're going to add a nice Adaptec hardware raid card and raid up the drives. We're fortunate in that we colocate with our ISP that has multiple OC-3s, and they mostly use the downstream bandwidth... The eventual plan is to replicate this box at another colo and then have two boxes, DNS round robined, and mirrored. Jer also wants to put in dedicated mysql servers, but truthfully, we're still figuring out what the best practice is. Anyone want to send us advice (privately would be best; this isn't a sysadmin list), we'll cheerfully listen. I think we have enough egg on our face that we'll humbly accept advice :-/ Cheers, Jer On Fri, 2003-04-25 at 08:50, Mike Hearn wrote: > On Fri, 2003-04-25 at 14:28, Jeremy White wrote: > > Actually, the old server had enough moxy to handle the load; > > it had been through several Slashdottings. We've got > > both the hardware resources and the bandwidth to handle > > this just fine. > > Just out of curiousity, what are the specs of the WineHQ box, and how > much bandwidth do you guys have? > > I'm currently trying to convince IE5.0 to not suck, hence my frustration > and boredom.... need something to gawp at before I go to sleep... > > -- > Mike Hearn <m.hearn(a)signal.qinetiq.com> > QinetiQ - Malvern Technology Center >

April 25, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Dimitrie O. Paun

On 25 Apr 2003, Mike Hearn wrote: > Actually.... yes? :) They aren't really diverging in my eyes, this > broken system tray I have sitting here taunting me is a visible reminder > that we need to keep Wine up to date with the latest standards. Yes, they become better integrated, but we're at the beginning of the road, and we still don't even get the easy stuff perfect: L&F, system tray, etc. I can see unifying most settings so we don't have to configure things twice, but we're far away, there seems to be little political will (especially on the KDE side). But what about OLE? KDE will never accept CORBA (for good reasons), while GNOME will not drop it. That's the big one: how do you integrate the apps more than making them just look the same? > I'm still not sure why you think we need one implementation to get > integration, as opposed to one set of interfaces with several possible > implementations. It's mainly a misunderstanding, mea culpa. I am not suggesting the "one implementation" is the way to go, but it's a possiblity. I actually think a set of interfaces with different implementations is better in the long run, so I'm happy we have things like the freestandards.org, and Havoc seems to be doing a great job. For WIDE, I would not reinvent everything around Win32, as the GNOME/KDE/OpenStep/Enlightment people did around their toolkits. I would get the best of breed apps from all environments, and try to integrate them: -- For L&F, having Wine adapt the L&F of the native environment is better, if that would be available, I'd use it. If not, I might compile GTK-Wimp agains Wine, until we get theaming in Wine. -- There are a bunch of free Win32 apps on SF which are very popular. I can choose some of those, like eMule, Mozilla/Win32, etc. I may use the ReactOS Explorer replacement instead of Nautilus, if they do a good job with it. -- I would compile wxWindows against it's Wine backend, simply because I think out widgets are better than the ones in GTK. -- I will try to have a Bonobo backend for Win32, so that GNOME apps could seemlessly link and embed Win32 apps. -- All libs in WIDE will be LGPL, so the platform is free for everybody. I was not suggesting to replace read with ReadFile, or Unix pipes with Win32 pipes. Yes, about the same thing one can achieve on top of GNOME, by just tweaking Wine to integrate better with it. But the big problem with GNOME is political, people are too religious about these issues. All I want is a higly integrated environment where I get by default 'best of breed' free apps from across GNOME/Windows/etc. As a user I don't care what langauge/api/toolkit an app uses, I want an unified seemless environment. I'm sick and tired of all the political debates, give me a cool user experience, not political diatribes on why I should belive religiously that Windows sucks and $YOUR_DESKTOP_ENVIRONMENT is the best thing since slice bread. -- Dimi.

April 25, 2003

Re: New Server?

by Mike Hearn

On Fri, 2003-04-25 at 14:28, Jeremy White wrote: > Actually, the old server had enough moxy to handle the load; > it had been through several Slashdottings. We've got > both the hardware resources and the bandwidth to handle > this just fine. Just out of curiousity, what are the specs of the WineHQ box, and how much bandwidth do you guys have? I'm currently trying to convince IE5.0 to not suck, hence my frustration and boredom.... need something to gawp at before I go to sleep... -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 25, 2003

Re: New Server?

by Jeremy White

Actually, the old server had enough moxy to handle the load; it had been through several Slashdottings. We've got both the hardware resources and the bandwidth to handle this just fine. We just relied on our good luck holding more than we should have... It turns out that one of the SCSI drives was slowly and steadily flaking out, causing all kinds of fun problems. And we didn't have the hardware raid turned on... So Jer and I had a really fun night last night. The highlight of which was squeezing the SCSI drive electronics for 1-2 hours while the data copied off. The good news is that the server is now up on a completely new box with a brand new shiny drive. The bad news is that it's still not set up on the proper hardware raid we mean for it to have. That's next weeks project... We're pretty sure that we copied everything properly, but the drive was really quite flaky towards the end, and we have found numerous cases of corrupted files. We're going to go through and test them on a point by point basis, and restore from tape where necessary, but please keep an eye out and let us know if you find issues. But the server should be solid for the next few days; except for a brief period next week, when we'll take it down and put in a proper hardware raid...<grin>. Cheers, Jeremy hatky wrote: > Since the Slash Dot pice on Wine the server is dead > half the day.... > Why not get the site on a new server > I know what you are going to say: > "Have you got one?" > :) > How about wine.sf.net? > > You already have a project open on source forge is it > that difficult to move the site to their server? > I THINK they can handle the load > > I assume there is some reason it has not been done but > if there is not any meager issue I think it will be > done at least for now (till the users stop coming :) ) > > What do you think? > > Hatky. > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com

April 25, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Mike Hearn

> Really? Do people think that KDE & QT would be a more suitable solution? No, but they are not the only platform available, as you have noted. > platform we want to build? You can develop apps for free on Windows > (see MinGW, Borland, OpenWatcom), or for a small price buy MSVC, yet How many people actually program Windows without using an IDE? Most programmers I know use either MS Visual C++/Basic or Delphi (and now .NET). > So the _only_ viable Unix GUI API is GTK/GNOME. I would say, rather, "So the _only_ viable Unix GUI API for non-GPLd software is GTK/GNOME" For GPLd software, Qt is fine (though aesthetically i prefer gtk). This would only be a problem if in future you were required to use it in order to get integration, as you are required to use the Win32 API implementations to get integration on Windows. Luckily that isn't the case, and is becoming less so every day. I don't see any fundamental reason why you can't have the same app written using Qt and GTK next to each other, with identical L&F and perfect integration. Sure, that's not the case today, but it's possible. > But version 2 of that API > came out only a year ago, and Evolution is not even ported to it! Well, it almost is. Apparently the 1.3.x series is quite stable now. > Do you > consider that traditional? It's so new it's not even funny. And maybe > that's fine, but the problem is that they lost steam: at the moment it > seems that most development is done by RedHat, Ximian, and Sun. Not sure where you got that idea, Ximian haven't been contributing much code of late at all, they mainly maintain current stuff. Redhat and Sun do quite a bit, but the bulk of the work, as ever, is done by volunteers. The release coordinator is a volunteer, GStreamer is developed by volunteers, a lot of the work on GTK is done by volunteers, ditto for gnome-panel, libgnome and so on. > And it's going slow. The two platforms (GNOME and KDE) seem to diverge more and > more, and if you look asymptotically, do you see a bright, integrated > future? Actually.... yes? :) They aren't really diverging in my eyes, this broken system tray I have sitting here taunting me is a visible reminder that we need to keep Wine up to date with the latest standards. > I don't think that WIDE is the greatest idea since slice bread. It's just > something I thought of as a possibility during the discussion, and I threw > it in there as a way to show there are other ways of looking at Wine. > But I also don't think it's such a bad idea either. And I really don't > understand the irrational fear (oh, it comes from MS, it *must* be evil), > and the overly emotional and unsupportable defense of 'Unix API'. I'm still not sure why you think we need one implementation to get integration, as opposed to one set of interfaces with several possible implementations. Experiments like the system tray seem to indicate that we can get a unified platform between several large toolkit implementations regardless of their license, or who designed them. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 25, 2003

[FYI] Mozilla & MinGW

by Dimitrie O. Paun

Folks, Mozilla officially builds on MinGW: http://www.mozilla.org/build/win32.html#ss2.2 Bug #134113 tracking this effort was closed: http://bugzilla.mozilla.org/show_bug.cgi?id=134113 Unfortunately, the new windres I was working on did not make it in time for this release, so a bunch of ugly hacks had to be checked in to work around various problems, but hopefully we'll be able to remove them in a few weeks, when the next binutils package is released. We can now start looking into the real Winelib port. :) -- Dimi.

April 25, 2003