Re: [PATCH] cmd/tests: If we rewind to the beginning of the line, don't increment line number.
On Mon, Mar 26, 2012 at 10:13, Christian Costa wrote: > If some particular cases, a bias is introduced in the line number which make > error message > mismatch the content of the .exp file. This patch fixes that. > --- > programs/cmd/tests/batch.c | 4 I guess this should be marked as a prerequisite to/included in your new attrib patches list Frédéric
Re: GSoC proposal
--- On Mon, 26/3/12, Aric Stewart wrote: > Hi, > > Not to argue if it will be useful or not, as I do not know. > I think this > will be technically very hard. You will have to be able to > get the > keystrokes for a native linux applications feed them into > WINE, have > wine do the IME processing and then get the resulting > characters and > feed them back into the native linux application. This > pipeline is not > trivial. Getting arbitrary microsoft or 3rd-party input methods to work with Wine (for windows application under wine) would be an interesting project. Getting arbitrary microsoft or 3rd-party windows input methods to be useable by native [unix] applications would be less useful - and as you wrote, rather troublesome for the sake of it. I would have to say, the perceived problem with ibus/fcitx/whatever's pinyin implementation is simply failing to naming the issue correctly: it is not that the pinyin implementation on Linux/X11 is poor, but that an entire generic input mechanism (which applies to both pronounciation/pinyin-based methods, as well as shape-decomposition-based methoids like Cangjie) that of predictive/anticipatory/auto-completion, is missing. If you cannot name and describe the issue correctly, you are simply "barking up the wrong tree", as the saying goes. Also, it is not true that such feature is entirely missing. The Japanese had done some very interesting work in anticipatory XIM inputs based on dictionaries (the typical linux installation actually ships several, from time to time), and I believe that the Taiwan people had done similar as well (these are available more under niche localized linux distributions); one problem is that those technical development has so far largely stayed localized - native-speaking linux/X11 people know where to find them, but have very little incentive or patience of pushing those technical developments back and integrating them into the western/English-speaking world. > Additionally, you have not explained how this will benefit > WINE. I can > forsee none of the above pipeline being accepted into or > applicable to > WINE presently, at lest in theory, i have done work that > allows native > XIM clients to be able to work in wines IME framework, so if > a user > really wants to use windows XIM in wine they should work. > The setup is > tricky but in all my years of working on wine IME i have > never heard of > a user wanting that. Almost all requests are to make > the Linux/Mac > Input Methods work better in WINE. > > I would love to have you work on improving IME and XIM > integration in > WINE, but i think the main goal of the project is pretty > tangential to wine. Yes, I agree "make the Linux/Mac Input Methods work better in WINE", or just "make the Linux/Mac Input Methods work better" are desired. Actually an ibus<->google-chinese bridge would be interesting, but that's completely othorgonal and unrelated to wine. (except in the sense that wine itself is one X11 application among many).
Re: Need suggestion to choose a GSoC idea
Qian, - Improve Wine App install / App running testing This idea is similar with Austin's early work [18], my idea is using sikuli [19] instead of autohotkey, since sikuli is more powerful for complex work. Sikuli using tesseract as orc engine, so if we done this job we can prevent many font relate regression as well. I already asked Austin about that for my GSoC proposal: > in short, I think this effort is best spent somewhere else. GUI > testing is really hard to get right, and very expensive(time, effort, > disk space, cpu power, etc.). I've since decided against GSoC for this year, but my idea revolved around improving cmd's parser, notably getting Firefox/Chromium and/or other software to build under wine (or at least, isolate potential/existing issues to non-cmd parts). I was partway through fixing http://bugs.winehq.org/show_bug.cgi?id=21174 Dan Kegel seemed pretty interested in the project. If you're interested you could e-mail him. Alex -- Not sent from my iPhone, Windows Phone, or Blackberry; Just an old-fashioned e-mail client.
Need suggestion to choose a GSoC idea
Hi all, I'm a student in Department of Mathematics, Sun Yat-sen University. My irc nick name is fracting, my real name is Qian Hong. I'm in GMT+8 time zone, availible on 10:00 to 18:00 (GMT+8) on #winehackers. I know C/bash and some Linux skills. Currently I'm an intern in Redhat, working in the kernel-qe group. I have great interesting in the Wine project. Last year I spent most of my spare time on reporting bugs to Wine. When I doing this I found lots of bugs regarding Chinese software have beem complained in local Linux forum for years but no one reported them to Wine project. In other words, I found most Chinese Linux users didn't report bugs to open source projects, well, I think that is a bug too :) After reported 100+ bugs, I'm surprised so many bugs have been fixed in just one year. I wish I can do some more then reporting bugs for Wine project, great if I can get start with the 2012 GSoC and keep submitting patches to Wine after that. I have lots of ideas in my TODO list, unfortunately most of them might too hard to do as a GSoC project. Anyway, I'll post my ideas here, wait for feedbacks, choose one of them as my GSoC idea, and leave others as my job in the coming years. Certainly I'm glad to see any others working on those ideas :) Here is my list: - Implement ndis.sys This idea come from the off-standard network authentication in China. Lots of Universities in China using some off-standard network authentication methods for campus network connection, the authentication protocols are usually private and changed frequently, the authentication clients are usually Windows-only. This issue is the main blocker for students in those Universities to change to Linux desktop or Mac. I've filed some bugs regarding some network authentication clients, such as [1],[2],[3],[4],[5]. However, even the above bugs are fixed, these clients might not work on wine because they depends on ndis.sys which is not implemented yet. As an intern in Redhat network-qe group focus on NIC testing, I have great interesting in implement ndis.sys, though I think it is too hard for a GSoC project. The ndiswrapper code is a great resource but not complete, also I known ReactOS project has a ndis.sys too but obviously it won't work on Wine. Is it allowed to read ReactOS implementation to learn how things work? Anyway I'm interesting in what you think :) - Implement/improve wpcap proxy This idea is similar with the first one, in fact André H has already done the most important part [6],[7]. I hope André's patch will be accepted, and I'm interesting in improving it. I have done some proof-of-concept to show that some kinds of network auth client wich depends on winpcap will work on wine with André's patch. - Improve builtin iexplore This idea is come from another main blocker for using Linux/Mac in China. Most Chinese online banks are ie-only, depends on ActiveX and some ie-only style JavaScript or even VBScript. Jacek and other wine developers has done lots of work on them, and I'm interesting in participating. I've filed 40+ bugs regarding online bank support with Wine [8]. My goal is to make wine builtin iexplore works for as many online banks, currently I have more then 6 different online bank accounts for testing, guys in openbank-discuss group [9] will help on testing too. - Improve USB support Yeah, this might be another idea which is too hard for a GSoC project. We already have a third party patch, I wonder will Wine-1.6 have official USB support? This idea is similar with the above one, my goal is to solve the online bank USB-key issues. After testing on 8 different USB-keys with the USB patch [10], I noticed they won't work on wine without hidusb.sys. ReactOS project has implement hidusb.sys in the last few months, again, is it allow to learn ReactOS code if I would like to contribute to Wine? - Improve Wine CJK font support The main idea is fix Bug 16325 [11], Aric and others have done a lot of work on it, and I'm glad to participating too. I think the main blocker for Wine CJK font support is Font Association now, is it suitable for a GSoC project? Also I've filed some other Wine font bugs [12],[13],[14],[15],[16], I'm happy to working on them. - Improve Wine font test case This idea is similar with the above one, however, instead of fixing real bugs, this idea is to prevent new bugs(regression). As having filed 100+ bugs I know the pain of doing regression test if we can't script the test, this happens on font related bugs. The main idea is to integrate an OCR engine to wine testcase, use ORC method to detect whether the fonts display correctly. We already have very good open source ORC engine [17] which is in Apache License. However tesseract-ocr is written in C++ an I am worring that will not be integrated to Wine code tree. - Improve Wine App install / App running testing This idea is similar with Austin's early work [18], my idea is using sikuli [19] instead of autohotkey, since sikuli
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
On 03/26/2012 08:15 AM, Alexandre Julliard wrote: Vitaliy Margolen writes: On 03/26/2012 06:14 AM, Alexandre Julliard wrote: Dmitry Timoshkov writes: This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass on a system without XInput2. It will break dinput, we rely on the clip rectangle being reset. I'd say it again, dinput should not warp mouse under any circumstances. Also, there is such a thing as non-exclusive background mode. I fail to see how this is relevant here, care to explain? If Dmitry fixes a real bug that means dinput shouldn't depend on broken behavior. And I'm questioning that exact behavior which shouldn't have been there in the first place. Dinput's exclusive mode works regardless of what ClipCursor is set to. Vitaliy.
Fwd: Student Proposals Now Being Accepted for Google Summer of Code
I'm still missing some people who haven't signed up as mentor yet. To all students, I hope you discussed your ideas on the mailing list and/or irc, good luck submitting your proposal! :D Originele bericht Onderwerp: Student Proposals Now Being Accepted for Google Summer of Code Datum: Mon, 26 Mar 2012 15:27:05 -0700 Van:Carol Smith Antwoord-naar: google-summer-of-code-announce+own...@googlegroups.com Aan:Google Summer of Code Announce Hi there, We are pleased to announce that we are now accepting applications from students to participate in Google Summer of Code 2012. Please check out the FAQs [1], timeline [2], and student manual [3] if you are unfamiliar with the process. The deadline to apply is April 6, 2012 at 19:00 UTC [4]. Late proposals will not be accepted for any reason. [1] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs [2] - http://www.google-melange.com/gsoc/events/google/gsoc2012 [3] - http://www.booki.cc/gsocstudentguide/ [4] - http://goo.gl/xiKC2
Re: Web based translation tool
On Mon, Mar 26, 2012 at 16:23, Michal Čihař wrote: >> With some sort of merging of commits >> things get more complex. > > It turned out such feature seems to be important for more projects, so I > will end up implementing some way of merging of commits for 1.0. > Details can be found at https://github.com/nijel/weblate/issues/16 I don't know how your tool/system exactly works, so my comment may be a bit naive/wrong, but instead of merging commits, couldn't there be instead (or as a complement) some kind of session/transaction system where a user translates a number of msgids, then sort of "commits" its changes to close the session/transaction, which would trigger the git commit creation? That would (help) limiting the # of git commits created IMO, at the cost of some additional complexity Frédéric
[GSoC] participate and contribute in opensource community
Sir, I am Naren Krishna, I am students of CSE, I have some background in c++ and I have been using wine to run *.exe files in ubuntu. I want to help improve this software as this is a very good software, what do you expect from one. Please guide me, tell me if you want some bugs to be fixed. sincerely, Naren Krishna
Re: GSoC proposal
--- On Mon, 26/3/12, Cheer Xiao wrote: > > What you are describing is the desirability of > predictive and phrasal input > > methods in general, where the computer can anticipate > and guess your > > intention as you type. > > > > We only disagree in the definition of what a "decent" IME > is. By > decent I meant a decent phrasal or sentence IME. Because > given the > large amount of homophones in Chinese a bare pinyin IME is > barely > usable. The first step of addressing a problem is to name and describe it correctly. Since predictive and phrasal input algorithms (and allowing fuzzy input) is not specific to pinyin - or pronounciation-based input methods, which the Japanese is also mostly based on - but also applies to shape-decomposition-based input methods like Cangjie. The majority of pinyin-based input methods are "correct" and complete for what they claim to do, namely translating from sound to words, but not useable. > > For what it is worth, you are forgetting two entire > "areas" of people. > > Taiwan/Hong Kong had always been far more > computer-literate than Mainland, > > so your "80% won't bother to learn another" is a gross > mis-statement in both > > quantity and quality. Due to different dialects and > other reasons, Cangjie > > (rather than Pinyin) had been far more popular with > Chinese users. But even > > with Cangjie (which is shape/writing-based, rather than > sound-based, thus > > getting around the dialect problem), predictive and > phrasal input methods > > are desirable. > > > > I declared that I was talking about the situation in > mainland China in > the beginning - I should have emphasized that along the way. > But by > declaring Cangjie is far more popular, you are ignoring the > mass > majority of people in mainland China. Again, I won't be able > to > convince you that the majority won't bother to learn another > IME, even > in highly computer-literate places like CS departments in > universities. Arguing about facts is plainly meaningless. You have completely ignore the historical context. Cangjie was the first input method which had a majority usage among ethnic Chinese users. That was in the 80's. It is a known fact that at that time, Mainland had just gotten out of the cultural revolution, and not in the best shape in general education, let alone technical areas, or access to computers or the internet. (in fact it is arguable about the last point even now, but I'll let that pass). Since reliable statistics does not exist - and the Chinese government won't allow it - any claims on majority or percentage of usage is null and void, honestly. You only speak for your own preference. > Yes, but "just works" is not the same thing as "usable". You have again lost my point: pinyin is not the missing part in Linux/X11's chinese input support. Predictive/anticipative/auto-completion phrasal input algorithm is. And predictive/anticipative/auto-completion phrasal input algorithm can be used in combination with non-pronounciation-based (i.e. non-pinyin-based) mechanism, such as Cangjie, which is shape-decomposition-based.
Re: My GSoC 2012 proposal
>> * Compatibility and exchange of installation recipes with other >> frontends like PlayOnLinux >> * Winetricks and AppDB integration. A way to mirror in AppDB the >> dependencies and workarounds employed by winetricks recipes. > > Winetricks is not a mentoring organization for Google Summer of Code. > That said, it theoretically could be under Wine's umbrella (as I did > with Appinstall, which did gui testing in 2009), but I think most > would rather see work done on Wine directly. Is this the general feeling of the list, e.g. would it be a waste of time to craft a proposal involving winetricks?
Re: My GSoC 2012 proposal
About the joystick configuration tool proposal. My plans are: * Start development as a standalone program, and then include it in the control panel * Enumerate all the joysticks with dinput * Simple windows GUI. Prototypes are here http://dl.dropbox.com/u/2701879/wiki/gsoc/dialog1.png (main screen) and here http://dl.dropbox.com/u/2701879/wiki/gsoc/dialog2.png (visualization/calibration). I don't know how I could draw the axis and buttons to give the visual feedback, I guess it's something to do with GDI? Or maybe embbeded pictures in the dialog? * Show supported force feedback devices and provide some controls for testing/setting it * Write settings to registry after user confirms calibration. * jscal stores the calibration settings in a file so it's probably enough to have an "Import calibration" option and read from this file. * Use the linux sysfs interfaces to get vid/pid and automatically detect "duplicate" drivers (this is extra but I think could be useful) Also I've yet to try to configure force feedback on linux with my joysticks so I can take a look at the ff bugs.
Regarding Gsoc 2012
I am Prateek Papriwal, a second year undergraduate student persuing Bachelors in Technology in the Indian Institute of Technology Delhi, in the department of Electrical Engineering. I love programming in C . I was told about GSOC 2012 by one of my seniors, who saw passion for coding in me. I traversed through the previous year list of organisations and thereby Wine caught my attention , through which we can install and run windows appplication in other operating systems as we do in our windows . For the last few weeks i have been going through the working of Wine and have gone through some of its modules.i am also using wine for running uTorrent application. I have done a course CSL 101 "Programming in C" in which i have several algorithms using C . I have gone through the ideas page and found "System Management - WMI support" very interesting . Relevant Courses taken: CSL 201 : Data Structures And Algorithms -- Object Oriented Programming, Trees Implementation , Sorting Techniques , Graph Theory ... *Involvement in Open Source Organisation* CMU Sphinx(SVN Repository) RAXA JSS EMR(Git Repository) -- https://raxaemr.atlassian.net/wiki/display/RAXAJSS/Voice+Module+Project Sympy (GIT Repository)
Re: PDB format documentation.
On Sun, 25 Mar 2012 05:24:45 -0300, Svyatoslav Kuzmich wrote: Hello dear Wine mailing list! I've found that Wine dbghelp.dll includes PDB file parser. Does anyone know where I can find documentation of PDB internal structure? http://undocumented.rawol.com/ May have parts of the info you want. Roald
Re: Web based translation tool
Hi Dne Mon, 19 Mar 2012 10:52:58 +0100 Michal Čihař napsal(a): > For the projects where I use Weblate I don't consider this as an issue > as merging commits would probably cause more problems than it would > solve. With current approach, you simply merge weblate branch to master > and everything works nicely. With some sort of merging of commits > things get more complex. It turned out such feature seems to be important for more projects, so I will end up implementing some way of merging of commits for 1.0. Details can be found at https://github.com/nijel/weblate/issues/16 -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: msi: Implement MSIMODIFY_MERGE function in TABLE_modify.
El 26 de marzo de 2012 13:38, Marvin escribió:
> Hi,
>
> While running your changed tests on Windows, I think I found new failures.
> Being a bot and all I'm not very good at pattern recognition, so I might be
> wrong, but could you please double-check?
> Full results can be found at
> http://testbot.winehq.org/JobDetails.pl?Key=17479
>
> Your paranoid android.
>
>
> === WNT4WSSP6 (32 bit db) ===
> db.c:1079: Test failed: MsiViewModify failed
>
> === W2KPROSP4 (32 bit db) ===
> db.c:1079: Test failed: MsiViewModify failed
>
> === WXPPROSP3 (32 bit db) ===
> db.c:1079: Test failed: MsiViewModify failed
>
> === W2K3R2SESP2 (32 bit db) ===
> db.c:1079: Test failed: MsiViewModify failed
>
> === WVISTAADM (32 bit db) ===
> db.c:1079: Test failed: MsiViewModify failed
>
> === W2K8SE (32 bit db) ===
> db.c:1079: Test failed: MsiViewModify failed
>
> === W7PRO (32 bit db) ===
> db.c:1079: Test failed: MsiViewModify failed
>
> === W7PROX64 (32 bit db) ===
> db.c:1079: Test failed: MsiViewModify failed
>
> === TEST64_W7SP1 (32 bit db) ===
> db.c:1079: Test failed: MsiViewModify failed
>
> === W7PROX64 (64 bit db) ===
> db.c:1079: Test failed: MsiViewModify failed
>
> === TEST64_W7SP1 (64 bit db) ===
> db.c:1079: Test failed: MsiViewModify failed
>
In my checkout there was several errors before applying the path and I
didn't noticed this one. The primary key 2 is used later in the test and
changing it to a value that's not used later is enough. The diff with the
respect of the previous patch is:
diff --git a/dlls/msi/tests/db.c b/dlls/msi/tests/db.c
index f5a3c1e..4c91bd8 100644
--- a/dlls/msi/tests/db.c
+++ b/dlls/msi/tests/db.c
@@ -935,7 +935,7 @@ static void test_viewmodify(void)
/* try merging a new record */
hrec = MsiCreateRecord(3);
-r = MsiRecordSetInteger(hrec, 1, 2);
+r = MsiRecordSetInteger(hrec, 1, 10);
ok(r == ERROR_SUCCESS, "failed to set integer\n");
r = MsiRecordSetString(hrec, 2, "pepe");
ok(r == ERROR_SUCCESS, "failed to set string\n");
--
Andoni Morales Alastruey
LongoMatch:The Digital Coach
http://www.longomatch.ylatuya.es
From 35e285d72ee3e481e624fbb04d66d5993379fc53 Mon Sep 17 00:00:00 2001
From: Andoni Morales Alastruey
Date: Mon, 19 Mar 2012 23:19:17 +0100
Subject: [PATCH] msi: implement MSIMODIFY_MERGE function in TABLE_modify
---
dlls/msi/table.c| 15 +--
dlls/msi/tests/db.c | 24
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/dlls/msi/table.c b/dlls/msi/table.c
index d37947e..852124e 100644
--- a/dlls/msi/table.c
+++ b/dlls/msi/table.c
@@ -1766,7 +1766,7 @@ static UINT TABLE_modify( struct tagMSIVIEW *view, MSIMODIFY eModifyMode,
MSIRECORD *rec, UINT row)
{
MSITABLEVIEW *tv = (MSITABLEVIEW*)view;
-UINT r, column;
+UINT r, frow, column;
TRACE("%p %d %p\n", view, eModifyMode, rec );
@@ -1811,8 +1811,19 @@ static UINT TABLE_modify( struct tagMSIVIEW *view, MSIMODIFY eModifyMode,
r = msi_table_assign( view, rec );
break;
-case MSIMODIFY_REPLACE:
case MSIMODIFY_MERGE:
+/* check row that matches this record */
+r = msi_table_find_row( tv, rec, &frow, &column );
+if (r != ERROR_SUCCESS)
+{
+/* if the record was not found, validate it and insert it */
+r = table_validate_new( tv, rec, NULL );
+if (r == ERROR_SUCCESS)
+r = TABLE_insert_row( view, rec, -1, FALSE );
+}
+break;
+
+case MSIMODIFY_REPLACE:
case MSIMODIFY_VALIDATE:
case MSIMODIFY_VALIDATE_FIELD:
case MSIMODIFY_VALIDATE_DELETE:
diff --git a/dlls/msi/tests/db.c b/dlls/msi/tests/db.c
index d33eb0c..4c91bd8 100644
--- a/dlls/msi/tests/db.c
+++ b/dlls/msi/tests/db.c
@@ -923,6 +923,30 @@ static void test_viewmodify(void)
r = MsiViewModify(hview, MSIMODIFY_INSERT_TEMPORARY, hrec );
ok(r == ERROR_FUNCTION_FAILED, "MsiViewModify failed\n");
+/* try to merge the same record */
+r = MsiViewExecute(hview, 0);
+ok(r == ERROR_SUCCESS, "MsiViewExecute failed\n");
+r = MsiViewModify(hview, MSIMODIFY_MERGE, hrec );
+ok(r == ERROR_SUCCESS, "MsiViewModify failed\n");
+
+r = MsiCloseHandle(hrec);
+ok(r == ERROR_SUCCESS, "failed to close record\n");
+
+/* try merging a new record */
+hrec = MsiCreateRecord(3);
+
+r = MsiRecordSetInteger(hrec, 1, 10);
+ok(r == ERROR_SUCCESS, "failed to set integer\n");
+r = MsiRecordSetString(hrec, 2, "pepe");
+ok(r == ERROR_SUCCESS, "failed to set string\n");
+r = MsiRecordSetString(hrec, 3, "7654321");
+ok(r == ERROR_SUCCESS, "failed to set string\n");
+
+r = MsiViewModify(hview, MSIMODIFY_MERGE, hrec );
+ok(r == ERROR_SUCCESS, "MsiViewModify failed\n");
+r = MsiViewExecute(hview, 0);
+ok(r == ERROR_SUCCESS, "MsiViewExecute failed\n");
+
r = MsiCloseHandle(hrec);
ok(r == ERROR_SUCCESS, "failed to close record\n");
--
1.7.5.4
Re: [PATCH] implement MSIMODIFY_MERGE function in TABLE_modify
El 26 de marzo de 2012 11:48, Andoni Morales escribió:
> El 26 de marzo de 2012 11:28, Hans Leidekker escribió:
>
> On Mon, 2012-03-26 at 11:14 +0200, Andoni Morales wrote:
>> > -case MSIMODIFY_REPLACE:
>> > case MSIMODIFY_MERGE:
>> > + /* check for a duplicated key */
>> > + r = msi_table_find_row( tv, rec, &row, column );
>> > + if (r == ERROR_SUCCESS) {
>> > +/* check that both are identical */
>> > +r = compare_record (tv, row, rec);
>> > +if (r != ERROR_SUCCESS)
>> > + break;
>> > + } else {
>> > +r = table_validate_new( tv, rec, NULL );
>> > +if (r != ERROR_SUCCESS)
>> > + break;
>> > +r = TABLE_insert_row( view, rec, -1, FALSE );
>> > + break;
>> > + }
>> > +
>> > +case MSIMODIFY_REPLACE:
>>
>> Please use bracketing and indentation style of the surrounding code.
>> Some tests would be nice.
>>
>
Updated patch with tests, which revealed bugs in the previous pathc :)
Cheers,
Andoni
>
>>
> Sorry, I attached the wrong patch file. I have fixed the indentation and
> will add tests too.
>
>
>
> --
> Andoni Morales Alastruey
>
> LongoMatch:The Digital Coach
> http://www.longomatch.ylatuya.es
>
--
Andoni Morales Alastruey
LongoMatch:The Digital Coach
http://www.longomatch.ylatuya.es
From c181ff748f0587e51b012330b5f47d550b6ceb0b Mon Sep 17 00:00:00 2001
From: Andoni Morales Alastruey
Date: Mon, 19 Mar 2012 23:19:17 +0100
Subject: [PATCH] msi: implement MSIMODIFY_MERGE function in TABLE_modify
---
dlls/msi/table.c| 15 +--
dlls/msi/tests/db.c | 24
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/dlls/msi/table.c b/dlls/msi/table.c
index d37947e..852124e 100644
--- a/dlls/msi/table.c
+++ b/dlls/msi/table.c
@@ -1766,7 +1766,7 @@ static UINT TABLE_modify( struct tagMSIVIEW *view, MSIMODIFY eModifyMode,
MSIRECORD *rec, UINT row)
{
MSITABLEVIEW *tv = (MSITABLEVIEW*)view;
-UINT r, column;
+UINT r, frow, column;
TRACE("%p %d %p\n", view, eModifyMode, rec );
@@ -1811,8 +1811,19 @@ static UINT TABLE_modify( struct tagMSIVIEW *view, MSIMODIFY eModifyMode,
r = msi_table_assign( view, rec );
break;
-case MSIMODIFY_REPLACE:
case MSIMODIFY_MERGE:
+/* check row that matches this record */
+r = msi_table_find_row( tv, rec, &frow, &column );
+if (r != ERROR_SUCCESS)
+{
+/* if the record was not found, validate it and insert it */
+r = table_validate_new( tv, rec, NULL );
+if (r == ERROR_SUCCESS)
+r = TABLE_insert_row( view, rec, -1, FALSE );
+}
+break;
+
+case MSIMODIFY_REPLACE:
case MSIMODIFY_VALIDATE:
case MSIMODIFY_VALIDATE_FIELD:
case MSIMODIFY_VALIDATE_DELETE:
diff --git a/dlls/msi/tests/db.c b/dlls/msi/tests/db.c
index d33eb0c..f5a3c1e 100644
--- a/dlls/msi/tests/db.c
+++ b/dlls/msi/tests/db.c
@@ -923,6 +923,30 @@ static void test_viewmodify(void)
r = MsiViewModify(hview, MSIMODIFY_INSERT_TEMPORARY, hrec );
ok(r == ERROR_FUNCTION_FAILED, "MsiViewModify failed\n");
+/* try to merge the same record */
+r = MsiViewExecute(hview, 0);
+ok(r == ERROR_SUCCESS, "MsiViewExecute failed\n");
+r = MsiViewModify(hview, MSIMODIFY_MERGE, hrec );
+ok(r == ERROR_SUCCESS, "MsiViewModify failed\n");
+
+r = MsiCloseHandle(hrec);
+ok(r == ERROR_SUCCESS, "failed to close record\n");
+
+/* try merging a new record */
+hrec = MsiCreateRecord(3);
+
+r = MsiRecordSetInteger(hrec, 1, 2);
+ok(r == ERROR_SUCCESS, "failed to set integer\n");
+r = MsiRecordSetString(hrec, 2, "pepe");
+ok(r == ERROR_SUCCESS, "failed to set string\n");
+r = MsiRecordSetString(hrec, 3, "7654321");
+ok(r == ERROR_SUCCESS, "failed to set string\n");
+
+r = MsiViewModify(hview, MSIMODIFY_MERGE, hrec );
+ok(r == ERROR_SUCCESS, "MsiViewModify failed\n");
+r = MsiViewExecute(hview, 0);
+ok(r == ERROR_SUCCESS, "MsiViewExecute failed\n");
+
r = MsiCloseHandle(hrec);
ok(r == ERROR_SUCCESS, "failed to close record\n");
--
1.7.5.4
Re: [PATCH] implement MSIMODIFY_MERGE function in TABLE_modify
El 26 de marzo de 2012 11:28, Hans Leidekker escribió:
> On Mon, 2012-03-26 at 11:14 +0200, Andoni Morales wrote:
> > -case MSIMODIFY_REPLACE:
> > case MSIMODIFY_MERGE:
> > + /* check for a duplicated key */
> > + r = msi_table_find_row( tv, rec, &row, column );
> > + if (r == ERROR_SUCCESS) {
> > +/* check that both are identical */
> > +r = compare_record (tv, row, rec);
> > +if (r != ERROR_SUCCESS)
> > + break;
> > + } else {
> > +r = table_validate_new( tv, rec, NULL );
> > +if (r != ERROR_SUCCESS)
> > + break;
> > +r = TABLE_insert_row( view, rec, -1, FALSE );
> > + break;
> > + }
> > +
> > +case MSIMODIFY_REPLACE:
>
> Please use bracketing and indentation style of the surrounding code.
> Some tests would be nice.
>
>
Sorry, I attached the wrong patch file. I have fixed the indentation and
will add tests too.
--
Andoni Morales Alastruey
LongoMatch:The Digital Coach
http://www.longomatch.ylatuya.es
From 0888ba45f7132ba63038b5810ff6edee2d16734f Mon Sep 17 00:00:00 2001
From: Andoni Morales Alastruey
Date: Mon, 19 Mar 2012 23:19:17 +0100
Subject: [PATCH] msi: implement MSIMODIFY_MERGE function in TABLE_modify
---
dlls/msi/table.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/dlls/msi/table.c b/dlls/msi/table.c
index d37947e..fcb879e 100644
--- a/dlls/msi/table.c
+++ b/dlls/msi/table.c
@@ -1766,7 +1766,7 @@ static UINT TABLE_modify( struct tagMSIVIEW *view, MSIMODIFY eModifyMode,
MSIRECORD *rec, UINT row)
{
MSITABLEVIEW *tv = (MSITABLEVIEW*)view;
-UINT r, column;
+UINT r, frow, column;
TRACE("%p %d %p\n", view, eModifyMode, rec );
@@ -1811,8 +1811,20 @@ static UINT TABLE_modify( struct tagMSIVIEW *view, MSIMODIFY eModifyMode,
r = msi_table_assign( view, rec );
break;
-case MSIMODIFY_REPLACE:
case MSIMODIFY_MERGE:
+/* check for a duplicated key */
+r = msi_table_find_row( tv, rec, &frow, &column );
+if (r == ERROR_SUCCESS) {
+/* check that both are identical */
+r = compare_record (tv, frow, rec);
+} else {
+r = table_validate_new( tv, rec, NULL );
+if (r == ERROR_SUCCESS)
+r = TABLE_insert_row( view, rec, -1, FALSE );
+}
+break;
+
+case MSIMODIFY_REPLACE:
case MSIMODIFY_VALIDATE:
case MSIMODIFY_VALIDATE_FIELD:
case MSIMODIFY_VALIDATE_DELETE:
--
1.7.5.4
Re: Spelling errors in en_US translation
On Fri, 16 Mar 2012, Julian Rüger wrote: > Am Freitag, den 16.03.2012, 11:05 +0100 schrieb Francois Gouget: [...] > > * All of Wine resources are supposed to be 100% American English. > > * en_US is automatically filled using Wine's resources. > > * en is manually translated to British English, essentially like any > >other language. [...] > > Why en rather than en_GB? > Maybe we should rename en.po? I checked with Alexandre and it turns out en.po is not just used for British but also for Canadian, Australian, etc. That's why it's not called en_GB.po. In theory that means it should contain 'neutral English' but there's not really any such thing so in practice that means it's British English. And I got confirmation that the en_US.po spelling issues should be fixed in the corresponding RC file. Also, ideally one should provide a command to fixup the PO files to avoid fuzzying the translations every time. [...] > > Should en.po only contain translations where British differs from > > American English? But then how do we know that the translation is > > complete? The thinking is that en.po should probably contain entries for everything even though that may be more work to maintain (really not that much compared to a real translation; imho, maybe even less as it would make keeping it up to date much easier). And that should fix bug 29924. -- Francois Gouget http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.
Re: [PATCH 1/2] shell32: Prepare ASSOC_GetValue and ASSOC_ReturnData to work on non WCHAR* data
Piotr Caban writes: > --- > dlls/shell32/assoc.c | 49 > + > 1 files changed, 25 insertions(+), 24 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M shlwapi.dll -T ../../.. -p shlwapi_test.exe.so assoc.c && touch assoc.ok assoc.c:131: Test failed: Expected 72, got 36 assoc.c:160: Test failed: Expected 24, got 12 make: *** [assoc.ok] Error 2 -- Alexandre Julliard julli...@winehq.org
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
Dmitry Timoshkov writes: > Alexandre Julliard wrote: > >> > Is that a way how dinput detects xinput2 support? Or is that a general >> > approach to detect if a driver supports mouse clipping? How did it work >> > before? >> >> It's used to detect that xinput2 is not supported. > > Apparently dinput shouldn't rely on this, but I don't see what to use > instead. How did it work before? It didn't clip, and it obviously didn't need to detect the lack of xinput2, since we didn't support it... -- Alexandre Julliard julli...@winehq.org
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
Alexandre Julliard wrote: > > Is that a way how dinput detects xinput2 support? Or is that a general > > approach to detect if a driver supports mouse clipping? How did it work > > before? > > It's used to detect that xinput2 is not supported. Apparently dinput shouldn't rely on this, but I don't see what to use instead. How did it work before? -- Dmitry.
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
Dmitry Timoshkov writes: > Is that a way how dinput detects xinput2 support? Or is that a general > approach to detect if a driver supports mouse clipping? How did it work > before? It's used to detect that xinput2 is not supported. -- Alexandre Julliard julli...@winehq.org
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
Vitaliy Margolen writes: > On 03/26/2012 06:14 AM, Alexandre Julliard wrote: >> Dmitry Timoshkov writes: >> >>> This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass >>> on a system without XInput2. >> >> It will break dinput, we rely on the clip rectangle being reset. >> > I'd say it again, dinput should not warp mouse under any > circumstances. Also, there is such a thing as non-exclusive background > mode. I fail to see how this is relevant here, care to explain? -- Alexandre Julliard julli...@winehq.org
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
On 03/26/2012 06:14 AM, Alexandre Julliard wrote: Dmitry Timoshkov writes: This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass on a system without XInput2. It will break dinput, we rely on the clip rectangle being reset. I'd say it again, dinput should not warp mouse under any circumstances. Also, there is such a thing as non-exclusive background mode. Vitaliy.
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
Alexandre Julliard wrote: > > This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass > > on a system without XInput2. > > It will break dinput, we rely on the clip rectangle being reset. Is that a way how dinput detects xinput2 support? Or is that a general approach to detect if a driver supports mouse clipping? How did it work before? -- Dmitry.
Re: d3d10core: Standardize COM aggregation for d3d10_device.
Now that Alexandre is back and Jacek didn't want to beat me to it it is
time to finish my reply...
On 03/22/2012 01:06 AM, Henri Verbeet wrote:
> On 22 March 2012 00:50, Michael Stefaniuc wrote:
>> -static HRESULT STDMETHODCALLTYPE d3d10_device_inner_QueryInterface(IUnknown
>> *iface, REFIID riid, void **object)
>> +static HRESULT STDMETHODCALLTYPE d3d10_device_inner_QueryInterface(IUnknown
>> *iface, REFIID riid,
>> +void **ppv)
>> {
>> -struct d3d10_device *This = d3d10_device_from_inner_unknown(iface);
>> +struct d3d10_device *This = impl_from_IUnknown(iface);
>>
>> -TRACE("iface %p, riid %s, object %p\n", iface, debugstr_guid(riid),
>> object);
>> +TRACE("iface %p, riid %s, object %p\n", iface, debugstr_guid(riid),
>> ppv);
>>
>> -if (IsEqualGUID(riid, &IID_IUnknown)
>> -|| IsEqualGUID(riid, &IID_ID3D10Device))
>> +if (IsEqualGUID(riid, &IID_IUnknown) || IsEqualGUID(riid,
>> &IID_ID3D10Device))
>> +*ppv = This;
>> +else if (IsEqualGUID(riid, &IID_IWineDXGIDeviceParent))
>> +*ppv = &This->IWineDXGIDeviceParent_iface;
>> +else
>> {
>> -ID3D10Device_AddRef(&This->ID3D10Device_iface);
>> -*object = This;
>> -return S_OK;
>> +WARN("%s not implemented, returning E_NOINTERFACE\n",
>> debugstr_guid(riid));
>> +*ppv = NULL;
>> +return E_NOINTERFACE;
>> }
>>
>> -if (IsEqualGUID(riid, &IID_IWineDXGIDeviceParent))
>> -{
>> -IWineDXGIDeviceParent_AddRef(&This->IWineDXGIDeviceParent_iface);
>> -*object = &This->IWineDXGIDeviceParent_iface;
>> -return S_OK;
>> -}
>> -
>> -WARN("%s not implemented, returning E_NOINTERFACE\n",
>> debugstr_guid(riid));
>> -
>> -*object = NULL;
>> -return E_NOINTERFACE;
>> +IUnknown_AddRef((IUnknown*)*ppv);
>> +return S_OK;
>> }
> I'm not sure this really makes it much better, but I guess it's mostly
> up to how Alexandre wants these.
Honestly, when Jacek documented it in the beginning I didn't like it
either. But having to deal now with the bad, the ugly and the
COM implementations in Wine I have overcome my hate for casts and
actually like this way more and more.
Of course if people know COM then it doesn't matter much. But looking at
COM in Wine, feeling the pain of some native COM implementations and how
the applications abuse them it is save to assume that most
developers that write COM stuff don't bother to learn COM.
COM is programmed by cut&paste and beating the code into submission. And
for that use case the way that Jacek documented is way better:
- Generic solution which works in all cases:
* Single interface implementation in the object (not the most elegant
solution though).
* Multiple interface implementations with one refcount.
* Multiple interface implementations with multiple refcounts.
- AddRef in one and only one place which is very explicit on what needs
to be addref'ed (the returned interface). And most importantly the
AddRef is part of the boiler plate which doesn't needs to change during
cut&paste programming.
- And last but not least the 3rd parameter of QueryInterface doesn't
have object in its name. It is *not* an object even though MS loves to
call it ppvObject. "ppv" is just "peepeevee"; any resemblance of
Hungarian notation is pure coincidence ;). Though I don't mind changing
it as long as it doesn't contains obj/object.
bye
michael
Re: GSoC proposal
Hi, Not to argue if it will be useful or not, as I do not know. I think this will be technically very hard. You will have to be able to get the keystrokes for a native linux applications feed them into WINE, have wine do the IME processing and then get the resulting characters and feed them back into the native linux application. This pipeline is not trivial. Additionally, you have not explained how this will benefit WINE. I can forsee none of the above pipeline being accepted into or applicable to WINE presently, at lest in theory, i have done work that allows native XIM clients to be able to work in wines IME framework, so if a user really wants to use windows XIM in wine they should work. The setup is tricky but in all my years of working on wine IME i have never heard of a user wanting that. Almost all requests are to make the Linux/Mac Input Methods work better in WINE. I would love to have you work on improving IME and XIM integration in WINE, but i think the main goal of the project is pretty tangential to wine. -aric On 3/25/12 10:48 PM, Cheer Xiao wrote: 2012/3/26 Hin-Tak Leung: Cheer Xiao wrote: I'm sure that's all true, but why would making Win32 input methods run through Wine be a better (or even easier) solution than improving the Linux/X11 input methods? (I'm talking about Chinese, but the same is true for Japanese.) Because developing a decent pinyin (it's a romanization scheme of Chinese; see my previous mail) IME is very hard. Yes, there are alternative input methods that is easier to implement, but the majority of the population won't bother to learn. Determined by the complexity of Chinese grammar, a decent pinyin IME would require a large corpse of vocabulary, driven by some statistical algorithm. I think you are describing the situation wrongly, in quite a few ways. Implementing pinyin *itself* is trivial - there is a standard-ish pronounciation, etc, and is completely table-driven. That's how most of Linux/X11's Chinese input method, especially pinyin, works. What you are describing is the desirability of predictive and phrasal input methods in general, where the computer can anticipate and guess your intention as you type. We only disagree in the definition of what a "decent" IME is. By decent I meant a decent phrasal or sentence IME. Because given the large amount of homophones in Chinese a bare pinyin IME is barely usable. For what it is worth, you are forgetting two entire "areas" of people. Taiwan/Hong Kong had always been far more computer-literate than Mainland, so your "80% won't bother to learn another" is a gross mis-statement in both quantity and quality. Due to different dialects and other reasons, Cangjie (rather than Pinyin) had been far more popular with Chinese users. But even with Cangjie (which is shape/writing-based, rather than sound-based, thus getting around the dialect problem), predictive and phrasal input methods are desirable. I declared that I was talking about the situation in mainland China in the beginning - I should have emphasized that along the way. But by declaring Cangjie is far more popular, you are ignoring the mass majority of people in mainland China. Again, I won't be able to convince you that the majority won't bother to learn another IME, even in highly computer-literate places like CS departments in universities. Arguing about facts is plainly meaningless. Over 10 years ago, I had some on-line discussion on emacs-devel, with Mr RMS no less, about my continued interests and compiler problems with emacs 19 (?) despite emacs 21 being around, which had mule [multi-lingual extension] newly added (or some issue of that vintage). The reason was that I could run emacs 19 inside cxterm (a chinese x terminal). Now the curious thing is that emacs actually took *all* the input methods from cxterm! So Pinyin/Cangjie themselves worked 10+ years ago identically under emacs 19 + cxterm, and emacs 21 mule. Yes, but "just works" is not the same thing as "usable". What emacs did not, and still does not, implement, which cxterm did even almost 20 years ago, was predictive and phrasal inputs and also fuzzy inputs. i.e. you can type "a?b", and get the list of "a[a-z]b". That was something done almost 20 years ago which is still missing in many of the modern Chinese X11 input mechanisms. (I have a confession to make - cxterm was orphaned for many years, and I and a few others are who kept it going-ish, in recent years, for what little needs to be done).
Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
Dmitry Timoshkov writes: > This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass > on a system without XInput2. It will break dinput, we rely on the clip rectangle being reset. -- Alexandre Julliard julli...@winehq.org
Re: msi: Implement MSIMODIFY_MERGE function in TABLE_modify.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17479 Your paranoid android. === WNT4WSSP6 (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === W2KPROSP4 (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === WXPPROSP3 (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === W2K3R2SESP2 (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === WVISTAADM (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === W2K8SE (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === W7PRO (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === W7PROX64 (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === TEST64_W7SP1 (32 bit db) === db.c:1079: Test failed: MsiViewModify failed === W7PROX64 (64 bit db) === db.c:1079: Test failed: MsiViewModify failed === TEST64_W7SP1 (64 bit db) === db.c:1079: Test failed: MsiViewModify failed
Re: [PATCH] implement MSIMODIFY_MERGE function in TABLE_modify
On Mon, 2012-03-26 at 11:14 +0200, Andoni Morales wrote:
> -case MSIMODIFY_REPLACE:
> case MSIMODIFY_MERGE:
> + /* check for a duplicated key */
> + r = msi_table_find_row( tv, rec, &row, column );
> + if (r == ERROR_SUCCESS) {
> +/* check that both are identical */
> +r = compare_record (tv, row, rec);
> +if (r != ERROR_SUCCESS)
> + break;
> + } else {
> +r = table_validate_new( tv, rec, NULL );
> +if (r != ERROR_SUCCESS)
> + break;
> +r = TABLE_insert_row( view, rec, -1, FALSE );
> + break;
> + }
> +
> +case MSIMODIFY_REPLACE:
Please use bracketing and indentation style of the surrounding code.
Some tests would be nice.
Re: [PATCH] implement MSIMODIFY_MERGE function in TABLE_modify
Andoni Morales wrote:
> -case MSIMODIFY_REPLACE:
> case MSIMODIFY_MERGE:
> + /* check for a duplicated key */
> + r = msi_table_find_row( tv, rec, &row, column );
> + if (r == ERROR_SUCCESS) {
> +/* check that both are identical */
> +r = compare_record (tv, row, rec);
> +if (r != ERROR_SUCCESS)
> + break;
> + } else {
> +r = table_validate_new( tv, rec, NULL );
> +if (r != ERROR_SUCCESS)
> + break;
> +r = TABLE_insert_row( view, rec, -1, FALSE );
> + break;
> + }
> +
> +case MSIMODIFY_REPLACE:
> case MSIMODIFY_VALIDATE:
Please get rid of redundant 'break' statements, and add one at the end
of case processing.
--
Dmitry.
