Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
Table Of Contents
|1.||20 Mar 2004 - 26 Mar 2004||(3 posts)||News: WineHQ Stats|
|2.||21 Mar 2004||(1 post)||New Task Manager|
|3.||24 Mar 2004 - 25 Mar 2004||(10 posts)||WinAPI Stats on WineHQ|
|4.||17 Mar 2004 - 24 Mar 2004||(42 posts)||A Distributed Test Environment|
|5.||24 Mar 2004||(2 posts)||Wine Weekly News Issues #90 and #91|
This is the 216th issue of the Wine Weekly News publication. Its main goal is to remind you to floss. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org
Mailing List Stats For This Week
We looked at 168 posts in 477K.
There were 49 different contributors. 25 posted more than once. 22 posted last week too.
The top posters of the week were:
1. News: WineHQ Stats
20 Mar 2004 - 26 Mar 2004 (3 posts) Archive Link: "News"
People: Gavriel State, LinuxWorld, , Gav State, News, TransGaming
Someone on IRC pointed out CIA is tracking Wine stats. The stats are skewed since it tracks things sent to wine-patches rather than wine-cvs. Nonetheless, the numbers are interesting. I suspect some of the other projects that show lots of traffic include regular discussion on their lists as well as patches.
Over at Frank's Corner I found a link to a vnunet.com article titled "Linux and Windows: Mixed doubles". Part I goes into a bit of discussion about Wine and part II delves into actual configuration of the Wine config file. (Yes, that same config file a bunch of people are working on eradicating once and for all.)
In fact, that task is on the To Do List. A few weeks ago we had 19 items marked as complete, 30 in progress, and 18 up for grabs. We've seen more progress and now:
Alexandre is working on the filesystem changes right now. We're likely to see a domino effect of some items once that's complete. Namely, that will set things up for switching the configuration into the registry.
LinuxWorld looked at the capabilities of Linux as a gaming platform. Dee-Ann LeBlanc put together two articles that mention a bit about TransGaming. The first one explores challenges faced by Linux. The second goes in-depth into libraries that can be used by game programmers. It includes this quote from Gav State:
Our users have asked us to begin adopting the ALSA API in place of the older OSS [Open Sound System, www.opensound.com] APIs, and we've begun to look at how best to do that. One option that we're considering is switching to OpenAL, which now has a direct ALSA back end. Doing that right is going to require us to get some extensions added to OpenAL, which we're discussing with OpenAL developers such as Ryan Gordon; driver quality is still an issue.
OpenAL was first introduced by Loki and provides a cross-platform 3D audio API.
2. New Task Manager
21 Mar 2004 (1 post) Archive Link: "reactos' taskmgr"
People: Eric Pouech, , ReactOS
Eric Pouech ported a Task Manager to Wine:
This is (finally...) the port of ReactOS taskmgr into wine.
There's also a small trick for setting/resetting debug channels on the fly. Just left click on any running program (not application) and in the context popup menu, choose the debug channel edition line. This will require you to have a running dbghelp DLL, which I might provide RSN. In other words, this patch alone won't allow channel manipilation, this patch and the yet to come dbghelp DLL will do.
There's still lot of possible improvement on the UI part for the debug channel editing, so if someone has better ideas for implementing it, please feel free to do it.
The Task Manager is pretty slick, and since it lends itself to screenshots I figured I would make some available:
3. WinAPI Stats on WineHQ
24 Mar 2004 - 25 Mar 2004 (10 posts) Archive Link: "To Do A.11 - Integrate API status into WineHQ"
People: Ofir Petruska, Jeremy Newman, , Francois Gouget, News
More work on the web site has been done over the past week. I'll summarize those changes in a news article next week. This one developed a thread on wine-devel, so I'll cover it now. Ofir Petruska, who seems to go by hatky, came up with a way to display the output from the winapi_extract tool. Francois Gouget has had a version of this on his personal web site for a while and it was decided it was cool enough that we should integrate it into WineHQ. Hatky came up with a different approach that involved using MySQL for part of the logic. Dimi was definitely against using a database, but hatky explained:
It uses DB only for creating the file as a parser becouse it's 3 lines of code instade of 30 line parsing and very very flexable, I talked to laxdragon, he has not problem with it, he is still reviewing it...
Jeremy Newman then took a look at it and made modifications. He announced:
Ok, I have commited a version of hatky's work. It is in one php file instead of split across multiple files.
The file is in the tools cvs http://cvs.winehq.org/cvsweb/tools/winapi_stats.php
I ran it once and the output will be here: http://www.winehq.org/site/winapi_stats
It will be updated when Alexander runs the wine_release script.
There is one bug we noticed, and I'll leave that for someone else to fix. The dll name is only showing the first 5 characters. I double checked, it is getting inserted into the db correctly, so it is happening sometime after the insert.
Thanks hatky for your work.
Francois pointed out that several DLL's needed to be ignored since they were Wine-specific. He provided a list that hatky integrated.
4. A Distributed Test Environment
17 Mar 2004 - 24 Mar 2004 (42 posts) Archive Link: "Win32 packages released on sourceforge"
People: Paul Millar, Chris Morgan, , Ferenc Wagner, Dimi Paun
More discussion took place about setting up a distributed testing framework. When this actually rolls out I'll write up more info about how it works. Some of the details are still being sort out, but basically the process will work like this:
In essence, the process is quite simple. Some discussion took place this week over details. Paul outlined how he has the builds set up:
I'm adding cross-building as part of WRT, so we'd get winetest.exe rebuilt as changes are made to CVS (& everything else too, if people want that). Its nearly there, having worked around some mingw/COFF nasties. There's one last hurdle: winetest.exe itself.
>From what I can see, the script programs/winetest/maketest builds the winetest.rc file. If the variable WINE_BUILD is set, it is used as the first element of the string-table, otherwise an auto-generated string is used, for example "20040322.1508-auto".
This makes winetest.exe build-time-dependant, so screws up the check to see if anything's actually changed.
Can I set WINE_BUILD to some fixed value? If so, what's a good one to use?
Dimi Paun had some suggestions:
The WINE_BUILD value must be valid, we can't distribute a winetest.exe with a fixed value in there. What you can do is fix it at build time to a known value (say YYYYMMDDhhmm), and replace it after the build with the proper value.
Now, when do we build? I don't think we should trigger the build based upon CVS commits, we need it a bit more controlled for a variety of reasons. Here is what I propose:
But the main point here is that we can't build based on CVS commits, we need a well known, controlled point where we build so that developers can reproduce the build and investigate problems.
Discussion then went back and forth.. and back.. and forth about whether to have builds triggered by CVS commits. Paul produced some interesting info concerning CVS commits:
Errr, 'fraid I don't see the 4am part (unless you mean at precisely 04:00:00). Taking data from the past year from:
Downloading the "downloadable version", and running a wee 1-oner:
Gnuplot it with:
The results are: http://www.astro.gla.ac.uk/users/paulm/cvs_commit.png
There's actually a peak of commits at 4am.
This is of course all UK local time. Do you mean 4am in one of the US-time-zones? (=> ~ 9am-11am or so?).
Hmmm, in the past year there've been patches a 7am, 8am, 11am and 13am. There haven't been any 9am and 10am, but looking at the data it wouldn't be impossible for Alexandre to commit at usual hours of the day or night :)
Actually, the build time isn't *that* time consuming. Running ccache and distcc, it currently takes about an hour to build both native and cross-compilation. With a bit of effort, I'm sure that could be improved a fair bit. As soon as the cross-compilation is finished, the binaries are available to be published.
The time-consuming bit at the moment is running the tests within wine, which is bad because of the way that's done within WRT. That needs fixing, but it's largely independent of the cross-building, publishing steps.
From there the discussion delved into using GPG to sign the binaries. Paul has already implemented that part on the server.
5. Wine Weekly News Issues #90 and #91
24 Mar 2004 (2 posts) Archive Link: "Missing WWN issues"
People: Francois Gouget, , Brian Vincent, Eric Pouech, News
Francois Gouget pointed out we have a bit of a gap in Wine Weekly News issues:
Looking through the WINeHQ CVS I noticed that we are missing 4 WWN issues. Fortunately they seem to be available at the Wine Kernel Cousin web site... sort of.
Would some kind soul volunteer for retrieving what can be retrieved?
We changed the XML format a few years ago, so I went back and ported the missing issues. If you're interested in the latest news from 2001, check out issues #90 and #91. More interesting than that (at least to me) was Eric Pouech's revelation that parts of issue #88 exist, but had never been published. At some point in the future I'll create issue 88 from those bits.
Sharon And Joy