.docs

git-svn-id: svn://ultimatepp.org/upp/trunk@8237 f0d560ea-af0d-0410-9eb7-867de7ffcac7

uppsrc/Core/SSL/init

@@ -1,9 +1,9 @@
 #ifndef _Core_SSL_icpp_init_stub
 #define _Core_SSL_icpp_init_stub
-#define BLITZ_INDEX__ F6fe5614ef3a94410532ec46bf6f89f79
+#define BLITZ_INDEX__ F2a01c2597c8c635f342bbb222556fa5c
 #include "InitExit.icpp"
 #undef BLITZ_INDEX__
-#define BLITZ_INDEX__ Fec819124718579f995f63faaf305d128
+#define BLITZ_INDEX__ F20fd197ce515f45c6284ecc270cf38ca
 #include "Socket.icpp"
 #undef BLITZ_INDEX__
 #endif

uppsrc/Core/srcdoc.tpp/CoreTutorial$en-us.tpp

@@ -569,7 +569,4 @@ GetHashValue method defines GetHashValue function too.&]
 [s7; &]
 [s16; GetHashValue(x) `= 3378606405&]
 [s7; &]
-[s0; &]
-[s0; &]
-[s0; &]
-[s0; [/ (to be continued)]]]
+[s0;/ ]]

uppsrc/Core/srcdoc.tpp/Decisions$en-us.tpp

@@ -39,7 +39,7 @@ pragmatic resolution `- our experience is that it is quite hard
 and annoying to achieve robustness here and it cannot be reliably 
 tested. Also, most platforms with virtual memory will almost 
 freeze long before out`-of`-memory problem due to intensive page 
-swapping. Connected issue `- default and copy constructors are 
+swapping. Related issue `- default and copy constructors are 
 not allowed to throw exceptions in U`+`+ (the common reason to 
 throw exception here was out`-of`-memory condition). This limitation 
 will be removed in future releases.&]
@@ -47,12 +47,12 @@ will be removed in future releases.&]
 (including GUI elements, like number of rows in DropList) is 
 2][%%` 31 ][%% `- 1 `= ]2,147,483,647.&]
 [s0;i150;b33;O0; GUI is designed in a way that all user events are 
-passed and processed the main thread. The synchronization is 
-done using single global mutex (operated by EnterGuiMutex, LeaveGuiMutex 
-or GuiLock scoped helper). Other threads can directly work with 
-GUI as long they do use this global mutex. There are some operations 
-(like opening/closing windows, message loops) that cannot be 
-performed by any other thread than main.&]
+passed and processed by the main thread. The synchronization 
+is done using single global mutex (operated by EnterGuiMutex, 
+LeaveGuiMutex or GuiLock scoped helper). Other threads can directly 
+work with GUI as long they do use this global mutex. There are 
+some operations (like opening/closing windows, message loops) 
+that cannot be performed by any other thread than main.&]
 [s0;i150;b33;O0; U`+`+ does not use OS`-native widgets. The main 
 reason for this is to achieve widget interface model optimal 
 for rapid development. The less important reason is that this 

uppsrc/Core/srcdoc.tpp/NTLvsSTL$en-us.tpp

@@ -40,7 +40,7 @@ of containers.&]
 (most) `'`=`' cases, with `&`& based move semantics for specific 
 or explicit cases (std`::move). NTL requires to specify the mode 
 of transfer with `'pick`' (corresponds to std`::move) or `'clone`' 
-functions in all cases, except the assignement of temporary value 
+functions in all cases, except the assignment of temporary value 
 (where the final semantics is the same).&]
 [s3; Random access and random access notation&]
 [s5; STL uses iterators as the preferred way how to access and identify 
@@ -58,7 +58,7 @@ ndex], is introduced, as an ideal building block for all kinds
 of associative operations.&]
 [s5; [* InVector, Sorted maps]&]
 [s5; NTL provides random access containers with fast insertion at 
-arbitrary position, which scales well to milions of items. This 
+arbitrary position, which scale well to milions of items. This 
 is then based to create `'sorted maps`' that are using binary 
 search.&]
 [s3; Algorithm requirements&]

uppsrc/Core/srcdoc.tpp/Tutorial$en-us.tpp

@@ -586,7 +586,7 @@ but they trade the speed of operator`[`] with the ability to
 insert or remove elements at any position quickly. You can expect 
 operator`[`] to be about 10 times slower than in Vector (but 
 that is still very fast), while Insert at any position scales 
