Hi,
Recently I learned a way to have vim automatically change settings
when I'm editing wine source code:
At the bottom of my ~/.vimrc (create it if it doesn't exist):
if !exists(loaded_vimrc_autocmd)
let loaded_vimrc_autocmd=1
autocmd BufNewFile,BufRead /data/wine/* set expandtab
From: Steven Edwards [EMAIL PROTECTED]
Which is why we want to have the ambassadors project to help
new people in to wine. The thinking goes that if we have some
people to help hold the hands of new developers and the
developers that are defacto maintainers of a certain section
of code
There's a bug in MSVCRT_fgetc in 0.9.21 (likely introduced in 0.9.19) in
that it sometimes sign extends the byte read from the file. The
following program illustrates the problem:
#include stdio.h
int
main()
{
FILE *f = fopen(tmp.bin, w+);
fputc(0xe0, f);
On Sunday 24 September 2006 12:08, Ge van Geldorp wrote:
Like I said before, I have a lot of respect for Alexandres technical
abilities. But when I read comments in the Wineconf report about git:
Developers might not like it, but Alexandre does so it's a success (did I
mention I dislike git
On 9/23/06, Mirek [EMAIL PROTECTED] wrote:
Also Wine reports 64MB of video memory not 16MB
I think there shuld be option in winecfg to set this, because it is not easy to
find how anyone can do that.
http://wiki.winehq.org/UsefulRegistryKeys
Tom
Dimi Paun [EMAIL PROTECTED] wrote:
Bottom line, I don't know. At most I can say that sometimes I wish
Alexandre would be a bit more impulsive, and just let (a selected few)
things in that people want. Maybe this way we generate more excitement,
and the tiny bit of quality drop we pay with would
On 9/25/06, Tom Wickline [EMAIL PROTECTED] wrote:
On 9/23/06, Mirek [EMAIL PROTECTED] wrote:
Also Wine reports 64MB of video memory not 16MB
I think there shuld be option in winecfg to set this, because it is not easy
to
find how anyone can do that.
On Monday 25 September 2006 01:04, Tobias Ringström wrote:
There's a bug in MSVCRT_fgetc in 0.9.21 (likely introduced in 0.9.19) in
that it sometimes sign extends the byte read from the file.
Looks like 'char *i;' should be 'unsigned char *i;'.
On Sat, Sep 23, 2006 at 05:52:51AM -0700, Dan Kegel wrote:
If anyone has tips on sore spots with Wine's msxml, please
let me know.
Hi Dan,
There are lots of things that need to be done in msxml3:
Currently we have implemented some of the DOM methods, most of these
are part of the IXMLDOMNode
To check what needs to be translated I have played a bit with wrc
--verify-translation and made some HTML from it's results. As this might
interest other translators I've put the statistics at
http://pf128.krakow.sdi.tpnet.pl/wine-transl/ .
Mikolaj Zalewski
On Monday 25 September 2006 04:36, Robert Shearman wrote:
Robert Lunnon wrote:
2. Adapt the patch acceptance process to create a right of appeal where a
patch can be proven to be within the Patch Acceptance policy. Appeal
should be independent of and binding on Alexandre - this eliminates
Hi,
is Alexandre on a holiday again? Or is this to recuperate from
WineConf?
Cheers,
Paul
On Sunday 24 September 2006 00:36, Rolf Kalbermatter wrote:
Robert Lunnon [EMAIL PROTECTED] wrote:
On community, the wine project doesn't represent a community in the sense
that Wine has an altruistic purpose to provide value to that community -
It doesn't do that because the wine developer
On Saturday 23 September 2006 16:36, Dmitry Timoshkov wrote:
Jim White [EMAIL PROTECTED] wrote:
snip
Steven cited the business at Wineconf of Alexandre never being proved
wrong on a technical matter. Another straw man. The part of
Alexandre's patch process that is the root of this
From: Kai Blin
Now, getting back to the patch submission process, you're talking about a
patch management system. How would that look like, in your opinion. We
were
discussing a couple of ideas, but in the end figured that most of those
would
slow down the submission speed of patches that
On Sunday 24 September 2006 01:06, Rolf Kalbermatter wrote:
Jim White wrote:
CodeWeavers Wine version is full of patches that Alexandre won't accept
for WineHQ. Obvious proof that the Alexandre's policy isn't the only
way to make a Wine that people value. In fact it proves that the
Le lundi 25 septembre 2006 à 13:29 +0200, Mikołaj Zalewski a écrit :
To check what needs to be translated I have played a bit with wrc
--verify-translation and made some HTML from it's results. As this might
interest other translators I've put the statistics at
On Saturday 23 September 2006 16:42, Mike McCormack wrote:
The current process is crippling this project, limiting the developer
base and reducing community value. Without some healthy dissent it will
never change and get better. I am a friend of change, a true believer in
the process
On 9/25/06, Ge van Geldorp [EMAIL PROTECTED] wrote:
If there is genuine interest to make this work I could put up a few mock
webpages to get a better idea of how it would work.
See also my similar post regarding a patch system:
On Monday 25 September 2006 20:08, Ge van Geldorp wrote:
From: Steven Edwards [EMAIL PROTECTED]
Which is why we want to have the ambassadors project to help
new people in to wine. The thinking goes that if we have some
people to help hold the hands of new developers and the
developers
On 9/25/06, Dimi Paun [EMAIL PROTECTED] wrote:
On Mon, 2006-09-25 at 13:29 +0200, Mikołaj Zalewski wrote:
To check what needs to be translated I have played a bit with wrc
--verify-translation and made some HTML from it's results. As this
might interest other translators I've put the
On Mon, 2006-09-25 at 19:47 +0900, Dmitry Timoshkov wrote:
Dimi, I thought you were aware of it, and Alexandre at least at
previous WineConf stated that he accepts dubious code in cases, when
he sees that nobody works on some component: that components were
OLE/COM, DDraw/D3D, BiDi at some
Hi
Ge van Geldorp wrote:
If there is genuine interest to make this work I could put up a few mock
webpages to get a better idea of how it would work.
maybe it is worth looking at patchwork?
---
PatchWork is a web-based patch tracking system designed to facilitate the
On Mon, 2006-09-25 at 13:29 +0200, Mikołaj Zalewski wrote:
To check what needs to be translated I have played a bit with wrc
--verify-translation and made some HTML from it's results. As this
might interest other translators I've put the statistics at
maybe it is worth looking at patchwork?
---
PatchWork is a web-based patch tracking system designed to facilitate the
contribution and management of contributions to an open-source project.
Patches that have been sent to a mailing list are 'caught' by the system,
and
Dimi Paun [EMAIL PROTECTED] wrote:
In fact, I must say that the most fun I had with Wine was when Alexandre
let me run with listview a few year back. He clearly committed patches
that weren't perfect, but I appreciated that because that's how I work:
I like to do several iterations, maybe redo
On 25.09.2006 13:29, Mikołaj Zalewski wrote:
To check what needs to be translated I have played a bit with wrc
--verify-translation and made some HTML from it's results. As this might
interest other translators I've put the statistics at
http://pf128.krakow.sdi.tpnet.pl/wine-transl/ .
Nice
To check what needs to be translated I have played a bit with wrc
--verify-translation and made some HTML from it's results. As this
might interest other translators I've put the statistics at
http://pf128.krakow.sdi.tpnet.pl/wine-transl/ .
Very nice! It would be cool if we could
Troy Rollo [EMAIL PROTECTED] wrote:
If I say I've been coding since I was 14 (in those days home computers had
less than 1% penetration in Australia), in assembly language since shortly
after that and raw machine code not long after, having memorised the
instruction set, then was widely
Hi,
if (This-stateBlock != NULL ) {
if ((IWineD3DResource *)This-stateBlock-streamSource[streamNumber] ==
resource) {
TRACE(Vertex buffer released whlst bound to a state block
stream %d\n, streamNumber);
TRACE(Vertex buffer released while bound to a state block stream %d\n,
Nice one! I'll see if I can update some of the German resources.
One thing I noticed is that the message table in kernel32 is treated as
one resource in the statistics, although it contains quite a number of
strings itself. Maybe wmc can be augmented with some
--verify-translation equivalent
On 9/25/06, Mikołaj Zalewski [EMAIL PROTECTED] wrote:
Yes, I could try to do it. However I would need to know where could I
find some winehq.org pages source codes that could be used as an
example, how to send my code (also through wine-patches?) and how to
update the data files for the pages
On 9/25/06, Jeremy White [EMAIL PROTECTED] wrote:
Hmm. Now I'm worried; I've long thought this would be a Good Idea (TM),
and yet if you look at the 'live' project site (presumably the project
this was built for):
http://patchwork.ozlabs.org/linuxppc64/
It's pretty clear that it's not
Jan Zerebecki wrote:
On Fri, Sep 22, 2006 at 12:04:40PM +0100, Robert Shearman wrote:
I appreciate your attempt at solving this hard problem, but I don't
believe this is the right approach. Using winsock2 instead of Unix
sockets adds overhead in terms of wineserver calls and extra
Andrew Talbot [EMAIL PROTECTED] writes:
Changelog:
dmime: Dangling references fix.
The right way is to use wine_dbg_sprintf(%s) to allocate a copy of
the buffer to return.
--
Alexandre Julliard
[EMAIL PROTECTED]
Andrew Talbot [EMAIL PROTECTED] writes:
Changelog:
kernel32: Remove unwanted null terminator.
There's no null terminator since the array size is specified
explicitly.
--
Alexandre Julliard
[EMAIL PROTECTED]
Andrew Talbot wrote:
A formal parameter declared as an array is treated as a pointer; any size
specifier is ignored. So here, sizeof decimal_buffer, for example, would
equate to the size of a pointer to WCHAR, not to that of an array of eight
WCHARs.
Why are you doing this?
- Dan
Alexandre Julliard wrote:
Andrew Talbot [EMAIL PROTECTED] writes:
Changelog:
kernel32: Remove unwanted null terminator.
There's no null terminator since the array size is specified
explicitly.
Ah, that's interesting! I see, from KR, that if [the array's] size is
fixed, the number
Damjan Jovanovic wrote:
On 9/22/06, Robert Shearman [EMAIL PROTECTED] wrote:
Using WSAEVENTs is an interesting approach, but I'd rather see Unix
sockets being used with a thread that select's on the socket and sets a
Win32 event instead. Also, I think this amount of nesting is confusing
and
Jakob Eriksson wrote:
Jan Zerebecki wrote:
On Fri, Sep 22, 2006 at 12:04:40PM +0100, Robert Shearman wrote:
I appreciate your attempt at solving this hard problem, but I don't
believe this is the right approach. Using winsock2 instead of Unix
sockets adds overhead in terms of wineserver
Dan Kegel wrote:
Andrew Talbot wrote:
A formal parameter declared as an array is treated as a pointer; any size
specifier is ignored. So here, sizeof decimal_buffer, for example, would
equate to the size of a pointer to WCHAR, not to that of an array of eight
WCHARs.
Why are you doing this?
Andrew Talbot wrote:
A formal parameter declared as an array is treated as a pointer; any size
specifier is ignored. So here, sizeof decimal_buffer, for example, would
equate to the size of a pointer to WCHAR, not to that of an array of eight
WCHARs.
Why are you doing this?
Are you asking why
Dan Kegel wrote:
BTW the way you define the new size, as a magic constant, seems
bad. Can you use 4 * sizeof(WCHAR), or whatever, instead of 8?
And even then, the '4' seems almost as bad.
- Dan
Yes, I did feel uneasy about using a magic constant, I must admit. Another
way to handle it would
On Tuesday 26 September 2006 00:16, Jeremy White wrote:
Hmm. Now I'm worried; I've long thought this would be a Good Idea (TM),
and yet if you look at the 'live' project site (presumably the project
this was built for):
http://patchwork.ozlabs.org/linuxppc64/
It's pretty clear that it's
On Monday 25 September 2006 19:47, n0dalus wrote:
At the bottom of my ~/.vimrc (create it if it doesn't exist):
if !exists(loaded_vimrc_autocmd)
let loaded_vimrc_autocmd=1
autocmd BufNewFile,BufRead /data/wine/* set expandtab tabstop=8
softtabstop=4
endif
You might want to add
Hi,
Dmitry Timoshkov wrote:
How many projects have you ever participated in? Every developers'
mailing list
of an open source I personally participated in *doesn't guarantee* not
only patch
acceptance, but even a reply with explanations why the patch has been
silently
dropped, and it
On Monday 25 September 2006 23:05, Robert Lunnon wrote:
On Saturday 23 September 2006 16:42, Mike McCormack wrote:
Since you know better, how about maintaining your own Wine tree and
showing us how it's done?
Self evidently thats what I have to do until some core functionality
patches find
On 9/25/06, jimtabor [EMAIL PROTECTED] wrote:
Every Wine developer needs to read this,
http://www.codeweavers.com/services/ and
http://www.codeweavers.com/services/wine .
I'm a Wine developer, and I don't work for codeweavers. Why should I read that?
It is your job to provide support for
Roderick, Mesa calls the extension GL_EXT_blend_minmax, and so does
the spec. I don't know what exactly uses the min_max form. Is this a
typo?
Apart from the blend_minmax typo, it appears to be me this patch has
some other problems.
This patch changes the detection extension detection for
James Hawkins wrote:
On 9/25/06, jimtabor [EMAIL PROTECTED] wrote:
Every Wine developer needs to read this,
http://www.codeweavers.com/services/ and
http://www.codeweavers.com/services/wine .
I'm a Wine developer, and I don't work for codeweavers. Why should I
read that?
You don't
On 9/25/06, jimtabor [EMAIL PROTECTED] wrote:
James Hawkins wrote:
On 9/25/06, jimtabor [EMAIL PROTECTED] wrote:
Every Wine developer needs to read this,
http://www.codeweavers.com/services/ and
http://www.codeweavers.com/services/wine .
I'm a Wine developer, and I don't work
Wow, just like that!
James Hawkins wrote:
It is shocking to most FOSS code writers that maybe this is a real,
truly, paid for project. No! It can not be! I contribute to someones
profit? NOO~~~!.
The above is a famous quote I read from Linux Journal magazine.
I am well aware that
jimtabor [EMAIL PROTECTED] wrote:
First, he doesn't represent Codeweavers on the wine-devel mailing
list. Second, there's nothing unprofessional about his actions.
Missed my point! If his address has [EMAIL PROTECTED], than yes,
that person does represent that organization.
Then check
On 9/25/06, jimtabor [EMAIL PROTECTED] wrote:
Every Wine developer needs to read this,
http://www.codeweavers.com/services/ and
http://www.codeweavers.com/services/wine .
What do these two pages have to do with Wine's Governance ?
It is your job to provide support for this product, I spend
I don't have any real reason to have a say in this (as someone who
hasn't successfully made any changes to the wine tree, for which I
blame my inability to contribute anything that belongs there rather
than any problems with the current system), but I was just thinking
that Patch management
55 matches
Mail list logo
