On Sun, Jan 20, 2013 at 8:09 PM, André Hentschel wrote:
> ---
> + IDS_TCP_SEGM_RECV, "Segments Recieved"
Typo here: should be "Received"
(same issue on the 2nd patch)
Frédéric
On 2012-04-26, at 6:51 PM, Dave Chinner wrote:
> On Thu, Apr 26, 2012 at 02:32:36PM +0100, David Howells wrote:
>> I wonder if there's a way to make this explicit - or is it something that if
>> the bit isn't set, you can't use the value in st_blksize.
>> I wonder if this value always has to be no
On Thu, Apr 26, 2012 at 02:32:36PM +0100, David Howells wrote:
> Andreas Dilger wrote:
> > st_blksize may be variable for a distributed filesystem,
It can be variable for local filesystems, too. XFS will vary the
block size based on the configuration of the inode. e.g. if there is
an extent alloc
On Thu, Apr 26, 2012 at 9:28 AM, J. Bruce Fields wrote:
> On Thu, Apr 26, 2012 at 02:45:54PM +0100, David Howells wrote:
>> Steve French wrote:
>>
>> > I also would prefer that we simply treat the time granularity as part
>> > of the superblock (mounted volume) ie returned on fstat rather than on
On Thu, Apr 26, 2012 at 02:45:54PM +0100, David Howells wrote:
> Steve French wrote:
>
> > I also would prefer that we simply treat the time granularity as part
> > of the superblock (mounted volume) ie returned on fstat rather than on
> > every stat of the filesystem. For cifs mounts we could
On Thu, Apr 26, 2012 at 02:40:17PM +0100, David Howells wrote:
> J. Bruce Fields wrote:
>
> > > (11) Include granularity fields in the time data to indicate the
> > > granularity of each of the times (NFSv4 time_delta) [Steve French].
> >
> > It looks like you're including this with *each*
Steve French wrote:
> I also would prefer that we simply treat the time granularity as part
> of the superblock (mounted volume) ie returned on fstat rather than on
> every stat of the filesystem. For cifs mounts we could conceivably
> have different time granularity (1 or 2 second) on mounts t
J. Bruce Fields wrote:
> > (11) Include granularity fields in the time data to indicate the
> > granularity of each of the times (NFSv4 time_delta) [Steve French].
>
> It looks like you're including this with *each* time? But surely
> there's no filesystem with different granularity (say)
Andreas Dilger wrote:
> > The idea was initially proposed as a set of xattrs that could be
> > retrieved with getxattr(), but the general preferance proved to be
> > for new syscalls with an extended stat structure.
>
> I would comment that it was the opposite. It was originally a
> stat()-like
remote, may
>> not
>> + * have been synchronised with the server.
>> + *
>> + * 0 will be returned on success, and a -ve error code if unsuccessful.
>> + */
>> +int vfs_xgetattr(struct vfsmount *mnt, struct dentry *dentry,
>> + struct kstat *stat)
>
On Tue, Apr 24, 2012 at 4:29 PM, J. Bruce Fields wrote:
> On Thu, Apr 19, 2012 at 03:06:12PM +0100, David Howells wrote:
>> Add a pair of system calls to make extended file stats available, including
>> file creation time, inode version and data version where available
On Thu, Apr 19, 2012 at 03:06:12PM +0100, David Howells wrote:
> Add a pair of system calls to make extended file stats available, including
> file creation time, inode version and data version where available through the
> underlying filesystem.
>
> The idea was initially propo
On 2012-04-19, at 8:06 AM, David Howells wrote:
> Add a pair of system calls to make extended file stats available,
> including file creation time, inode version and data version where available
> through the underlying filesystem.
>
> The idea was initially proposed as a set
Add a pair of system calls to make extended file stats available, including
file creation time, inode version and data version where available through the
underlying filesystem.
The idea was initially proposed as a set of xattrs that could be retrieved with
getxattr(), but the general preferance
On 20 July 2010 04:37, Dan Kegel wrote:
> Quoth Linus:
>
> "Ask the Wine people what strange open-function-from-hell they are
> interested in."
>
> Full message follows. Discussion archived at e.g.
> http://marc.info/?l=linux-kernel&m=127955270231189&w=2
>
>
That link didn't work for me, it's on
l 19, 2010 at 8:17 AM
Subject: Re: [PATCH 02/18] xstat: Add a pair of system calls to make
extended file stats available [ver #6]
To: David Howells
Cc: linux-c...@vger.kernel.org, linux-...@vger.kernel.org,
samba-techni...@lists.samba.org, linux-ker...@vger.kernel.org,
v...@zeniv.linux.
Am 28.05.2010 21:24, schrieb Paul Vriens:
> On 05/28/2010 07:25 PM, André Hentschel wrote:
>> Am 28.05.2010 19:14, schrieb GOUJON Alexandre:
>>> Hi,
>>>
>>> There is a Win API Stats page available at
>>> http://www.winehq.org/winapi_stats.
>>&
On 05/28/2010 07:25 PM, André Hentschel wrote:
Am 28.05.2010 19:14, schrieb GOUJON Alexandre:
Hi,
There is a Win API Stats page available at
http://www.winehq.org/winapi_stats.
But as you can see, it's not updated since about a year.
So here is my question : (as wine-1.2 is coming) Shou
André Hentschel writes:
> Am 28.05.2010 19:14, schrieb GOUJON Alexandre:
>> Hi,
>>
>> There is a Win API Stats page available at
>> http://www.winehq.org/winapi_stats.
>> But as you can see, it's not updated since about a year.
>>
>> So here
On 5/28/2010 21:25, André Hentschel wrote:
Am 28.05.2010 19:14, schrieb GOUJON Alexandre:
Hi,
There is a Win API Stats page available at
http://www.winehq.org/winapi_stats.
But as you can see, it's not updated since about a year.
So here is my question : (as wine-1.2 is coming) Shou
Am 28.05.2010 19:14, schrieb GOUJON Alexandre:
> Hi,
>
> There is a Win API Stats page available at
> http://www.winehq.org/winapi_stats.
> But as you can see, it's not updated since about a year.
>
> So here is my question : (as wine-1.2 is coming) Should we update t
Hi,
There is a Win API Stats page available at
http://www.winehq.org/winapi_stats.
But as you can see, it's not updated since about a year.
So here is my question : (as wine-1.2 is coming) Should we update the
page or simply remove it ?
I think a cleanup is preferable to avoid confusio
Hi André,
> inspired by "Linux Kernel Development: How Fast it is Going, Who is Doing It,
> What They are Doing, and Who is Sponsoring It: An August 2009 Update"
> (http://www.linuxfoundation.org/publications/whowriteslinux.pdf), i thought
> we might do a similar analyse of the wine tree.
The
Hi,
inspired by "Linux Kernel Development: How Fast it is Going, Who is Doing It,
What They are Doing, and Who is Sponsoring It: An August 2009 Update"
(http://www.linuxfoundation.org/publications/whowriteslinux.pdf), i thought we
might do a similar analyse of the wine tree.
I attach a first ove
On Fri, Apr 24, 2009 at 8:04 PM, Ken Sharp wrote:
>
>
> Austin English wrote:
>>
>> On Fri, Apr 24, 2009 at 6:40 PM, Scott Ritchie
>> wrote:
>>>
>>> I had a theory that we might be getting better at preventing regressions
>>> now
>>> than a year or so ago due to the expansion of things like AppDB
Austin English wrote:
On Fri, Apr 24, 2009 at 6:40 PM, Scott Ritchie wrote:
I had a theory that we might be getting better at preventing regressions now
than a year or so ago due to the expansion of things like AppDB and the test
suite. It'd be nice to have some sort of data though.
Would i
On Fri, Apr 24, 2009 at 6:40 PM, Scott Ritchie wrote:
> I had a theory that we might be getting better at preventing regressions now
> than a year or so ago due to the expansion of things like AppDB and the test
> suite. It'd be nice to have some sort of data though.
>
> Would it be reasonable to
I had a theory that we might be getting better at preventing regressions
now than a year or so ago due to the expansion of things like AppDB and
the test suite. It'd be nice to have some sort of data though.
Would it be reasonable to comb through the bugzilla database for all the
bugs tagged
2009/4/9 Scott Ritchie :
> Joel Holdsworth wrote:
>>>
>>> Has anyone else noticed
>>> http://commons.wikimedia.org/wiki/File:History_Of_WineAppDB.gif
>>> which is shown on the right side of
>>> http://en.wikipedia.org/wiki/Wine_(software) ?
>>> It's kind of cool. Hats off to
>>> http://en.wikipedi
Joel Holdsworth wrote:
Has anyone else noticed
http://commons.wikimedia.org/wiki/File:History_Of_WineAppDB.gif
which is shown on the right side of
http://en.wikipedia.org/wiki/Wine_(software) ?
It's kind of cool. Hats off to
http://en.wikipedia.org/wiki/User_talk:Estemi
who put it together.
- Da
2009/4/9 Joel Holdsworth :
>> Has anyone else noticed
>> http://commons.wikimedia.org/wiki/File:History_Of_WineAppDB.gif
>> which is shown on the right side of
>> http://en.wikipedia.org/wiki/Wine_(software) ?
>> It's kind of cool. Hats off to
>> http://en.wikipedia.org/wiki/User_talk:Estemi
>> wh
> Has anyone else noticed
> http://commons.wikimedia.org/wiki/File:History_Of_WineAppDB.gif
> which is shown on the right side of
> http://en.wikipedia.org/wiki/Wine_(software) ?
> It's kind of cool. Hats off to
> http://en.wikipedia.org/wiki/User_talk:Estemi
> who put it together.
> - Dan
Yes th
Has anyone else noticed
http://commons.wikimedia.org/wiki/File:History_Of_WineAppDB.gif
which is shown on the right side of
http://en.wikipedia.org/wiki/Wine_(software) ?
It's kind of cool. Hats off to
http://en.wikipedia.org/wiki/User_talk:Estemi
who put it together.
- Dan
Hans Leidekker a écrit :
> $ for year in {2002..2008}; do \
> count=$( git log | grep ^Date: | grep $year | wc -l ); \
> echo "Number of commits in $year: $count"; \
> done
> Number of commits in 2002: 3094
> Number of commits in 2003: 3283
> Number of commits in 2004: 3851
> Number of commit
2004: 3851
> Number of commits in 2005: 6006
> Number of commits in 2006: 8431
> Number of commits in 2007: 9532
> Number of commits in 2008: 11292
>
> -Hans
>
>
I had a look at these stats as I'm (still) playing around with gitstat
in combination with Wine. T
$ for year in {2002..2008}; do \
count=$( git log | grep ^Date: | grep $year | wc -l ); \
echo "Number of commits in $year: $count"; \
done
Number of commits in 2002: 3094
Number of commits in 2003: 3283
Number of commits in 2004: 3851
Number of commits in 2005: 6006
Number of commits in 200
Just a little note to all about the appdb stats. We now have 9000
application versions in the database.
http://appdb.winehq.org/appdbStats.php
Users: 23474
Comments: 21305
Application families: 5814
Versions: 9000
Application maintainers: 1462
Test reports: 18572
Screenshots: 6234
The
Hans Leidekker wrote:
> $ for y in {2002..2007}; do \
> n=$( git log | grep ^Date: | grep $y | wc -l ); \
> echo "Number of commits in $y: $n"; \
> done
> Number of commits in 2002: 3094
> Number of commits in 2003: 3283
> Number of commits in 2004: 3851
> Number of commits in 2005: 6006
> Nu
On Tuesday 01 January 2008 21:25:02 Clarence Risher wrote:
> Because I like to nitpick, does your 2007 count include any commits to
> your local tree that arent actually submitted/accepted?
>
> On Jan 1, 2008 7:37 AM, Hans Leidekker <[EMAIL PROTECTED]> wrote:
> >
> > $ for y in {2002..2007}; do \
$ for y in {2002..2007}; do \
n=$( git log | grep ^Date: | grep $y | wc -l ); \
echo "Number of commits in $y: $n"; \
done
Number of commits in 2002: 3094
Number of commits in 2003: 3283
Number of commits in 2004: 3851
Number of commits in 2005: 6006
Number of commits in 2006: 8431
Number of
[EMAIL PROTECTED] writes:
> Web page:
>
> http://www.winehq.org/site/winapi_stats
>
> on wine statistics does not work.
Yes, winapi_extract failed to parse a file in the last release. I've
uploaded a fixed version.
--
Alexandre Julliard
[EMAIL PROTECTED]
Web page:
http://www.winehq.org/site/winapi_stats
on wine statistics does not work.
Stefan,
Please take a look at Nero website.
I use Nero 3 linux native build.
It works perfect.
Also K3b and Brasero - which are free alternatives (they have some
problems with symbolic links).
But Nero 3 is perfect.
Stefan Leichter wrote:
Am Tuesday 04 September 2007 21:27 schrieb Roderick
Am Tuesday 04 September 2007 21:27 schrieb Roderick Colenbrander:
>
> Number 4 of the list Nero has a native Linux version using GTK2. It even
> supports HDDVD and Blu-Ray. Further it used (?) to run on wine using
> wineaspi in case you were using scsi hardware/emulation.
>
> Roderick
What Nero Ver
> http://www.osalt.com/ has a list of most-requested commercial windows
> apps, currently:
>
> 1. Visio
> 2. Norton Ghost
> 3. Photoshop
> 4. Nero Burning Rom
> 5. Dreamweaver
> 6. AutoCAD
> 7. Illustrator
> 8. Access
> 9. Premiere Pro
> 10. ACDSee
Number 4 of the list Nero has a native Linux ve
Hi Dan (and wine-devel)
The list is based on the number of visits each of the product pages has on
http://www.osalt.com/ .
Thus, only products listed on the site is included on the list. The lists
shows the most visited products during the past two weeks.
Do you need the list for checking which p
Dan Kegel wrote:
> http://www.osalt.com/ has a list of most-requested commercial windows
> apps, currently:
>
> 1. Visio
> 2. Norton Ghost
> 3. Photoshop
> 4. Nero Burning Rom
> 5. Dreamweaver
> 6. AutoCAD
> 7. Illustrator
> 8. Access
> 9. Premiere Pro
> 10. ACDSee
>
> No idea how they generated
On Tuesday 04 September 2007, Dan Kegel wrote:
> http://www.osalt.com/ has a list of most-requested commercial windows
> apps, currently:
>
> 2. Norton Ghost
> 4. Nero Burning Rom
Native applications exist for both, it's pointless to have wine support either
methinks.
Cheers, Kuba
On 9/4/07, Alex Waite <[EMAIL PROTECTED]> wrote:
> I don't know exactly what versions of Ghost they hope to use, but at
> work we have an automated imaging system that reboots into Linux,
> launches Ghost via DOS emulation, reimages the machine, and then comes
> back up on the newly re-imaged windo
http://www.osalt.com/ has a list of most-requested commercial windows
apps, currently:
1. Visio
2. Norton Ghost
3. Photoshop
4. Nero Burning Rom
5. Dreamweaver
6. AutoCAD
7. Illustrator
8. Access
9. Premiere Pro
10. ACDSee
No idea how they generated that list, but it seems somewhat
reasonable. c
The web page indicating the status of the wine API:
http://www.winehq.org/site/winapi_stats
is corrupted and indicates an SQL error. I assume that there is some
information in the database corrupted:
Warning: mysql_num_fields(): supplied argument is not a valid MySQL
result resource in /home
t; Date: Mon Jan 15 13:01:42 2007 +0100
>
> oleaut32/tests: Replace some macros by functions to reduce code size and
> compile time.
Some compile stats for vartest.c on my P4 3GHz HT, 2 GB RAM, FC6,
gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
-O0 -O1 -O2 -O3 -Os
$ for y in {2002..2006}; do \
n=$( git log | grep ^Date: | grep $y | wc -l ); \
echo "Number of patches in $y: $n"; \
done
Number of patches in 2002: 3094
Number of patches in 2003: 3283
Number of patches in 2004: 3851
Number of patches in 2005: 6006
Number of patches in 2006: 8404
-Hans
Peter Åstrand wrote:
I've noticied that http://www.winehq.org/site/winapi_stats is not
quite correct. For example, it claims that "amstream" is 100%
implemented, which is not correct: There are 21 stubs or something
like that.
How is this page generated?
It only looks at functions expor
I've noticied that http://www.winehq.org/site/winapi_stats is not quite
correct. For example, it claims that "amstream" is 100% implemented, which
is not correct: There are 21 stubs or something like that.
How is this page generated?
Regards,
--
Peter Åstrand ThinLinc Chief Develop
Hello all,
while debugging one of applications I'm working on I noticed a lot
of GetPrivateProfileString calls with the same file name but in
different case causes profile code to open and parse system.ini
again. I sent a patch which helps to find a cached file in that
case and do not parse it aga
On Thursday 12 August 2004 17:31, Francois Gouget wrote:
> ./tools/winapi/winapi_extract --pseudo-stub-statistics --no-verbose --no-progress
> loader/preloader.c: 226: syntax error: 'ElfW(auxv_t) *av'
I have looked into this in the past and IIRC winapi does
it's own C parsing, but has no preproce
a call for volunteers)
Hmm, I'd just hack the preloader out of the winapi_extract script -
messy but the preloader isn't relevant for calculating API stats anyway.
And it's magic voodoo with strange constructs in several different ways,
so I vote to jettison it with a "continue if filename eq 'preloader.c'" :)
On Thu, 12 Aug 2004, Tom wrote:
> Hello,
>
> The Win API Stats page is broken in a bad way!
> See: http://www.winehq.org/site/winapi_stats
Actually I now have a cron script that updates my page regularly.
However it's been failing since 2004/06/05 witht he following error
On Thu, Aug 12, 2004 at 03:36:38AM -0400, Tom wrote:
> Hello,
>
> The Win API Stats page is broken in a bad way!
> See: http://www.winehq.org/site/winapi_stats
> I think we should just go with
> http://fgouget.free.fr/wine/winapi_stats-en.shtml
No, we should just fix it, i
Hello,
The Win API Stats page is broken in a bad way!
See: http://www.winehq.org/site/winapi_stats
I think we should just go with
http://fgouget.free.fr/wine/winapi_stats-en.shtml
and link to it. and kindly ask Francois to update it from time to time.
And it has always been far better than the
61 matches
Mail list logo
