I don't really like this. Maybe only do this on the build server, or at
least don't do it to kernel code. "Measurable" difference in performance
doesn't really mean much on an OS that does not have any performance
infrastructure, but trust me, there's a difference between O1 and O2.
Best regards,
Alex Ionescu
On Wed, Jul 31, 2013 at 6:04 AM, <akhaldi(a)svn.reactos.org> wrote:
> Author: akhaldi
> Date: Wed Jul 31 13:04:38 2013
> New Revision: 59598
>
> URL: http://svn.reactos.org/svn/reactos?rev=59598&view=rev
> Log:
> [CMAKE/GCC]
> * Compile debug builds using -O1 instead of -Os. This results in faster
> compilation time with no measurable difference in runtime performance
> according to tests.
> CORE-7374 #resolve #comment Committed in r59598.
>
> Modified:
> trunk/reactos/cmake/config.cmake
>
> Modified: trunk/reactos/cmake/config.cmake
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/config.cmake?rev=595…
>
> ==============================================================================
> --- trunk/reactos/cmake/config.cmake [iso-8859-1] (original)
> +++ trunk/reactos/cmake/config.cmake [iso-8859-1] Wed Jul 31 13:04:38
> 2013
> @@ -10,7 +10,7 @@
> set(TUNE "i686" CACHE STRING
> "Which CPU ReactOS should be optimized for.")
>
> -set(OPTIMIZE "1" CACHE STRING
> +set(OPTIMIZE "4" CACHE STRING
> "What level of optimization to use.
> 0 = off
> 1 = Default option, optimize for size (-Os) with some additional options
>
>
>
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 25th of Julu, 19:00 UTC. Put that into your
calendars so you don't forget.
I will handle the technical side of the meeting and you will get your
login credentials shortly before the meeting. If someone still is not
getting passwords sent before a meeting - please email Colin or Pierre
before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (preferably send them to me before the meeting starts).
Regards,
Aleksey Bragin
Hi,
For all TSVN users: the new version 1.8.0 is broken. Merging doesn't
work and aborts once you get a conflict. I had to install a nightly to
make that work.
Also: it uses a new working copy format, which is incompatible with
older svn versions, like the one we use in RosBE. Which you would also
need to update.
Therefore I suggest to not update it yet, unless you really know what
you are doing. I don't want to hear complaints later ;-)
Timo
Am 30.06.2013 15:11, schrieb hbelusca(a)svn.reactos.org:
> weird indentation made by a mix of tabs / spaces which take either 4 or 8 or even (!!) 2 spaces per indentation level
That is called GNU coding style.
You should get a copy of the GNU coding standards.
And then treat it the way Linus T. suggests ;-)
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 27th of June, 19:00 UTC. And that's tomorrow!
Put that into your calendars so you don't forget.
The meeting will be at irc://dev.reactos.org (Port 6667, no SSL) in the
channel #meeting, or as Pierre says. Note that the IRC service will only
be started shortly before the meeting. Your participation passwords will
be emailed to you shortly before the meeting starts, and they are going
to be different once again as they are not stored in any database.
Hopefully it's not much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Colin or Pierre before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to me shortly before the meeting starts).
Regards,
Aleksey Bragin
Hi All,
A few months ago, an SVN branch, vs_jc, was created so that I could
experiment with manual creation of Visual Studio solution. I am ready to
start putting files into it, but before I do, I would like to get it synced
with the trunk. Unfortunately, I am not very experienced with SVN (more like
hopelessly ignorant), and Id like to avoid making a mess if possible. I was
hoping that someone could sit with me for the 10-15 minutes that would be
needed to get it right so that I dont make a mess. Hermès was helping me
yesterday do a merge, but he seems to be out-of-pocket at the moment, and
Id rather not wait, as I am blocking the work of others.
The merge generated a lot of conflicts, and I see no option on Tortoise SVN
menu to resolve them, and I have tried 6 or 7 times myself to do a merge,
each time not being clear on what I am doing. I would have no problem
whatsoever blowing away vs_jc and simply branching HEAD-of-trunk and
starting over, as there is currently nothing that I put in vs_jc that is of
value.
Cheers!
-JC
That is still not correct. MM_DECOMMIT (which should be aliased as
MM_GUARDPAGE) is 0x10.
BUT, this is only a guardpage, if 0x8, aka MM_NOCACHE is not set.
it's like this:
Protection & 0x18 ==
0x00: normal
0x08: uncached
0x10: guard page
0x18: write combined
see http://www.reactos.org/wiki/Techwiki:Memory_Protection_constants
Am 16.06.2013 22:37, schrieb dreimer(a)svn.reactos.org:
> Author: dreimer
> Date: Sun Jun 16 20:37:04 2013
> New Revision: 59238
>
> URL: http://svn.reactos.org/svn/reactos?rev=59238&view=rev
> Log:
> logical 'and' applied to non-boolean constant
> Reviewed by Thomas Faber and asked for commit, so blame him!
> CORE-7207 #resolve #comment Fixed!
>
> Modified:
> trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c
>
> Modified: trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] Sun Jun 16 20:37:04 2013
> @@ -647,7 +647,7 @@
> (EndAddress >= ((PMMVAD_LONG)Vad)->u3.Secured.StartVpn))
> {
> /* Guard page? */
> - if (ProtectionMask && MM_DECOMMIT)
> + if (ProtectionMask & MM_DECOMMIT)
> {
> DPRINT1("Not allowed to change protection on guard page!\n");
> return STATUS_INVALID_PAGE_PROTECTION;
>
>
>
( end of the message) , and its more elegant than many (str[i] !=
prefix[i] || ) instructions.
Maybe youre criticizing this change because of performances reasons ?
Cheers
Hermès
De : Hermès BÉLUSCA - MAÏTO [mailto:hermes.belusca@sfr.fr]
Envoyé : lundi 3 juin 2013 11:10
À : 'ReactOS Development List'
Objet : RE: [ros-dev] [ros-diffs] [hbelusca] 59165: [RTL] Use
RtlPrefixUnicodeString.
It was suggested by Thomas Faber, during some fixes of path.c
De : ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] De la
part de Alex Ionescu
Envoyé : lundi 3 juin 2013 04:33
À : ReactOS Development List
Cc : Linda Wang
Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 59165: [RTL] Use
RtlPrefixUnicodeString.
You should realize there's sometimes a reason why code doesn't use an
existing helper function. Among some very good bug fixes and patches, you
really seem to love changing code just for the sake of changing code.
Best regards,
Alex Ionescu
On Sun, Jun 2, 2013 at 3:51 PM, <hbelusca(a)svn.reactos.org> wrote:
Author: hbelusca
Date: Sun Jun 2 22:51:24 2013
New Revision: 59165
URL: http://svn.reactos.org/svn/reactos?rev=59165
<http://svn.reactos.org/svn/reactos?rev=59165&view=rev> &view=rev
Log:
[RTL]
Use RtlPrefixUnicodeString.
Modified:
trunk/reactos/lib/rtl/path.c
Modified: trunk/reactos/lib/rtl/path.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/path.c?rev=59165
<http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/path.c?rev=59165&r
1=59164&r2=59165&view=diff> &r1=59164&r2=59165&view=diff
============================================================================
==
--- trunk/reactos/lib/rtl/path.c [iso-8859-1] (original)
+++ trunk/reactos/lib/rtl/path.c [iso-8859-1] Sun Jun 2 22:51:24
2013
@@ -479,13 +479,19 @@
/* Capture input string */
CapturedDosName = *DosName;
- /* Check for \\?\ form */
- if ((CapturedDosName.Length <= RtlpWin32NtRootSlash.Length) ||
- (CapturedDosName.Buffer[0] != RtlpWin32NtRootSlash.Buffer[0]) ||
- (CapturedDosName.Buffer[1] != RtlpWin32NtRootSlash.Buffer[1]) ||
- (CapturedDosName.Buffer[2] != RtlpWin32NtRootSlash.Buffer[2]) ||
- (CapturedDosName.Buffer[3] != RtlpWin32NtRootSlash.Buffer[3]))
- {
+ /* Check for the presence of the NT prefix "\\?\" form */
+ if (RtlPrefixUnicodeString(&RtlpWin32NtRootSlash, &CapturedDosName,
FALSE))
+ {
+ /* NT prefix is contained in the path */
+
+ /* Use the optimized path after acquiring the lock */
+ QuickPath = TRUE;
+ NewBuffer = NULL;
+ }
+ else
+ {
+ /* NT prefix is not contained in the path */
+
/* Quick path won't be used */
QuickPath = FALSE;
@@ -497,12 +503,6 @@
NewBuffer = RtlAllocateHeap(RtlGetProcessHeap(), 0, MaxLength);
DPRINT("MaxLength: %lx\n", MaxLength);
if (!NewBuffer) return STATUS_NO_MEMORY;
- }
- else
- {
- /* Use the optimized path after acquiring the lock */
- QuickPath = TRUE;
- NewBuffer = NULL;
}
/* Lock the PEB and check if the quick path can be used */
Revisions >= 59161 are fine (before starting with 59152 they are broken
- known).
This is only due to a VMware testbot internal failure. This is now fixed.
Sorry for the flood.
On 03/06/2013 00:28, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Linux_AMD64_2 VMWPlayer-Test while building ReactOS.
> Full details are available at:
> http://build.reactos.org/builders/Linux_AMD64_2%20VMWPlayer-Test/builds/985
>
> Buildbot URL: http://build.reactos.org/
>
> Buildslave for this Build: Linux_AMD64_2
>
> Build Reason: Triggerable(Linux_AMD64_1 KVM-Test Trigger)
> Build Source Stamp: 59161
> Blamelist:
>
> BUILD FAILED: failed test
>
> sincerely,
> -The Buildbot
>
>
>
>
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation