On 2015-02-16 10:27, zefklop (JIRA) wrote:
> zefklop commented on ROSTESTS-153:
> ----------------------------------
>
> This and the advapi32:service disabled test call for (optional) per-test timeout parameter in rostests or testman.We can't afford skipping tests, that's an open door to all kind of regressions.
I agree that skipping tests is a really bad idea. It should be used as
a last resort only. And we need a proper process for it** -- I've been
spending way too much time hunting down skipped tests recently, and way
too many of them had their underlying bugs (and sometimes even Jira
issue) fixed without re-enabling the test.
However I don't see a practical way to implement your solution. For one,
the timeout seems like it would have to cause a machine reboot, which
significantly increases test time. I guess rosautotest could keep track
of the time and kill the child process, but I don't know how reliable
that would be.
Secondly and more importantly, killing the test on timeout seems worse
than skipping the offending part, because then any tests running
_after_ the code causing the timeout would never be executed. That means
instead of skipping a test that's known to be problematic, we skip
completely unrelated and innocent tests.
I'm not sure if there's a way to win this. Let me know if you have any
ideas. As it stands I think skipping the offenders is an okay solution
-- we just need to stay very aware of them and make sure to re-test more
regularly than we do now.
Thanks!
-Thomas
** For the record, here's an example process that I try to keep to:
- Create a ROSTESTS bug to indicate that a test was skipped
- Link the ROSTESTS bug to ROSTESTS-125, the Skipped Tests Epic
- Do not #if out the test, instead check for winetest_interactive, and
skip the test only if it's not set
- Make sure to call skip() with a message that references the ROSTESTS
bug
- Optionally create a CORE issue for the underlying problem if enough
information is available; make sure it blocks the ROSTESTS issue
- Do not under any circumstances close the ROSTESTS bug before the test
code is actually restored and no longer skips the test in question
This allows the issue to be actually found, by checking the Epic, or
grepping for "ROSTESTS-" or "winetest_interactive". Skipped tests
should be re-tested regularly, at the very least every time the test is
Wine-synced.
>> gdi32_winetest:bitmap test_mono_bitmap skipped because it takes too long and spams the debug log with too many failures
>> -----------------------------------------------------------------------------------------------------------------------
>>
>> Key: ROSTESTS-153
>> URL: https://jira.reactos.org/browse/ROSTESTS-153
>> Project: ReactOS Test Suite
>> Issue Type: Bug
>> Components: Wine Tests
>> Reporter: Thomas Faber
>> Assignee: Bug Zilla
>> Labels: HACK
>>
>> If you close this task, that means the winetest_interactive check and skip() in test_mono_bitmap must be gone!
Hi James!
It would be nice if you could also do some cleanup in that caret code,
because it seems (starting r66244):
- there is somewhat duplicated caret painting in win32k and in user32,
- the caret is sometimes drawn one or two pixels too high.
And of course, everything should be done windows-compatible (not
wine-compatible)!!
Cheers,
Hermès.
------------------------------------------
Author: jimtabor
Date: Fri Feb 13 13:39:57 2015
New Revision: 66244
URL: http://svn.reactos.org/svn/reactos?rev=66244&view=rev
Log:
[NtUser]
- Use a real timer for caret. This should cleanup message testing from those
random system timer messages. See CORE-7447.
Modified:
trunk/reactos/win32ss/user/ntuser/caret.c
Modified: trunk/reactos/win32ss/user/ntuser/caret.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/caret.c
?rev=66244&r1=66243&r2=66244&view=diff
============================================================================
==
--- trunk/reactos/win32ss/user/ntuser/caret.c [iso-8859-1] (original)
+++ trunk/reactos/win32ss/user/ntuser/caret.c [iso-8859-1] Fri Feb 13
13:39:57 2015
@@ -16,6 +16,111 @@
/* FUNCTIONS
*****************************************************************/
+VOID FASTCALL
+co_IntDrawCaret(PWND pWnd, PTHRDCARETINFO CaretInfo)
+{
Hey Timo,
nice stuff, but I think you committed a bit too fast ;-)
See inline:
Le 13/02/2015 21:19, tkreuzer(a)svn.reactos.org a écrit :
> Author: tkreuzer
> Date: Fri Feb 13 20:19:51 2015
> New Revision: 66250
>
> URL: http://svn.reactos.org/svn/reactos?rev=66250&view=rev
> Log:
> [CMAKE]
> Add support for "module groups". These are meta targets that automatically include all targets using set_module_type() that are included between start_module_group(name) and end_module_group().
>
> Modified:
> trunk/reactos/cmake/CMakeMacros.cmake
>
> Modified: trunk/reactos/cmake/CMakeMacros.cmake
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/CMakeMacros.cmake?re…
> ==============================================================================
> --- trunk/reactos/cmake/CMakeMacros.cmake [iso-8859-1] (original)
> +++ trunk/reactos/cmake/CMakeMacros.cmake [iso-8859-1] Fri Feb 13 20:19:51 2015
> @@ -550,9 +550,14 @@
> message(STATUS "set_module_type : unparsed arguments ${__module_UNPARSED_ARGUMENTS}, module : ${MODULE}")
> endif()
>
> + # Add the module to the module group list, if it is defined
> + if(DEFINED CURRENT_MODULE_GROUP)
> + set_property(GLOBAL APPEND PROPERTY ${CURRENT_MODULE_GROUP}_MODULE_LIST "${MODULE}")
> + endif()
> +
> # Set subsystem. Also take this as an occasion
> # to error out if someone gave a non existing type
> - if((${TYPE} STREQUAL nativecui) OR (${TYPE} STREQUAL nativedll)
> + if((${TYPE} STREQUAL nativecui) OR (${TYPE} STREQUAL nativedll)
> OR (${TYPE} STREQUAL kernelmodedriver) OR (${TYPE} STREQUAL wdmdriver) OR (${TYPE} STREQUAL kerneldll))
> set(__subsystem native)
> elseif(${TYPE} STREQUAL win32cui)
> @@ -662,6 +667,21 @@
>
> # do compiler specific stuff
> set_module_type_toolchain(${MODULE} ${TYPE})
> +endfunction()
> +
> +function(start_module_group __name)
> + if(DEFINED CURRENT_MODULE_GROUP)
> + message(FATAL_ERROR "CURRENT_MODULE_GROUP is already set ('${CURRENT_MODULE_GROUP}')")
> + endif()
> + set(CURRENT_MODULE_GROUP rostests PARENT_SCOPE)
> +endfunction()
> +
should be
set(CURRENT_MODULE_GROUP ${__name} PARENT_SCOPE)
> +function(end_module_group)
> + get_property(__modulelist GLOBAL PROPERTY ${CURRENT_MODULE_GROUP}_MODULE_LIST)
> + add_custom_target(${CURRENT_MODULE_GROUP})
> + foreach(__module ${__modulelist})
> + add_dependencies(${CURRENT_MODULE_GROUP} ${__module})
> + endforeach()
> endfunction()
You should unset CURRENT_MODULE_GROUP somewhere aroud here.
>
> function(preprocess_file __in __out)
>
>
Hi,
I tried to do an SVN DCommit (git-svn) using TGIT. It used to work
flawlessly. I didn't change anything in my checkout, but suddenly it
doesn't work anymore and I get an error:
ERROR from SVN:
Authorization failed: Cannot negotiate authentication mechanism
I'd appeceate if someone could fix that.
Otherwise ... you'll not get the nice fixes I have in my repo.
I'm not going to move them over to SVN!
Thanks,
Timo
Hi all,
The long-announced Mumble Server is finally live! I've put up all
instructions on our Wiki: https://reactos.org/wiki/Mumble
I've resembled the structure of our IRC channels, meaning there is a
general "ReactOS" channel open for everybody and a channel "ReactOS-Dev"
for authenticated users only. There will also be international channels
for easier discussions in your native language. On top of this,
everybody can create temporary channels for short discussions.
You login with your ReactOS Development Account (aka SVN account) to
become authenticated. If you don't have such an account, choose an
arbitrary username and join the open channels.
I'm also looking for ReactOS members willing to serve as Mumble
administrators. Just like on IRC, this gives you additional rights, like
creating permanent channels or kicking and banning people. As this also
allows you to modify permissions, I don't like to give this status to
every authenticated user. So far, only Pierre and me are administrators
on Mumble. Volunteers are welcome!
I think it makes no sense to set up even more rules right now before
people have checked it out, so let's all give it a try and see how we
can work with it. In a next step, we could announce it on the website
and even use Mumble for the monthly meetings.
Cheers,
Colin
Hi all,
FOSDEM 2015 has ended some days ago. After five years of absence, the
ReactOS Project was finally represented with a stand again, maintained
by Aleksey Bragin, Giannis Adamopoulos, Pierre Schweitzer and me.
Turns out that FOSDEM has significantly grown over the recent years,
so our experiences really deserve a report - and should motivate
others to join us next time! :)
Our stand was born around 11 o'clock on Saturday when I arrived at the
AW building. After walking several rounds in the building and neither
finding known people nor a free table, it turned out that the coreboot
guys next to us had tried to expand their presence a bit ;)
Reclaiming our booth was a matter of a few words though, and soon we
had a sweet spot in the building with enough space for the upcoming
crowd. With Aleksey arriving shortly after that, along with several
flags and pins, our empire was finally alive and marked! Giannis and
Pierre arrived in the course of the day, right in time for the
afternoon rush hour with lots of people interested in ReactOS. Our
four person booth staff was really overwhelmed in these times. But
let's see, maybe we even got new developers through this :)
Our stock of 100 ReactOS demonstration CDs prepared by Hermès
Bélusca-Maito and me already ran out during the first day. Given our
experiences at other exhibitions and the general phase-out of CDs
these days, this came totally unexpected. But it wouldn't be the
ReactOS Project if we had no solution to the problem. On the same
Saturday evening, Pierre and me went out on a little adventure into
downtown Brussels in the hope of finding open stores that sell all we
needed: Blank CDs, labels and paper sleeves. And we were successful!
Returning with another 100 CDs, all disc drives of our laptops were
working that evening and the full other day, busy with burning new
ReactOS CDs. FOSDEM staff was kind enough to offer one of their
printers for getting the additional labels done. And our booth on
Sunday had partly turned into a CD manufacturing plant. With the
consequence of people sometimes grabbing the CD labels and trying to
read them before being presented with our real flyers :)
At the end of the conference, around 170 ReactOS CDs were in the wild.
Definitely much more than what we expected!
Of course, the culinary supply also didn't come too short in the
capital of Belgium. On Saturday evening, we met up with our friend
Nuno Brito, who had already reserved a nice restaurant for us.
Obviously, he had learned from last year! I well remember the evening,
when five hungry geeks walked for half an hour through the city,
trying to beat the unsolvable problem of finding the best restaurant
for all of us.
I've put up some of Aleksey's and my photos here:
https://www.flickr.com/photos/colinfinck/sets/72157650656130121/
Maybe more to come in the next few days!
I hope you're now all eager to join us next time to this wonderful event!
Cheers,
Colin
P.S.: Feel free to use this for a news article about FOSDEM on our website
On 01.02.2015 23:22, hbelusca(a)svn.reactos.org wrote:
> Author: hbelusca
> Date: Sun Feb 1 20:22:13 2015
> New Revision: 66144
>
> URL: http://svn.reactos.org/svn/reactos?rev=66144&view=rev
> Log:
> [FREELDR]
> - Fix date format in CHANGELOG (that uses that #$@! of US format)
> - Diverse code style changes (whitespace, extra braces, C++ to C-style comments, ...)
> ==============================================================================
> --- trunk/reactos/boot/freeldr/freeldr/CHANGELOG [iso-8859-1] (original)
> +++ trunk/reactos/boot/freeldr/freeldr/CHANGELOG [iso-8859-1] Sun Feb 1 20:22:13 2015
> @@ -1,4 +1,4 @@
> -Changes in v3.0+ (05/01/2015) (hbelusca)
> +Changes in v3.0+ (01/05/2015) (hbelusca)
Don't make our dear American contributors feel offended! :-)
Also there is ISO 8601 standard, you know, the big-endian style YYYY-MM-DD.
Regards,
Aleksey Bragin
Why are you moving a file out of the i386 folder and then add #ifdef
_M_IX86 around all the code???
Am 01.02.2015 um 18:49 schrieb hbelusca(a)svn.reactos.org:
> --- trunk/reactos/boot/freeldr/freeldr/arch/i386/custom.c [iso-8859-1] (original)
> +++ trunk/reactos/boot/freeldr/freeldr/custom.c [iso-8859-1] Sun Feb 1 17:49:11 2015
> @@ -19,6 +19,7 @@
>
> #include <freeldr.h>
>
> +#ifdef _M_IX86
>
> const CHAR BootDrivePrompt[] = "Enter the boot drive.\n\nExamples:\nfd0 - first floppy drive\nhd0 - first hard drive\nhd1 - second hard drive\ncd0 - first CD-ROM drive.\n\nBIOS drive numbers may also be used:\n0 - first floppy drive\n0x80 - first hard drive\n0x81 - second hard drive";
> const CHAR BootPartitionPrompt[] = "Enter the boot partition.\n\nEnter 0 for the active (bootable) partition.";
> @@ -448,3 +449,5 @@
> DiskStopFloppyMotor();
> Reboot();
> }
> +
> +#endif // _M_IX86
I hope you are not talking about the ... Right arm? ^^Am 01.02.2015 00:27 schrieb Hermès BÉLUSCA - MAÏTO <hermes.belusca(a)sfr.fr>:
>
> And after that, people go to #reactos by mistake to ask for Java-related questions... By the way, if one believes Wikipedia, this ReactJS was created in 2013: http://en.wikipedia.org/wiki/ReactJS
>
> <troll>Now… look carefully at the video around 0:40 up to 0:50… \o ^^ </troll>
>
>
>
> De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Timo Kreuzer
> Envoyé : samedi 31 janvier 2015 22:50
> À : ReactOS Development List
> Objet : Re: [ros-dev] ReactOS trademark and logo violation
>
>
>
>
> I agree this is pretty nasty. Too much consonance for me to believe in accidental coincidence. ("ReactJS"? Srsly?)
>
> Are we going to sue them?
> Let's make them PAY! :D
>
>
> Am 31.01.2015 um 20:01 schrieb Alexander Rechitskiy:
>>
>> I clearly see that ReactOS trademark and logo are violated by Facebooks' ReactJS project
>>
>>
>>
>> http://www.youtube.com/watch?v=KVZ-P-ZI6W4
>>
>>
>>
>> --
>>
>> Best regards,
>> Alexander Rechitskiy
>>
>> +79286331900
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Ros-dev mailing list
>>
>> Ros-dev(a)reactos.org
>>
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
On 2014-12-15 22:07, hbelusca(a)svn.reactos.org wrote:
> +1 stub -noname ShellGetUserList ; (long long long)
For future reference, you might as well write this kind of thing as
1 stdcall -stub -noname ShellGetUserList(long long long)
Then spec2def will create a stub that uses the correct calling
convention and also prints out the arguments. Plus it's easier to
change to the real thing when someone implements it ;)
On 24/01/2015 01:15, hbelusca(a)svn.reactos.org wrote:
> ==============================================================================
> --- trunk/reactos/tools/cdmake/dirhash.c [iso-8859-1] (original)
> +++ trunk/reactos/tools/cdmake/dirhash.c [iso-8859-1] Sat Jan 24 00:15:08 2015
> @@ -138,12 +138,14 @@
> hashcode = djb_hash(targetnorm);
> de = calloc(1, sizeof(*de));
> de->parent = parent_de;
> + de->head = NULL;
> + de->child = NULL;
de has been allocated few lines upper with calloc.
head & child CANNOT be different from NULL.
This is non sense.
> @@ -170,6 +172,7 @@
> tf->target_name = strdup(chop_filename(target));
> }
>
> +#if 0
> static struct target_dir_entry *
> dir_hash_next_dir(struct target_dir_hash *dh, struct target_dir_traversal *t)
> {
> @@ -200,13 +203,13 @@
> return t->it;
> }
> }
> +#endif
Once again, this is trunk, not your working copy.
If you 0 out, please add a comment explaining it's just unused and not
buggy.
And actually, because it's trunk & unusued, it would be better just to
remove them. svn history can help finding them back if really needed.
> ==============================================================================
> --- trunk/reactos/tools/cdmake/dirhash.h [iso-8859-1] (original)
> +++ trunk/reactos/tools/cdmake/dirhash.h [iso-8859-1] Sat Jan 24 00:15:08 2015
> @@ -26,11 +26,13 @@
> struct target_dir_entry root;
> };
>
> +#if 0
> struct target_dir_traversal
> {
> struct target_dir_entry *it;
> int i;
> };
> +#endif
See comment above.
Cheers,
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Hi all,
We're still preparing merchandising products for FOSDEM, and flyers are
probably most important here and still doable in time.
Can somebody please take the template from
https://svn.reactos.org/press-media/trunk/Events/2009%20-%20FOSDEM/Flyer/ and
alter it a bit to reflect current ReactOS state?
The best would be a flyer not including a certain ReactOS version
number, so that it is universally usable.
If you don't have InDesign to modify the file, just send me the modified
text here.
Thanks!
Colin
Dear all,
Just to make sure you read it: https://www.reactos.org/node/928
The SVN accounts are not affected.
Cheers,
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Hi all !
Our build system is now able to build so-called hybrid cds . What are
they?
They are boot+live-cd all-in-one. In addition it is now possible with them
to load the live cd as a ramdisk. For that the contents of the bootcd is
placed into a bootcd/ directory, the contents of the livecd is placed into a
livecd/ directory, and the livecd image itself is also included (this is the
one that is used for livecd ramdisk). You can notice that makes a lot of
redundancy, but its the best thing I could do for now. The best way would
be to build some kind of flat HDD image that is used as the livecd ramdisk
(and never use the livecd with reads from the cd as we currently do ) .
Anyways.
So here it is !
In addition you can add extra custom files via the build process: just place
your files into a <your_ROS_source>/modules/hybridcd_extras/ directory (this
directory doesnt exist by default, its up to you to create and populate
it; I think its better to create a directory somewhere else and then add a
symlink hybridcd_extras to this directory, inside the modules/ directory,
as you already do with rosapps and rostests).
After that you configure a build, build the host-tools and then ninja
hybridcd !!
If then you need to change the custom files, do it and then reconfigure a
build with the cmake . command (when youre inside
<your_ROS_builddir>/reactos/ ) so that cmake can build again the list of
files to be included into the hybridcd.
See https://jira.reactos.org/browse/CORE-9069 for few more details.
Cheers,
Hermès.