Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
[doc] Under the hood
[simgrid.git] / doc / doxygen / FAQ.doc
index c7d6600..2a8a74d 100644 (file)
@@ -477,7 +477,7 @@ do so.
 
 \subsubsection faq_trouble_err_logcat "gcc: _simgrid_this_log_category_does_not_exist__??? undeclared (first use in this function)"
 
-This is because you are using the log mecanism, but you didn't created
+This is because you are using the log mechanism, but you didn't created
 any default category in this file. You should refer to \ref XBT_log
 for all the details, but you simply forgot to call one of
 XBT_LOG_NEW_DEFAULT_CATEGORY() or XBT_LOG_NEW_DEFAULT_SUBCATEGORY().
@@ -496,53 +496,6 @@ come after <tt>-lsimgrid</tt> on this command line.
 
 \subsection faq_trouble_errors Runtime error messages
 
-\subsubsection faq_flexml_limit "surf_parse_lex: Assertion `next limit' failed."
-
-This is because your platform file is too big for the parser.
-
-Actually, the message comes directly from FleXML, the technology on top of
-which the parser is built. FleXML has the bad idea of fetching the whole
-document in memory before parsing it. And moreover, the memory buffer size
-must be determined at compilation time.
-
-We use a value which seems big enough for our need without bloating the
-simulators footprints. But of course your mileage may vary. In this case,
-just edit src/surf/surfxml.l modify the definition of
-FLEXML_BUFFERSTACKSIZE. E.g.
-
-\verbatim
-#define FLEXML_BUFFERSTACKSIZE 1000000000
-\endverbatim
-
-Then recompile and everything should be fine, provided that your version of
-Flex is recent enough (>= 2.5.31). If not the compilation process should
-warn you.
-
-A while ago, we worked on FleXML to reduce a bit its memory consumption, but
-these issues remain. There is two things we should do:
-
-  - use a dynamic buffer instead of a static one so that the only limit
-    becomes your memory, not a stupid constant fixed at compilation time
-    (maybe not so difficult).
-  - change the parser so that it does not need to get the whole file in
-    memory before parsing
-    (seems quite difficult, but I'm a complete newbe wrt flex stuff).
-
-These are changes to FleXML itself, not SimGrid. But since we kinda hijacked
-the development of FleXML, I can grant you that any patches would be really
-welcome and quickly integrated.
-
-<b>Update:</b> A new version of FleXML (1.7) was released. Most of the work
-was done by William Dowling, who use it in his own work. The good point is
-that it now use a dynamic buffer, and that the memory usage was greatly
-improved. The downside is that William also changed some things internally,
-and it breaks the hack we devised to bypass the parser, as explained in
-\ref pf_flexml_bypassing. Indeed, this is not a classical usage of the
-parser, and Will didn't imagine that we may have used (and even documented)
-such a crude usage of FleXML. So, we now have to repair the bypassing
-functionality to use the latest FleXML version and fix the memory usage in
-SimGrid.
-
 \subsubsection faq_trouble_errors_big_fat_warning I'm told that my XML files are too old.
 
 The format of the XML platform description files is sometimes
@@ -553,9 +506,9 @@ descriptions to allow more compact descriptions.
 
 That is why the XML files are versionned using the 'version' attribute
 of the root tag. Currently, it should read:
-\verbatim
-  <platform version="2">
-\endverbatim
+@verbatim
+  <platform version="4">
+@endverbatim
 
 If your files are too old, you can use the simgrid_update_xml.pl
 script which can be found in the tools directory of the archive.
@@ -589,7 +542,7 @@ This is when valgrind starts complaining about longjmp things, just like:
 ==21434==    at 0x420DC3A: __longjmp (__longjmp.S:48)
 \endverbatim
 
-This is the sign that you didn't used the exception mecanism well. Most
+This is the sign that you didn't used the exception mechanism well. Most
 probably, you have a <tt>return;</tt> somewhere within a <tt>TRY{}</tt>
 block. This is <b>evil</b>, and you must not do this. Did you read the section
 about \ref XBT_ex??
@@ -653,7 +606,7 @@ will run only one half of the true SimGrid potential.
 
 Unfortunately, we cannot debug every code written in SimGrid.  We
 furthermore believe that the framework provides ways enough
-information to debug such informations yourself. If the textual output
+information to debug such information yourself. If the textual output
 is not enough, Make sure to check the \ref faq_visualization FAQ entry to see
 how to get a graphical one.