I have a doubt:
==============================================================================
--- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Wed Dec 22 21:59:27 2010
@@ -2446,6 +2446,9 @@
/* Check if this VAD is too high */
if (BaseVpn < Vad->StartingVpn)
{
+ /* Stop if there is no left child */
+ if (!Vad->LeftChild) break;
+
/* Search on the left next */
Vad = Vad->LeftChild;
}
@@ -2453,6 +2456,11 @@
{
/* Then this VAD is too low, keep searching on the right */
ASSERT(BaseVpn > Vad->EndingVpn);
+
+ /* Stop if there is no right child */
+ if (!Vad->LeftChild) break;
+
+ /* Search on the right next */
Vad = Vad->RightChild;
}
}========================================================
Look these lines:
+ /* Stop if there is no left child */
+ if (!Vad->LeftChild) break;
+ /* Stop if there is no right child */
+ if (!Vad->LeftChild) break;
1) Is there a typo in the copy-pasta condition?
2) Is the comment wrong or misleading?
3) Am I a complete noob?
I think the order is 3), 1), 2)
One of the latest changes has made ReactOS totally uninstallable(12 tries /12 fails) using less than 192MB Ram.It halts in first stage during copying files.
Merry Christmas!!
Hi!
I guess once long tyme ago, there was a little file called dos.h!
Need this #define _A_VOLID 0x08 /* Volume ID file */
VolumeLabelDirEntry.Fat.Attrib = 0x08;
}
I'm not able to get the wubble simulation working for the ua-ros-pkg at:
http://code.google.com/p/ua-ros-pkg
[Note: I'm a new comer to ROS]
Summary of Issue:
I am using the Q&A Format provided by the site above.
a. What steps will reproduce the problem?
1. Follow http://code.google.com/p/ua-ros-pkg/wiki/DeveloperInstall to
install uav-ros-pkg packages
2. Run roslaunch wubble_mapping simulation.launch
b. What is the expected output? What do you see instead?
Expected output: Runs as given in
http://code.google.com/p/ua-ros-pkg/wiki/ClassInstructions.
Observed output:
--------------
while processing
/opt/ros/cturtle/stacks/ua-ros-pkg-read-only/arrg/wubble_world/wubble_environments/launch/empty_blocks_world.launch:
while processing
/opt/ros/cturtle/stacks/ua-ros-pkg-read-only/arrg/wubble_world/wubble_environments/launch/world_common.launch:
Invalid roslaunch XML syntax: [Errno 2] No such file or directory:
u'/opt/ros/cturtle/stacks/ua-ros-pkg-read-only/arrg/wubble_world/wubble_environments/launch/world_common.launch'
------------
c. What version of the product are you using? On what operating system?
Latest trunk, on Ubuntu 10.04 /Lucid.
d. Additional Notes?
world_common isn't there in the given files, and neither does it get
generated during the build. Also, while running make-all.sh I get 'Built 46
packages with 1 failure'. My gearbox
has the following issue during the build:
==========================
mkdir -p build/gearbox-svn/build
cd `rospack find gearbox` && patch -d
build/gearbox-svn/src/hokuyo_aist/python --verbose < `rospack find
gearbox`/aist_python_mt.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- CMakeLists.txt 2010-11-05 17:13:52.719057243 -0700
|+++ CMakeLists.txt.ros 2010-11-05 17:12:30.921672551 -0700
--------------------------
Patching file CMakeLists.txt using Plan A...
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
Hunk #1 ignored at 41.
1 out of 1 hunk ignored -- saving rejects to file CMakeLists.txt.rej
done
===========================
I wonder whether this is causing the problem, and am not totally clear as to
how to correct this.
Thanks!
--
Ganesh
$ g++ file.c -fblocks -Wall /usr/lib/bundle1.o -arch x86_64 -o file.out
pschweitzer(a)svn.reactos.org wrote:
>
> ASSERT(Name->Length);
> ASSERT(Expression->Length);
> ASSERT(!FsRtlDoesDbcsContainWildCards(Name));
It'd be preferable to wrap that last ASSERT so it isn't compiled into release builds.
Adding functions into asserts adds overhead on release builds as they're called for no reason.
Ged.
Hello all,
I'm currently developing two project tools which are going to be used by
the German ReactOS foundation (custom IRC Server and plugin for Jameica
- http://www.willuhn.de/products/jameica/).
They shall be committed into a public ReactOS SVN repository.
Since I believe that these tools are hardly useful for the average
ReactOS developer, I don't want to commit them to our current
/trunk/tools directory in the "reactos" repository. Among other
disadvantages, every commit to them would trigger a useless BuildBot
build, source checkouts would include unnecessary stuff, etc.
As this is generally the case with most of the stuff in /trunk/tools,
I'd like to move everything below this directory and the /irc directory
into a new repository called "project-tools".
We have already done a similar step in the past for the former "web"
directory.
Additionally, the "press-media" directory would be a similar candidate
for an own "press-media" repository. After these steps, our "reactos"
repository would finally contain only OS development related stuff.
For comparison, Wine already keeps its main repository free from
unrelated stuff and has several similar repositories (see
http://source.winehq.org/git/).
If there are no objections to my idea within the next two weeks, I will
proceed and set up "project-tools" and "press-media" repositories
(preserving as much SVN history as possible).
Cheers,
Colin
A worthy commit for r50000.
You've been waiting for this revision, haven't you .... haha.
Ged
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of fireball(a)svn.reactos.org
Sent: 10 December 2010 09:33
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [fireball] 50000: [HEAP] - Time has come to get rid of a slightly modified implementation of WINE's heap, which is a hack based on Windows 95's heap implementation, itself a hack of DOS memory mana...
Author: fireball
Date: Fri Dec 10 09:33:20 2010
New Revision: 50000
URL: http://svn.reactos.org/svn/reactos?rev=50000&view=rev
Log:
[HEAP]
- Time has come to get rid of a slightly modified implementation of WINE's heap, which is a hack based on Windows 95's heap implementation, itself a hack of DOS memory management. It supported 3 out of the 18 possible NT Heap Flags, did not support custom allocation/deallocation routines, and was about 50-80x slower with fragmentation rates up to 500x higher when compared to NT's LFH (WINE is lucky because the advanced NT Heap features are used in kernel-mode usually, not in user-mode, and they are crossing their fingers for this being the same). Several high-end SQL/Database applications would significantly benefit from custom heap features provided by NT. Not to say about removing crappy support for a custom Commit routine and crappy support for User-defined flags and the User-defined value.
- So, the glorious moment for a new heap manager, which is (to remind you) a totally new heap manager, resembling real NT heap manager, based on data structures similar to Windows 2003 and Vista+'s heap structures, supporting advanced heap flags (e.g. useful for debugging), having substantially lower fragmentation rates (and thus speed and reliability), having native support for user-defined flags and user-defined values, also native support for a custom commit routine, which is very important for trunk's win32 subsystem. It also reserves, commits, decommits and frees memory on the fly, unlike existing heap manager which prefers to reserve and commit as much as possible, and doesn't decommit when it's no longer necessary. Not to say about support for per process heaps, with a proper lock, and a further support for a special so-called debug heap allocator (to be implemented in heapdbg.c) which will be useful for finding heap corruptions.
Yeah, I'm not a fun person :D
Added:
trunk/reactos/lib/rtl/heap.c
- copied unchanged from r49999, trunk/reactos/lib/rtl/heap_rewrite.c
Removed:
trunk/reactos/lib/rtl/heap_rewrite.c
[This mail would be too long, it was shortened to contain the URLs only.]
Removed: trunk/reactos/lib/rtl/heap_rewrite.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/heap_rewrite.c?rev…