February 2008 - Wine-Devel - list.winehq.org

Re: IStream interface for domdoc and terminate call

by Kornél Pál

Hi, If you mean passing an IStream interface to DOMDocument.save method: As far as I know save method is synchronous (if I'm wrong you still can set the async property to FALSE). So when the save method returns you know that the entire document has been passed to the IStream. If you want to do something else please be more specific. Kornél ----- Original Message ----- From: "Josef Reidinger" <josef.reidinger(a)gmail.com> To: <wine-devel(a)winehq.org> Sent: Monday, February 11, 2008 11:55 AM Subject: IStream interface for domdoc and terminate call > Hi, I try make IStream write interface for domdoc (msxml3). Problem is > that microsoft doesn't have terminate string for write call and libxml > have proble with it (more at > http://mail.gnome.org/archives/xml/2008-February/msg00052.html ). Does > anyone has any idea how solve it? (test in each dom call if is some > nonparsed characters and force parsing looks very ugly). > JR > >

Feb. 11, 2008

IStream interface for domdoc and terminate call

by Josef Reidinger

Hi, I try make IStream write interface for domdoc (msxml3). Problem is that microsoft doesn't have terminate string for write call and libxml have proble with it (more at http://mail.gnome.org/archives/xml/2008-February/msg00052.html ). Does anyone has any idea how solve it? (test in each dom call if is some nonparsed characters and force parsing looks very ugly). JR

Feb. 11, 2008

Re: pdh[3:3]: remove unnecessary tests doneinPdhLookupPerfNameByIndexW

by Dmitry Timoshkov

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: > I think it will be better to pass > machine in this case. Yes, it just needs to be converted to unicode first. -- Dmitry.

Feb. 11, 2008

Re: pdh[3:3]: remove unnecessary tests doneinPdhLookupPerfNameByIndexW

by Jeff Latimer

Dmitry Timoshkov wrote: > That's true for index, but not for machine. You are correct. I will resubmit. I think it will be better to pass machine in this case. Jeff

Feb. 11, 2008

Re: pdh[3:3]: remove unnecessary tests doneinPdhLookupPerfNameByIndexW

by Dmitry Timoshkov

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: > My understanding of your question is: if I am removing the tests in one > place then they should not be be necessary in the other. This is not > the case. A call to PdhLookupPerfNameByIndexA will call > PdhLookupPerfNameByIndexW and thus execute the all tests. The way it is > at the moment the tests get executed twice (in the negative), this > change ensures that they only execute once. That's true for index, but not for machine. -- Dmitry.

Feb. 11, 2008

Re: pdh[3:3]: remove unnecessary tests done inPdhLookupPerfNameByIndexW

by Jeff Latimer

Dmitry Timoshkov wrote: > "Jeff Latimer" <lats(a)yless4u.com.au> wrote: > >>>> - if (machine) >>>> - { >>>> - FIXME("remote machine not supported\n"); >>>> - return PDH_CSTATUS_NO_MACHINE; >>>> - } >>>> - >>>> if (!buffer || !size) return PDH_INVALID_ARGUMENT; >>>> - if (!index) return ERROR_SUCCESS; >>> Changelog mentions PdhLookupPerfNameByIndexW by the change is in >>> PdhLookupPerfNameByIndexA. >>> Why are you removing the checks in one place by leave the same in >>> other one? Why the tests >>> are unnecessary? >> The parameters, bufferW and sizeW passed by PdhLookupPerfNameByIndexA >> to PdhLookupPerfNameByIndexW are local to PdhLookupPerfNameByIndexA. My understanding of your question is: if I am removing the tests in one place then they should not be be necessary in the other. This is not the case. A call to PdhLookupPerfNameByIndexA will call PdhLookupPerfNameByIndexW and thus execute the all tests. The way it is at the moment the tests get executed twice (in the negative), this change ensures that they only execute once. > > That doesn't mean that PdhLookupPerfNameByIndexW can't be called > directly. Correct and that is why the tests are left in place. > >> The test is needed still in PdhLookupPerfNameByIndexA because the >> size and buffer are not passed but still need to be checked. > > That still doesn't answer my questions. Does this clarify this things?

Feb. 11, 2008

Re: [1/9] WineD3D: Add a test for the vFace register

by H. Verbeet

On 11/02/2008, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > /* TODO: vFace (ps_3_0) */ You should probably remove that one :-)

Feb. 11, 2008

Re: Is there a Git Repositories for Unaccept Patches or (work in Progress)?

by Steven Edwards

On Feb 11, 2008 1:28 AM, Steven Edwards <winehacker(a)gmail.com> wrote: > It seems to me that its less trouble to have a central repo hosted > somewhere like repo.or.cz where winehq origin is imported in parallel > and as changes come in they are merged on to a public winequartzdrv > branch. Then I fix the stuff I know I can fix in my local tree like So now that I've spammed the list enough I see in the other thread people already have branches hosted on repo.or.cz. I guess I will push my winequartzdrv there. Before these threads I didn't know anyone was hosting wine related stuff there so send my spam to /dev/null -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Feb. 11, 2008

Re: Is there a Git Repositories for Unaccept Patches or (work in Progress)?

by Steven Edwards

On Feb 11, 2008 12:59 AM, Dan Kegel <dank(a)kegel.com> wrote: > On Feb 10, 2008 9:57 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > > ... Having invested a > > good bit of time in trying to understand git, I think I git it now so > > to speak and not having a public repo where there can be really > > collaborative development seems to be a step back to me. > > ? But you don't need a central public git repository to do > collaborative development, that's the whole point of git... Maybe I still don't get git. Right now there are not many others interested in winequartzdrv and the only place its hosted is in CVS. I've got it imported locally and I can publish changesets on wine-patches or bugzilla but thats going to spam wine-patches or be very sucky for development if its not ready to merge in to master for months++ or longer. For a proper push or pull to work, I'd either have to publish my repo here or someone else would have to pick it up and import it right? Then we could rebase off of each others changes? We could push and pull to each other via email and still pull in from winehq and rebase right? Then wouldn't that imply that I'd have to push my changes to everyone via a mailing or something or still host my own public repo if multiple people want to pull from my most recent bleeding edge broken stuff? It seems to me that its less trouble to have a central repo hosted somewhere like repo.or.cz where winehq origin is imported in parallel and as changes come in they are merged on to a public winequartzdrv branch. Then I fix the stuff I know I can fix in my local tree like the keyboard input handling changes, push those changes up, while leaving other broken stuff like visable region handling for someone else to work on. If others come along with an existing winehq tree, they can pull from that repo without much trouble. I've still got my local git repo I can branch off of and hack the hell out of and cherry pick patches from, push them up to the winequartdrv branch on the public repo, etc. Thats in effect what I have here. I've got a faux-public git repo and a private repo where I pull winehq origin in I pull the faux-public's quartzdrv branch in, I rebase winehq on top of my private branch, fix the changes and then push the new "stable" winequartzdrv up to my faux-public repos winequartzdrv branch. It would work really well for others to pull and push from except. A. I don't want to host it on my cable modem and B. I can't commit to running it due to lack of time and skill with the code in question. I can do minor enhancements like fix up the changes for mouse/keyboard handling now that its moved to the server but as far as actual design and real programming go I don't view myself and competent enough to waste my or anyone elses time publicly hosting. I just did all of this as a experiment to teach myself git. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Feb. 11, 2008

Re: Is there a Git Repositories for Unaccept Patches or (work in Progress)?

by Dan Kegel

On Feb 10, 2008 10:02 PM, James Hawkins <truiken(a)gmail.com> > This sparked a memory of the discussion about having a -devel and a > -stable branch after we release 1.0. Oh, yeah. IMHO we should release 1.0.0 and 1.1.0 at the same time, and treat 1.0.x as our stable branch.

Feb. 11, 2008