|
From: Bryan M. <om...@br...> - 2005-11-04 23:34:12
|
Dear Valgrind Team, you can find a patch against svn here: www.brainmurders.eclipse.co.uk/omega_ALPHA_01.patch.gz This is ALPHA software but is quite functional. =46rom the docs: What Next? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I have to finish coding it ;P Right now, this is an ALPHA version of code for people to start playing wit= h.=20 I have only tested it on x86 32 bit so far (I just got it working and the=20 company server room is down for power work this weekend so no 64 bit testin= g=20 from me until next week). It is seriously not optimised in places and has=20 some missing functionality. It passes the small set of tests that included= =20 with it (but not hooked into the libtool/autotest system). If anyone is interested in helping me out on this, send your patches. I hop= e=20 to get this accepted into Valgrind so it can get some serious attention but= I=20 dont know if that will happen so I will try to maintain a patch against svn= =20 or a tar of the whole thing if that gets too troublesome. Of course, you can wait for me to do it instead if you are not in a hurry :D Bryan "Brain Murders" Meredith =46eel free to email me about this at om...@br... so I= can=20 sort the incoming mail. |
|
From: Josef W. <Jos...@gm...> - 2005-11-04 23:59:32
|
On Saturday 05 November 2005 00:33, Bryan Meredith wrote: > to get this accepted into Valgrind so it can get some serious attention but I > dont know if that will happen so I will try to maintain a patch against svn > or a tar of the whole thing if that gets too troublesome. Why don't you make a separately distributed, external VG tool out of it? It is a lot easier to be not the only one checking that a VG installation provides enough for such external tools. Josef |
|
From: Oswald B. <os...@kd...> - 2005-11-05 08:53:46
|
On Sat, Nov 05, 2005 at 01:03:33AM +0100, Josef Weidendorfer wrote: > On Saturday 05 November 2005 00:33, Bryan Meredith wrote: > > to get this accepted into Valgrind so it can get some serious > > attention but I dont know if that will happen so I will try to > > maintain a patch against svn or a tar of the whole thing if that > > gets too troublesome. > > Why don't you make a separately distributed, external VG tool out of > it? > because being integrated gives you more visibility, relieves you from release management, more or less assures continuous code review from people who ought to know what they are talking about and finally the user has less effort to obtain + install it. on the downside, you're bound to the core project's release schedule ... > It is a lot easier to be not the only one checking that a VG > installation provides enough for such external tools. > ... and if the project is supposed to have library character, it gets less testing in this area. really, it's all the same as with kde. ;) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Josef W. <Jos...@gm...> - 2005-11-05 19:44:00
|
On Saturday 05 November 2005 09:53, Oswald Buddenhagen wrote: > On Sat, Nov 05, 2005 at 01:03:33AM +0100, Josef Weidendorfer wrote: > > Why don't you make a separately distributed, external VG tool out of > > it? > > > because being integrated gives you more visibility, relieves you from > release management, more or less assures continuous code review from > people who ought to know what they are talking about and finally the > user has less effort to obtain + install it. That is all good and fine, but VGs history tells me: there was not one tool being accepted to be included into VG unless the author was one of the VG core authors itself. And there is a reason: if the author disappears, all the maintenance falls back to the core developers. And at such a point, it is better to drop it again. This even happened to one tool from a core developer: helgrind. And that was even "only" because of changed funtionality of VG core. > on the downside, you're bound to the core project's release schedule ... No. Unfortunately that is the case even with external tools: As the tool API's major number changes with every major VG release, I am "forced" to come up with a release of my external tool ASAP. There were 6 bug reports for debian because Callgrind did not catch up in time with VG 3 :-( > > It is a lot easier to be not the only one checking that a VG > > installation provides enough for such external tools. > > > ... and if the project is supposed to have library character, it gets > less testing in this area. > > really, it's all the same as with kde. ;) VG has a small active developer community, you can not compare it to KDE (and even KDE has unmaintained code in its core distribution!). In the KDE case, a big plus to be in a core package is to get i18n. This is not a problem with VG. So perhaps an idea for VG >= 3.2: Make a VG core distribution with pure library character, without any tool at all, and provide all tools externally. Visibility is done via valgrinds web site, listing all tools available. I am quite sure that Fedora/SuSE/Debian etc. would provide packages for all such tools. And by calling the package e.g. "valgrind-omega" it probably will be installed by users interested in valgrind. Josef |
|
From: Bryan M. <om...@br...> - 2005-11-05 21:03:40
|
On Saturday 05 Nov 2005 20:12, Josef Weidendorfer wrote: > On Saturday 05 November 2005 09:53, Oswald Buddenhagen wrote: > > On Sat, Nov 05, 2005 at 01:03:33AM +0100, Josef Weidendorfer wrote: > > > Why don't you make a separately distributed, external VG tool out of > > > it? > > > > > because being integrated gives you more visibility, relieves you from > > release management, more or less assures continuous code review from > > people who ought to know what they are talking about and finally the > > user has less effort to obtain + install it. > > That is all good and fine, but VGs history tells me: there was not one > tool being accepted to be included into VG unless the author was one > of the VG core authors itself. And there is a reason: if the author > disappears, all the maintenance falls back to the core developers. > And at such a point, it is better to drop it again. This even happened > to one tool from a core developer: helgrind. And that was even "only" > because of changed funtionality of VG core. > > > on the downside, you're bound to the core project's release schedule ... > > No. Unfortunately that is the case even with external tools: As the tool > API's major number changes with every major VG release, I am "forced" to > come up with a release of my external tool ASAP. There were 6 bug reports > for debian because Callgrind did not catch up in time with VG 3 :-( > > > > It is a lot easier to be not the only one checking that a VG > > > installation provides enough for such external tools. > > > > > ... and if the project is supposed to have library character, it gets > > less testing in this area. > > > > really, it's all the same as with kde. ;) > > VG has a small active developer community, you can not compare it to KDE > (and even KDE has unmaintained code in its core distribution!). > In the KDE case, a big plus to be in a core package is to get i18n. > This is not a problem with VG. > > So perhaps an idea for VG >= 3.2: Make a VG core distribution with pure > library character, without any tool at all, and provide all tools externally. > > Visibility is done via valgrinds web site, listing all tools available. > I am quite sure that Fedora/SuSE/Debian etc. would provide packages > for all such tools. And by calling the package e.g. "valgrind-omega" > it probably will be installed by users interested in valgrind. > > Josef > I appreciate the comments - thanks. The main thing for me is to get it working to such an extent that it is usefull to people. Whilst there is a lot that I can do on my own, there is a lot more that can be done either directly or with the help and guidance of others. If the guys don't want it in, that's fine but omega has to be in a visible enough place so that people know that it is available and that they are welcome to hack on it. There are many ways of achieving that but my preference is for it to be in with the core toolset. If it looks like that wont happen, I will work out the best way forwards from that point. This tool wont be going away - I have written it to use at work whilst we transition some code so I will be supporting it at least for internal use for quite some time to come. It just strikes me that sharing it out is the right thing to do. Bryan "Brain Murders" Meredith |
|
From: Julian S. <js...@ac...> - 2005-11-05 23:10:50
|
> That is all good and fine, but VGs history tells me: there was not one > tool being accepted to be included into VG unless the author was one > of the VG core authors itself. And there is a reason: if the author > disappears, all the maintenance falls back to the core developers. > And at such a point, it is better to drop it again. This even happened > to one tool from a core developer: helgrind. And that was even "only" > because of changed funtionality of VG core. That really was only because of the threading changes in 2.4, which were carried into 3.0, made it impossible for Helgrind to work. I for one would love to have Helgrind working again. We do get a number of requests for it, and assuming it is possible to make function wrapping work again in the 3.1->3.2 gap, then we might have Helgrind for 3.2. Your best short term course of action, IMO, is to make Omega work really well with 3.1. "work really well" means something like: is able to run programs the size of OpenOffice and Firefox stably, on x86, amd64 and ideally ppc32, in reasonable time, and produces output which is meaningful to users (eg, not many false positives and not many false negatives). Perhaps we should raise the visibility of external tools on the web site by creating a separate page for them off the top level "Information" category. I'd be happy for Omega to be listed there. J |