Since kthreads has now been removed, references to it in the
developer's guide should presumably be removed. What about NPTL?
Should discussion comparing it to kthreads be removed?
Peter
> I don't know about the 'respectability' of SF, but I'm more concerned with
> the content and who gets to change it. There are folks that may decide to
> enter incorrect or even bogus information. I would like it if all added
> information that is not already present in the Wine API be vetted
> What's wrong with strncmp?
strncmp(arg, str, sizeof(str)-1) looks ugly.
Peter
> Hi,
> sorry, but your patch is a bit ugly...
> please look at the code below /* determine if tihs switch is followed by a
> separate argument */ in winegcc.c and understand what it does.
> specially with next_is_arg, is_linker_arg,
I could set option_arg for semantic correctness.
> Also t
> My primary concern here is
> participation
Count me in! I think it would be a great way to learn the wine/windows
internals.
Peter
> Wine can load and parse resources just from
> winelib (dll.so/exe.so) binaries.
I assume that dll.so/exe.so are for all practical purposes identical
to .dll/.exe except they can't be run on windows.
Peter
> Howdy,
>
> I was looking at http://bugs.winehq.org/show_bug.cgi?id=23421, and
> wanted to add a stub for it. Using winedump on a Windows 7 shlwapi.dll
> gives different exports than Windows XP SP3 shlwapi.dll. Which dll
> should the spec file be updated to match? I'm assuming the latest and
> gre
> What is the cleanest way to do this? I was hoping it would be as simple
> as passing -fprofile-generate and -fprofile-dir as CFLAGS and LDFLAGS
> to configure.
>
> Thanks,
> Scott Ritchie
Copy 'preloader.o' (to prevent wine-preloader being rebuilt) and
'wine-preloader' from a normal build. As
> Is best practice to confine these to a particular folder (like you get
> with -fprofile-dir)? Is there a switch to do that for gcov data?
Due to limitations of my patch -fprofile-dir (or passing arguments to
-fprofile-* is unsupported). All it allows you can do is pass
"--coverage", "-fprofile-
> It shouldn't. What conf* files do you see?
conf23880
conf23880.dir
conf23880.file
Where "conf23880.dir" is an empty directory, "conf238800.file" is a
file containing only a newline and "conf23880" symlinks to
"conf23880.file".
Having looked into it, it seems that these files are usually delete
Does this mean that "make depend" should be removed from README and
./tools/wineinstall? It generates /conf* files.
Peter
On 18 June 2010 01:50, Scott Ritchie wrote:
> Hey Peter,
>
> Was just hoping you'd make the (I believe trivial) change to your gcov
> patch that Alexandre wanted and submit it by tomorrow so it creeps into
> the next RC. I want to start messing around with profiled package
> builds this weekend :
>LDFLAGS are already passed to winegcc where appropriate.
Oops, hadn't noticed they got in though $(ALL_LIBS), you can omit that
part of the patch then.
Why do we silently drop unrecognized args in "winegcc" anyway?
Peter
On 16 June 2010 02:37, Dan Kegel wrote:
> But does PGO improve performance measurably?
>
Probably, to test it I need a program that runs wine like a typical
program, that I can run autonomously. Anyone have any ideas?
Peter
After applying my "[RESEND 2] Changes to enable the use of gcov and PGO" patch
To use gcov:
Run "make EXTRACFLAGS=--coverage LDFLAGS=--coverage"
Run program (presumably test suite)
Run "gcov file.c" (multiple files like "gcov *.c" doesn't work for
some reason)
To use PGO
Run "make EXTRA
> Wouldn't it be sufficient for our purposes to just count every first
> fixme in a WINAPI function as a stub? As it is now there's a large
> percentage of fixmes that don't include the 'stub' keyword.
A FIXME doesn't neccesarily indicate a stub. It sometimes is like
"Flag FOO unsupported", which
> Somehow this patch got munged in transit and will not apply to current git.
> Can you update it and send it again?
I think my mail client (gmail) line wraps. I discovered when trying to
apply it myself.
> As an aside, if gcov compilation finally starts working that means we
> can build Wine u
On 14 June 2010 18:40, Damjan Jovanovic wrote:
>
> Since around 2-3 months ago, you don't need to run "make depend" at all :-).
>
> Damjan
>
Then why is it still there?
Peter
How often do I need to run "make depend"?
Peter
On 12 June 2010 00:23, Aneurin Price wrote:
> Is it a legal requirement that everyone working on WINE must be a
> complete arsehole, or just a project requirement?
>
> Nye
Which side are you on?
Peter
How do I get the test suite to report it success rate (as a whole) in
a "%d tests executed (%d marked as todo, %d %s), %d skipped.\n" style.
Peter
Some tests crash for me (eg.
http://bugs.winehq.org/show_bug.cgi?id=22903 segfaults). This means I
can't run the entire test suite with "make test", what should I do?
Peter
> We use real names here. This patch probably will not be committed until it
> is resubmitted.
Ops! I've mis-configured my mail client
> The patch is also wrong.
Why? What difference does malloc() over HeapAlloc() make? (this is arguably a
case for not sending the patch in the first place)
There
23 matches
Mail list logo
