On Thu, Dec 17, 2009 at 2:07 PM, Dan Kegel wrote:
> On Thu, Dec 17, 2009 at 12:06 PM, Eric Pouech wrote:
>> we don't need to support several grammar compiler in wine
>> yacc/bison is way sufficient
yow, we already have eight parsers written in bison in wine.
bison it is, then.
Hi Frédéric,
Using "absence" and "installé" in the same sentence doesn't sound right.
Something like "L'envoi de courriel a échoué car vous n'avez pas de
client mail MAPI installé." or "L'envoi de courriel a échoué du fait
de l'absence de client mail MAPI." should be simpler and more correct.
--
Eric Pouech writes:
> do you recommend this way of doing being the recommanded way for all
> the thunks which have been recently added
> ie assuming the app will only provide a limited number of functions
> being passed to the thunks, rather than trying to allocate/free the
> thunks when possible
Hi,
Here's a new patch for review. I won't send it until Monday because I want to
do some performance testing(see below), and because the ddraw patch is queued
below that, but it needs more testing.
The changes are essentially some bugfixing(one NULL pointer exception), and I
dropped the opti
On Thu, Dec 17, 2009 at 12:06 PM, Eric Pouech wrote:
> we don't need to support several grammar compiler in wine
> yacc/bison is way sufficient
> but I agree that using a real grammar to rewrite cmd would be a real gain.
> current code is unmaintainable as it is
For what it's worth, antlr generat
On Thu, Dec 17, 2009 at 1:25 PM, Jason Green wrote:
> We both work for TransGaming, and these patches are officially from the
> company.
>
Ok, thanks for the info!
We both work for TransGaming, and these patches are officially from the company.
On Dec 17, 2009, at 4:22 PM, James Hawkins wrote:
> On Thu, Dec 17, 2009 at 1:19 PM, Jason Green wrote:
>> Sorry, should have copied Eric van Beurden on this earlier. His name &
>> email are in the patch on the Fr
On Thu, Dec 17, 2009 at 1:19 PM, Jason Green wrote:
> Sorry, should have copied Eric van Beurden on this earlier. His name & email
> are in the patch on the From: line.
>
To clarify my question, are you guys working at a company that is
contributing to Wine, or are you contributing for fun, etc
Sorry, should have copied Eric van Beurden on this earlier. His name & email
are in the patch on the From: line.
On Dec 17, 2009, at 4:07 PM, James Hawkins wrote:
> On Thu, Dec 17, 2009 at 12:56 PM, Jason Green wrote:
>> Yeah, I was just forwarding this from one of our other internal developer
On Thu, Dec 17, 2009 at 12:56 PM, Jason Green wrote:
> Yeah, I was just forwarding this from one of our other internal developers.
> I just went back and noticed that he had a note here which said, "This patch
> isn't really necessary, and could be left off the submission to WineHQ."
>
I'm jus
Jason Green a écrit :
I don't think it's a good idea to change the exception structure passed
by the caller to the minidump creation
it's better to hard wire the optimization in dump_exception_info
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate
Yeah, I was just forwarding this from one of our other internal developers. I
just went back and noticed that he had a note here which said, "This patch
isn't really necessary, and could be left off the submission to WineHQ."
:-)
On Dec 17, 2009, at 3:46 PM, Juan Lang wrote:
> Hi Jason,
>
>
Hi Jason,
-static const ABC nil;
+static const ABC nil = {0};
This has no effect, as static variables are implicitly initialized to
0 anyway. It might be a little less surprising this way..
--Juan
On Wed, Dec 16, 2009 at 12:56 PM, Dan Kegel wrote:
> http://kegel.com/wine/valgrind/logs/2009-12-16-09.22.errs.txt
> 38 Invalid read of size 2
> 49 Invalid read of size 4
> 54 Conditional jump or move depends on uninitialised value
> 734 XXX bytes in XXX blocks are definitely lost
>
Alexandre Julliard a écrit :
Eric Pouech writes:
Alexandre Julliard a écrit :
Module: wine
Branch: master
Commit: dcec342b50524562844f64d43d423ed2c83c1f97
URL:
http://source.winehq.org/git/wine.git/?a=commit;h=dcec342b50524562844f64d43d423ed2c83c1f97
Author: Alexandre Julliard
D
Dan Kegel a écrit :
On Thu, Dec 17, 2009 at 4:03 AM, Henri Verbeet wrote:
2009/12/17 Dan Kegel :
The two problems are not unrelated. It's possible that
finding somebody willing to use antlr would be easier
than finding somebody willing to use yacc or write it
from scratch.
Fo
Am 17.12.2009 um 20:20 schrieb Luke Benstead:
> Luke.
> <0001-ddraw-Fix-an-incorrect-refcount-test.txt>
This patch is correct. The test intends to test DDraw7, there's a DDraw4 test
below. So the variable name was wrong, not the macro.
On 12/17/2009 06:26 PM, Alexandre Julliard wrote:
Paul Vriens writes:
That's just hiding the problem, an app can pass the same structure.
So the 'users' should be fixed?
We need to define a platform-independent struct for marshalling that
data across processes anyway, we can't blindly send
Paul Vriens writes:
>> That's just hiding the problem, an app can pass the same structure.
>
> So the 'users' should be fixed?
We need to define a platform-independent struct for marshalling that
data across processes anyway, we can't blindly send the structure.
--
Alexandre Julliard
julli...@
On 12/17/2009 05:27 PM, Alexandre Julliard wrote:
Paul Vriens writes:
Fixes some Valgrind warnings.
Changelog
Initialize an APPBARDATA struct (Valgrind)
That's just hiding the problem, an app can pass the same structure.
So the 'users' should be fixed?
--
Cheers,
Paul.
Paul Vriens writes:
> Fixes some Valgrind warnings.
>
> Changelog
> Initialize an APPBARDATA struct (Valgrind)
That's just hiding the problem, an app can pass the same structure.
--
Alexandre Julliard
julli...@winehq.org
Jeremy White writes:
>> It looks like a good place to use broken().
>
> I don't think it's broken on win98; it looks as though
> they do 4 byte alignment prior to the data structure in win9x,
> and winnt and on seem to do 8 byte alignment prior to the
> data chunk. That results in a 4 byte diff
On Thu, Dec 17, 2009 at 4:03 AM, Henri Verbeet wrote:
> 2009/12/17 Dan Kegel :
>> The two problems are not unrelated. It's possible that
>> finding somebody willing to use antlr would be easier
>> than finding somebody willing to use yacc or write it
>> from scratch.
>>
> For a potential new cont
On Wed, Dec 16, 2009 at 08:06:32PM +0100, Jacek Caban wrote:
> On 12/16/09 7:50 PM, Marcus Meissner wrote:
> >On Wed, Dec 16, 2009 at 07:30:22PM +0100, Paul Vriens wrote:
> >>On 12/15/2009 09:16 PM, Jacek Caban wrote:
> >>>---
> >>>dlls/urlmon/binding.c | 6 +
> >>>dlls/urlmon/tests/url.c | 58 +
2009/12/17 Dan Kegel :
> The two problems are not unrelated. It's possible that
> finding somebody willing to use antlr would be easier
> than finding somebody willing to use yacc or write it
> from scratch.
>
For a potential new contributor possibly, but I doubt that's true for
most existing Wine
On Thu, Dec 17, 2009 at 3:05 AM, Henri Verbeet wrote:
>> If it's not ok to require Java to build (and I could imagine that),
>> we could check in ANTLR's output. Then only people
>> hacking on cmd would need java installed.
>
> Well, at least Alexandre as well, and I could imagine distributions
>
2009/12/17 Dan Kegel :
> On Thu, Dec 17, 2009 at 2:43 AM, Henri Verbeet wrote:
>> That needs Java.
>
> But only when generating the parser. It can output a pure C parser.
>
> If it's not ok to require Java to build (and I could imagine that),
> we could check in ANTLR's output. Then only people
On Thu, Dec 17, 2009 at 2:43 AM, Henri Verbeet wrote:
> 2009/12/17 Dan Kegel :
>> I wonder if http://www.antlr.org/ would be overkill for generating
>> the parser. It does support generating C... might be a fun
>> thing to try, anyway. ANTLR does seem to be the most popular
>> parser generator
2009/12/17 Dan Kegel :
> I wonder if http://www.antlr.org/ would be overkill for generating
> the parser. It does support generating C... might be a fun
> thing to try, anyway. ANTLR does seem to be the most popular
> parser generator these days.
>
That needs Java.
On Thu, Dec 17, 2009 at 1:57 AM, Dan Kegel wrote:
> There are lots of bugs filed for little (or big) problems in wine's cmd
> that involve parsing the command language:
>...
> The existing parser in cmd is pretty weak. I wonder if it might not
> be time to write a new parser -- either using some
There are lots of bugs filed for little (or big) problems in wine's cmd
that involve parsing the command language:
21047 cmd does not handle for %%a in ('command')
21046 cmd does not handle all operators in 'if' command
20161 cmd can't handle echo commands containing quotes and redirection
1
On Wed, Dec 16, 2009 at 5:13 PM, James Hawkins wrote:
> On Wed, Dec 16, 2009 at 5:07 PM, Lei Zhang wrote:
>> Hi, this is for bug 21045.
>>
>
> + SecurePackage *prev_package = NULL;
> LIST_FOR_EACH_ENTRY(package, &packageTable->table,
> SecurePackage, entry)
> {
> +
On 12/15/2009 11:40 AM, Paul Vriens wrote:
On 12/13/2009 12:59 AM, Vincent Povirk wrote:
Hi Vincent,
It appears that this one introduced a test failure:
http://test.winehq.org/data/tests/gdiplus:image.html
One of the tests that fails now (line 533) was there for a long time
it's just that
33 matches
Mail list logo
