I was getting ready to argue with you this point, but you made a
comment on IRC that changed my mind: "I thought the idea was to
support the full range of the hardware". And, you're right. :-)
So, please ignore this patch for now - I'll re-work it over the
weekend and resubmit.
On 7/21/06, Iv
Kevin Krammer wrote:
IMHO of course based on the agreement of both students since they might have
individual ideas on how to solve certian aspects.
My suggestion is to give each student a bag (of marijuana), a lighter,
and a pipe, lock them in a room, and don't let them out until they have
come
There were plenty of ways to fix this. One would have been to unroll
all of the memset/memcpy calls into functions that explicitly set
every value on the stateblock. While this might have been more
"correct", it would be harder to maintain.
I argue that an explicit initializer is always bette
On 7/21/06, Chris <[EMAIL PROTECTED]> wrote:
On Friday 21 July 2006 11:19, Jason Green wrote:
> + /* Calculate reflection vector (Assume normal is normalized): RF =
2*(N.E)*N -E */
> + shader_addline(buffer, "tmp0.w = dot(vec3(tmp0), %s);\n", src1_str);
> + shader_addline(buffer, "tmp0 = tmp0.w *
Well, it seems that we have a bit of a problem building Wine 0.9.17 on
Gentoo...
make[2]: Entering directory
`/var/tmp/portage/wine-0.9.17/work/wine-0.9.17/dlls/gphoto2.ds'
../../tools/makedep -I. -I. -I../../include -I../../include
-I/usr/include/gphoto2 -I/usr/include -I/usr/include/gphoto2
On Friday 21 July 2006 11:19, Jason Green wrote:
> + /* Calculate reflection vector (Assume normal is normalized): RF =
2*(N.E)*N -E */
> + shader_addline(buffer, "tmp0.w = dot(vec3(tmp0), %s);\n", src1_str);
> + shader_addline(buffer, "tmp0 = tmp0.w * tmp0;\n");
> + shader_addline(bu
Alexandre Julliard wrote:
A quick fix is to add more free list entries, and in particular an
entry for very small blocks since your test case seems to create a lot
of them. Something like this seems to work well:
Thank you Alexandre, this patch speeds up HomeSite a lot. It's still not
as fast
On Thursday 20 July 2006 20:10, Yuriy wrote:
> Uh-oh.
>
> I'm already well into making this. I guess we have a little
> mis-/lack-of communication.
I have informed the other KDE mentors and we are discussion some solutions to
avoid duplication of efforts.
Basically something like Yuriy concentr
On Tue, 11 Jul 2006, gslink wrote:
The most common problem with Ndiswrapper is that it requires more than a 4k
stack. The result you are getting may be coming from a stack overflow caused
by a combination of Wine and Ndiswrapper.
The 4k stack issue you are talking about is a kernel stack. Wi
Doesn't look like they have anything substantial to say, but just in
case from the Summer of Code FAQ:
What if someone else is attempting to execute on the same project?
That's fine, a little duplication is par for the course in open source.
Can a group apply for and work on a single project?
No,
"H. Verbeet" <[EMAIL PROTECTED]> wrote:
Attached is a slightly updated version of the patchset. I got rid of
the winmm import, and it should now destroy cursors / icons when the
process is destroyed. The changes are in parts 1 & 9, the rest should
be pretty much unchanged.
I've looked only at
On Tue, 11 Jul 2006, Thomas Kho wrote:
[...]
A fake notepad.exe is currently created in c:\windows\system32. I
don't think there's duplication of CreateProcess because CreateProcess
considers the filename of the executable to be the first quoted term
in the commandline. In contrast, cmd.exe also
On 07/07/06, Robert Shearman <[EMAIL PROTECTED]> wrote:
However, I did find two things that I think need consideration or
improvement:
From 01_server_cursoricon.diff.txt:
> +/* Destroy a cursor */
> +DECL_HANDLER(destroy_cursor)
> +{
> +unsigned int i;
> +cursor_t *cursor = free_user_h
Thursday, July 20, 2006, 11:53:37 PM, Dan Kegel wrote:
> On 7/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> There is a patch in the AppDB entry for the game Continuum. (sorry I
>> don't have AppDB playing nice with DNS here yet so no link.) What needs
>> to be done to have this considered?
Michael Kaufmann <[EMAIL PROTECTED]> writes:
> HomeSite's syntax checker needs 120 seconds to load on Wine because of
> Wine's poor heap implementation. Most users will think that the
> program has crashed. I have created a trace of HomeSite's memory
> requests and a program to replay them. For de
Let me guess, your "stress-test" is installing Gentoo :)
Jeremy Newman wrote:
Thanks. ;)
Sorry to everyone for the extended downtime. It has been a nightmare of
the worst sysadmin kind. I had stress tested 2 different motherboards.
The first one would run for less than 12 hours or so then crash
16 matches
Mail list logo
