Hi,
this question seems to arise periodically, so let's have a
constructive discussion again about the issue once again.
The issue is being that a lot of people have direct commit access to
the repository, and sooner or later some of them commit patches which
introduce a regress in functionality.
I will use Magnus (GreatLord) again as an example. He was doing a
good thing (as usual), but then somehow lost focus, and along with
good fixes committed a breakage for FF2.0 installer (and all other
apps using PatBlt functions). I had to (as usual!) spend the whole
morning reviewing all his diffs, then regress-testing by bisection to
find the guilty revision, then work out a better solution with him,
and then come to agreement that the guilty commit could be just
reverted for now, since it partly works anyway.
This takes up significant amount of my time, which could go into
something more productive than just testing patches, finding way to
unregress, and so on.
Especially I'm angry about this happening right when approaching
0.3.5 release.
Ideally (as I explained in #reactos today to blight_), I want the
trunk itself be directly committable only by a very limited number of
persons, and all developers should be committing to "some other
place" at first, and then their patches merged by reviewers/testers
(yes, manually, sometimes just reviewing may be enough to commit/
reject the patch, sometimes a thorough testing must be involved,
maybe additional devs asked for a review).
blight_ called this as a "linux development model" with an
intermediate branch - yes, maybe, why not?.
What I definately don't want to do is to scare developers away and
make their life more complicated by need of sending text patches
(this is just not convinient, and as seen on the example of Wine
makes a lot of possible contributors going away).
I remember what Alex proposed (those who don't, may look up ros-dev
ML archives with a similar topic).
Would there be any new prepositions? Maybe someone discovered a new
CIS for SVN, or a decentralized VCS for patch submission and usual
SVN for maintaining HEAD?
With time, developers number is only going to increase, so this
problem will become more and more annoying.
With the best regards,
Aleksey Bragin.
Hi,
I'm going to explain this ONCE:
1st: The move was to conserve and reduce space and size of the current
structure.
Writing a floating point package could be hard to do or just copyleft
one off the net.... Problem is if we do the later it will most likely
not be compatible with M$ SFPP. BTW, M$ did patent their strange and
unusual floating point package. Which means I can not write one! Just
writing the storage emulation is almost a problem too... But due to US
patent law I can just do what I did, to "Talk to the Interface" with
the storage emulation.
Keeping the current state of ReactOS FP is my first choice. We use the
speed of the FPU which is part of the main processor and reduce the
size of the source. (Two pluses so far, Speed and Small Size.) The
storage emulation for gdi32 is important for compatibility and with
ReactOS concept of drop in replacement and play.
Thanks,
my 1EU
References:
Fast floating-point truncation to integer form - US Patent 6535898:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US6535898&F=0
Use of indices for queries with comparisons based on a function:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1193619&F=0
System and method for fast and smooth rendering of lit, textured spheres:
http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=EP1227443&F=0
John R. Hauser SoftFloat package :
http://www.jhauser.us/arithmetic/SoftFloat.html
IEEE 754 floating-point test software:
http://www.math.utah.edu/~beebe/software/ieee/
Hi,
I experience a hang of FF 1.5 installation app at "0% Extracting".
Sometimes hangs completely (even mouse doesn't move), sometimes I'm
able to click "X" and choose yes to cancel.
It started happening at least since yesterday.
WBR,
Aleksey Bragin.
Hi,
I like to start testing FF again on hardware but this bug is still open.
http://www.reactos.org/bugzilla/show_bug.cgi?id=2987
I've copied most of the netamd.inf from Ros to match with the inf for
the driver. But still the same crash.
Please let me know,
James
Hi!
There was a reason for doing what I commit'ed,,,, since you are
looking at it can you please fix this.
8^)
James
gdi32_winetest pen
ExFreePool of already freed address 80e8ba78
KeBugCheck at ntoskrnl/mm/npool.c:1566
*** Fatal System Error: 0x00000000
(0x00000000,0x00000000,0x00000000,0x00000000)
Entered debugger on embedded INT3 at 0x0008:0x808ac7d8.
kdb:> bt
Eip:
<NTOSKRNL.EXE:ac7d9 (lib/rtl/i386/debug_asm.S:42
(RtlpBreakWithStatusInstruction))>
Frames:
<NTOSKRNL.EXE:29a2 (ntoskrnl/ke/bug.c:1100 (KeBugCheckWithTf@24))>
<NTOSKRNL.EXE:2aac (ntoskrnl/ke/bug.c:1364 (KeBugCheck@4))>
<NTOSKRNL.EXE:5f00c (ntoskrnl/mm/npool.c:1567 (ExFreeNonPagedPool@4))>
<NTOSKRNL.EXE:61e64 (ntoskrnl/mm/pool.c:238 (ExFreePool@4))>
<win32k.sys:967ff (subsystems/win32/win32k/objects/pen.c:344
(NtGdiExtCreatePen@44))>
<NTOSKRNL.EXE:96eda (ntoskrnl/ke/i386/trap.s:244 (KiFastCallEntry))>
<ntdll.dll:5dda>
<gdi32_winetest.EXE:3b497>
<gdi32_winetest.EXE:3d605>
<gdi32_winetest.EXE:3d78d>
<gdi32_winetest.EXE:3dc3d>
<gdi32_winetest.EXE:3dc6a>
<kernel32.dll:21610>
<00000000>
On Tue, Jun 3, 2008 at 5:08 PM, Colin Finck <mail(a)colinfinck.de> wrote:
> The Wine test framework is currently only used by tests imported from Wine,
> so an own test suite for ws2_32.dll might get lost there.
You could have written the tests for the wine test suite and submitted them.
> Also Timo's testing framework offers some interesting features like HTML
> output not offered by the Wine one.
Sure, but given the size of the wine test suite verses Timo's I think
the effort is
better spent adding this to winetest
> Additionally, we have a free hand here and can play with it as we want,
> while we can only import and maybe make little changes to the Wine test
> framework if we want to avoid a big merging mess.
Your always free to fork. As I said given the large number of unit
tests in the Wine framework
it seems to make more sense to me to extend that rather than develop a new one.
Besides you can add the features you need to the Winetest gui and have
it be independent
of the framework as a whole.
--
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
I'm getting *quite* annoyed with seeing these kinds of tests:
ret = SomeFunc();
ASSERT(ret == success);
How exactly is this a test anyway? It proves in NO way that the
function *worked*, only that it returned success. Furthermore, there
are *plenty* of cases where a function could legitimately fail -- it
is simply stupid to assume that a failure means a regression. What if
the system is out of memory?
On Sun, Jun 1, 2008 at 10:38 PM, <greatlrd(a)svn.reactos.org> wrote:
> Author: greatlrd
> Date: Sun Jun 1 09:38:02 2008
> New Revision: 33807
>
> URL: http://svn.reactos.org/svn/reactos?rev=33807&view=rev
> Log:
> add Test for EngDeleteSemaphore, it only test if it been create or not
>
> Added:
> trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c (with props)
> Modified:
> trunk/rostests/apitests/gdi32api/testlist.c
>
> Modified: trunk/rostests/apitests/gdi32api/testlist.c
> URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/gdi32api/testlis…
> ==============================================================================
> --- trunk/rostests/apitests/gdi32api/testlist.c [iso-8859-1] (original)
> +++ trunk/rostests/apitests/gdi32api/testlist.c [iso-8859-1] Sun Jun 1 09:38:02 2008
> @@ -11,6 +11,7 @@
> #include "tests/CreateFont.c"
> #include "tests/CreatePen.c"
> #include "tests/CreateRectRgn.c"
> +#include "tests/EngCreateSemaphore.c"
> #include "tests/ExtCreatePen.c"
> #include "tests/GdiConvertBitmap.c"
> #include "tests/GdiConvertBrush.c"
> @@ -51,6 +52,7 @@
> { L"CreateCompatibleDC", Test_CreateCompatibleDC },
> { L"CreateFont", Test_CreateFont },
> { L"CreatePen", Test_CreatePen },
> + { L"EngCreateSemaphore", Test_EngCreateSemaphore },
> { L"CreateRectRgn", Test_CreateRectRgn },
> { L"ExtCreatePen", Test_ExtCreatePen },
> { L"GdiConvertBitmap", Test_GdiConvertBitmap },
>
> Added: trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c
> URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/gdi32api/tests/E…
> ==============================================================================
> --- trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c (added)
> +++ trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c [iso-8859-1] Sun Jun 1 09:38:02 2008
> @@ -1,0 +1,15 @@
> +/* Simple test of EngAcquireSemaphore only check if we got a lock or not */
> +INT
> +Test_EngCreateSemaphore(PTESTINFO pti)
> +{
> +
> + HSEMAPHORE hsem;
> + hsem = EngCreateSemaphore();
> +
> + RTEST ( hsem != NULL );
> +
> + EngDeleteSemaphore(hsem);
> +
> + return APISTATUS_NORMAL;
> +}
> +
>
> Propchange: trunk/rostests/apitests/gdi32api/tests/EngCreateSemaphore.c
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
>
--
Best regards,
Alex Ionescu
Hi!
I checked this and it is all wrong,,,,, I reverted part of revision 19267:
Replacing the code with the original wine code that behaves like
"Windows code" but should be called inside EngCreateBitmap if (pvBits)
Width = DIB_GetDIBWidthBytes( lWidth, iFormat); .
As it should be:
INT FASTCALL DIB_GetDIBWidthBytes (INT width, INT depth)
{
// return ((width * depth + 31) & ~31) >> 3;
int words;
switch(depth)
{
case 1: words = (width + 31) / 32; break;
case 4: words = (width + 7) / 8; break;
case 8: words = (width + 3) / 4; break;
case 15:
case 16: words = (width + 1) / 2; break;
case 24: words = (width * 3 + 3)/4; break;
default:
DPRINT1("(%d): Unsupported depth\n", depth );
/* fall through */
case 32:
words = width;
}
return 4 * words;
}
On Sat, May 31, 2008 at 7:15 PM, <tkreuzer(a)svn.reactos.org> wrote:
> Author: tkreuzer
> Date: Sat May 31 18:15:34 2008
> New Revision: 33792
>
> URL: http://svn.reactos.org/svn/reactos?rev=33792&view=rev
> Log:
> preserve code for NtGdiCreateEnhMetaFile from win32k (where it's going to be removed later) in gdi32 (where it's going to be implemented later)
if your going to implement it all in usermode are you going to try to
just rip the Wine metafile and enhanced metefile drivers?
Thanks
--
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