search for: formatv

* UDL Syntax is removed in the latest version of the patch <https://reviews.llvm.org/D25587>. * Name changed to `formatv` since `format_string` is too much to type. * Added conversion operators for `std::string` and `llvm::SmallString`. I had some feedback offline (not on this thread, unfortunately) that it might be worth using a printf style syntax instead of this Python-esque syntax. FTR, I actually somewhat obje...

...lue xmlv) } value -v2v_xml_copy_doc (value docv, value recursivev) +mllib_xml_copy_doc (value docv, value recursivev) { CAMLparam2 (docv, recursivev); CAMLlocal1 (copyv); @@ -147,7 +148,7 @@ v2v_xml_copy_doc (value docv, value recursivev) } value -v2v_xml_to_string (value docv, value formatv) +mllib_xml_to_string (value docv, value formatv) { CAMLparam2 (docv, formatv); CAMLlocal1 (strv); @@ -166,7 +167,7 @@ v2v_xml_to_string (value docv, value formatv) } value -v2v_xml_xpath_new_context (value docv) +mllib_xml_xpath_new_context (value docv) { CAMLparam1 (docv); CAMLl...

...ferent separator, or control the formatting of the underlying type. >> (e.g. it's not clear how you would elegantly format a range of integers in >> hex using this style of approach). >> > > It is entirely unclear to me that putting everything in a format string: > formatv("Here's a range: {0:$[ + ]@[x]}", range); > is better than composing functions with usual function-call syntax, e.g. > something like this: > format("Here's a range: %s", Join(range, " + ", Formatter("%x"))); > > I think that's th...

...he formatting of the underlying type. > >> (e.g. it's not clear how you would elegantly format a range of integers in > >> hex using this style of approach). > >> > > > > It is entirely unclear to me that putting everything in a format string: > > formatv("Here's a range: {0:$[ + ]@[x]}", range); > > is better than composing functions with usual function-call syntax, e.g. > > something like this: > > format("Here's a range: %s", Join(range, " + ", Formatter("%x"))); > > > &...

...gt;> >> It has a verbal LGTM, but I plan to wait a bit longer just in case anyone >> has some additional thoughts. It's a large patch, but if you're >> interested, one way you can help without doing a full-blown review is to >> look at the large comment blocks in FormatVariadic.h and >> FormatProviders.h. Here I provide a formal description of the grammar of >> the replacement sequences and format syntax. So you can look at this >> without looking at the code behind it and see if you have comments just on >> the format language. >> &...

...iews.llvm.org/rL289668). * Clang gained a testbed and skeleton of a new expression parser. [r290004](http://reviews.llvm.org/rL290004). ## Other project commits * It is now possible to build lld standalone, i.e. with an existing LLVM installation. [r289421](http://reviews.llvm.org/rL289421). * formatv support has been sprinkled throughout LLDB. [r289922](http://reviews.llvm.org/rL289922).

...ws.llvm.org/D25587 > > It has a verbal LGTM, but I plan to wait a bit longer just in case anyone > has some additional thoughts. It's a large patch, but if you're > interested, one way you can help without doing a full-blown review is to > look at the large comment blocks in FormatVariadic.h and > FormatProviders.h. Here I provide a formal description of the grammar of > the replacement sequences and format syntax. So you can look at this > without looking at the code behind it and see if you have comments just on > the format language. > > Here's a sum...

...value xpathobjv) +{ + CAMLparam1 (xpathobjv); + xmlXPathObjectPtr xpathobj = Xpathobj_ptr_val (xpathobjv); + + xmlXPathFreeObject (xpathobj); + CAMLreturn (Val_unit); +} + +value v2v_xml_parse_memory (value xmlv) { CAMLparam1 (xmlv); @@ -159,7 +162,7 @@ v2v_xml_to_string (value docv, value formatv) } value -v2v_xml_xpath_new_context (value docv) +v2v_xml_xpath_new_context_ptr (value docv) { CAMLparam1 (docv); CAMLlocal1 (xpathctxv); @@ -171,21 +174,21 @@ v2v_xml_xpath_new_context (value docv) if (xpathctx == NULL) caml_invalid_argument ("xpath_new_context: unable to c...

...value xpathobjv) +{ + CAMLparam1 (xpathobjv); + xmlXPathObjectPtr xpathobj = Xpathobj_ptr_val (xpathobjv); + + xmlXPathFreeObject (xpathobj); + CAMLreturn (Val_unit); +} + +value v2v_xml_parse_memory (value xmlv) { CAMLparam1 (xmlv); @@ -159,7 +162,7 @@ v2v_xml_to_string (value docv, value formatv) } value -v2v_xml_xpath_new_context (value docv) +v2v_xml_xpath_new_context_ptr (value docv) { CAMLparam1 (docv); CAMLlocal1 (xpathctxv); @@ -171,21 +174,21 @@ v2v_xml_xpath_new_context (value docv) if (xpathctx == NULL) caml_invalid_argument ("xpath_new_context: unable to c...

...g many EXPECT statements to test a single logical condition. When you want to do this for many different inputs / outputs of an API it turns into a long list of expect statements that the person reading the test can't easily grok and see how they're related. Here's an example from the formatv tests that I wrote: > > Replacements = formatv_object_base::parseFormatString("{0,-3}"); > ASSERT_EQ(1u, Replacements.size()); > EXPECT_EQ(ReplacementType::Format, Replacements[0].Type); > EXPECT_EQ(0u, Replacements[0].Index); > EXPECT_EQ(3u, Replacements[0].A...

Hi all, Here is a new version of the virt-builder-repository series taking care of Pino's comments. It has also been rebased on recent master. Cédric Bosdonnat (7): mllib: factorize code to add Checksum.get_checksum function Move xml and xpath_helpers OCAML code to mllib mllib: expose libosinfo DB reading functions in mllib builder: rename docs test script builder: add

In version 2: - No substantial change, I just tidied up the code a bit. - Removed one case where whitespace changes had crept in. Rich.

Hi guys, Here is a v3 of the series, including changes to answer Richard's comments. Cédric Bosdonnat (10): mllib: factorize code to add Checksum.get_checksum function Move xml and xpath_helpers OCAML code to mllib mllib: add Xml.parse_file helper lib/osinfo.c: Extract xml processing into a callback lib: extract osinfo DB traversing API mllib: ocaml wrapper for lib/osinfo

A long time ago I suggested that we might want to add gmock to compliment the facilities provided by gtest in LLVM's unittests. It didn't go over well: 1) There was concern over the benefit vs. the cost 2) Also concern about what the facilities would look like in practice and whether they would actually help 3) At the time, I didn't have good, large examples of what these things might