-well up to hunderds of megabytes of data (e.g. InVector containing 
+well up to hundreds of megabytes of data (e.g. InVector containing 
 100M of String elements is handled without problems).&]
 [s7; -|InVector<int> v;&]
 [s7; -|for(int i `= 0; i < 1000000; i`+`+)&]
@@ -599,7 +599,7 @@ well up to hunderds of megabytes of data (e.g. InVector containing
 to Vector/Array, InVector/InArray in addition implements FindLowerBound/FindUpper
 Bound functions `- while normal random access algorithms work, 
 it is possible to provide InVector specific optimization that 
-basically matches the performace of Find`*Bound on somple Vector.&]
+basically matches the performace of Find`*Bound on sample Vector.&]
 [s7; &]
 [s7; -|DUMP(v.FindLowerBound(55));&]
 [s7; &]
@@ -607,7 +607,7 @@ basically matches the performace of Find`*Bound on somple Vector.&]
 [s5; SortedIndex is similar to regular Index, but keeps its elements 
 in sorted order (sorting predicate is a template parameter, defaults 
 to StdLess). Implementation is using InVector, so it works fine 
-even with very large number of elements (performace is similar 
+even with very large number of elements (performance is similar 
 to tree based std`::set). Unlike Index, SortedIndex provides lower/upper 
 bounds searches, so it allow range search.&]
 [s7; -|SortedIndex<int> x;&]

uppsrc/Core/srcdoc.tpp/pick_$en-us.tpp

@@ -31,14 +31,14 @@ in `"picked`" state and number of operations that can be performed
 on it is limited. In most cases, only allowed operations here 
 are operator`=, destructor and Clear. This one of reasons for 
 having `'pick`' function (and using term `'pick`' instead of 
-`'move`', even if the semantics is about the same as `'std`::move`'.&]
+`'move`', even if the semantics is about the same as `'std`::move`').&]
 [s7; Vector<int> a, b;&]
 [s7; a `= pick(b); // moves content of b to a, b is put into picked 
 state&]
 [s7; b `= clone(a); // a and b now contain the same data&]
 [s3; C`+`+03 compatibility&]
 [s5; In ideal world, we would be now using only C`+`+11. In real 
-world, we will need to support C`+`+03 for forseeable future.&]
+world, we will need to support C`+`+03 for foreseeable future.&]
 [s5; pick constructor/operator`= in C`+`+11 can obviously use&]
 [s7; T(T`&`&);&]
 [s7; T`& operator`=(T`&`&);&]

uppsrc/ide/ide.lay

@@ -61,13 +61,13 @@ LAYOUT(RunLayout, 420, 172)
 	ITEM(Label, stdout_file_lbl, SetLabel(t_("STDOUT file:")).LeftPosZ(4, 112).TopPosZ(52, 19))
 	ITEM(WithDropChoice<EditString>, stdout_file, HSizePosZ(120, 4).TopPosZ(52, 19))
 	ITEM(Label, dv___6, SetLabel(t_("Standard output:")).LeftPosZ(4, 112).TopPosZ(76, 19))
-	ITEM(Switch, runmode, SetLabel(t_("&Standalone\n&Console\n&File")).HSizePosZ(120, 116).TopPosZ(76, 19))
+	ITEM(Switch, runmode, SetLabel(t_("&Standalone\n&Console\n&File")).HSizePosZ(120, 104).TopPosZ(76, 19))
 	ITEM(Option, external, SetLabel(t_("&External application")).HSizePosZ(120, 168).TopPosZ(96, 15))
 	ITEM(Switch, consolemode, SetLabel(t_("Auto\nAlways\nNever")).HSizePosZ(120, 4).TopPosZ(116, 20))
 	ITEM(Button, ok, SetLabel(t_("OK")).RightPosZ(72, 64).BottomPosZ(8, 24))
 	ITEM(Button, cancel, SetLabel(t_("Cancel")).RightPosZ(4, 64).BottomPosZ(8, 24))
 	ITEM(Label, console_lable, SetLabel(t_("Open console:")).LeftPosZ(4, 112).TopPosZ(116, 20))
-	ITEM(Option, utf8, SetLabel(t_("Output is UTF-8")).LeftPosZ(312, 104).TopPosZ(76, 20))
+	ITEM(Option, utf8, SetLabel(t_("Output is UTF-8")).LeftPosZ(316, 104).TopPosZ(76, 20))
 END_LAYOUT
 
 LAYOUT(FindInFilesLayout, 492, 152)