For example;
results.Errors.Count.Should().Be(0, $"because {results.Errors[0]}");
produces the Result Message:
Expected value to be 0 because 'Name' should not be empty., but found 2.
But what I really want, in this particular instance (invocation of the assertion) is just the value of results.Errors[0], that is I would like the message to be just: 'Name' should not be empty.
(As an aside what I really want is to pass a concatenated string representation of the entire results.Errors array, but my linq/lambda skills aren't there yet)!
So how can I get FA to just use what I supply as the message string?
You can't do that. The because part is baked into the language to promote failure messages that are as natural as possible.
Related
The docs say that fmt
Returns a string where each element in the list has been formatted according to $format [the first argument] and where each element is separated by $separator [the second argument].
Based on that description, I expected to be able to call .fmt on a List of Lists, and then pass a printf-style format string containing a % directive for each element in the inner list. But that doesn't work.
If you'd told me that I was wrong about ^^^^, I'd have expected that .fmt was auto-flattening its arguments and thus that each argument would be formatted and separated by the $separator. But that's also not what happens.
Instead, running this code
say (<a b c>, <1 2 3>, <X Y Z>).fmt('→%03s|', "\n=================\n");
produces this output:
→00a| →00b| →00c|
=================
→001| →002| →003|
=================
→00X| →00Y| →00Z|
That is, the format string is applied to each element in the inner lists, those lists are then stringified (without using the format string; note the between each | and → character), and then the separator is inserted between each outer list.
That leaves me with three questions:
Have I correctly described/understood the current behavior? [edit: nope. See below]
Is this behavior intentional or an odd bug? (I checked Roast, but didn't see anything either way)
Assuming this is intentional, why? Is there some way that this is consistent with Raku's general approach to handling lists that I'm missing? Or some other reason for this (imo) surprising behavior?
Edit:
After further investigation, I've realized that the behavior I observed above only occurs if the format string contains a width directive. Changing the →%03s| format string from above to →%s| produces the following output:
→a b c|
=================
→1 2 3|
=================
→X Y Z|
That is, without a width, the format string is applied after the list is stringified rather than before.
So I'm back to being confused/thinking at least some of this behavior must be buggy.
Ok, it looks like there were at least two bugs here. This should be fixed with https://github.com/rakudo/rakudo/commit/a86ec91e36 . Writing spectests for these situations, would be appreciated :-)
Basically looking for opposite of spacy.strings.get_string_id() which does not need to load the language model to get the vocabulary. I tried StringStore methods, but you need to add the string first or else you get a "Can't retrieve string for hash 'xxx'" error.
Use case is the hash is serialized then it is unserialized somewhere else.
No, you will need to keep a copy of the StringStore from the pipeline you used to process your documents in order to look up strings for hashes in the future.
In the end, it's nothing more than a list of strings that have been seen before, either as tokens or annotations, which you can simply re-add to a new StringStore.
I have 3 separate APIs, A, B, and C. A and B are completely independent, whereas C queries A and B to compile data together. Each API is in its own project and running on its own port (8081, 8082, and 8083, respectively).
I am able to successfully hit A and B individually AND through C...sort of. When C hits one of these endpoints, the result comes back as a glassfish.grizzlly.utils.BufferInputStream.
I've dealt with this BufferInputStream type before by using a Transform Message Component. However, doing so here simply produces an error, saying that payload.id is of the wrong type (it should be an integer). When running this in debug mode, I can see that A has an Output Payload with id: Integer (it is of a custom type). However, upon moving back into C's flow, the payload is now the aforementioned BufferInputStream type, and I'm unable to directly access payload.id.
In short: How do I retrieve data in one project from another project?
Thanks in advance!
Update:
I used an Object to String transformer on the BufferInputStream to get a better look at the value. It appears to be in the format of a URL:
id=12345&name=nameValue&otherVal=%5B8499%5D...
I can #[payload.split('&')] at this point and get most of what I need, but then there's still the issue of things like the following:
summary=Words+with+plus+signs+in+the+middle
Again, I can work around this with things like split, but surely this is not what is intended.
Update 2:
I discovered the following warning:
[[test].api-httpListenerConfig.worker.01]
org.mule.module.http.internal.listener.HttpResponseBuilder:
Payload is a Map which will be used to generate an url encoded http body but
Contenty-Type specified is application/java; charset=windows-1252 and not
application/x-www-form-urlencoded
I'm not entirely sure what to do with that info, though the Contenty-Type typo is interesting ^^
Solved! In A and B, I needed to use an Object to Byte Array transformer before returning the value. This allows me to use a Byte Array to Object transformer in C and get the original value back.
Is there any way of programmatically getting the value of a Text Symbol at runtime?
The scenario is that I have a simple report that calls a function module. I receive an exported parameter in variable LV_MSG of type CHAR1. This indicates a certain status message created in the program, for instance F (Fail), X (Match) or E (Error). I currently use a CASE statement to switch on LV_MSG and fill another variable with a short description of the message. These descriptions are maintained as text symbols that I retrieve at compile time with text-MS# where # is the same as the possible returns of LV_MSG, for instance text-MSX has the value "Exact Match Found".
Now it seems to me that the entire CASE statement is unnecessary as I could just assign to my description variable the value of the text symbol with ID 'MS' + LV_MSG (pseudocode, would use CONCATENATE). Now my issue is how I can find a text symbol based on the String representation of its ID at runtime. Is this even possible?
If it is, my code would look cleaner and I wouldn't have to update my actual code when new messages are added in the function module, as I would simply have to add a new text symbol. But would this approach be any faster or would it in fact degrade the report's performance?
Personally, I would probably define a domain and use the fixed values of the domain to represent the values. This way, you would even get around the string concatenation. You can use the function module DD_DOMVALUE_TEXT_GET to easily access the language-dependent text of a domain value.
To access the text elements of a program, use a function module like READ_TEXT_ELEMENTS.
Be aware that generic programming like this will definitely slow down your program. Whether it would make your code look cleaner is in the eye of the beholder - if the values change rarely, I don't see why a simple CASE statement should be inferior to some generic text access.
Hope I understand you correctly but here goes. This is possible with a little trickery, all the text symbols in a report are defined as variables in the program (with the name text-abc where abc is the text ID). So you can use the following:
data: lt_all_text type standard table of textpool with default key,
lsr_text type ref to textpool.
"Load texts - you will only want to do this once
read textpool sy-repid into lt_all_text language sy-langu.
sort lt_all_Text by entry.
"Find a text, the field KEY is the text ID without TEXT-
read table lt_all_text with key entry = i_wanted_text
reference into lsr_text binary search.
If you want the address you can add:
field-symbols: <l_text> type any.
data l_name type string.
data lr_address type ref to data.
concatenate 'TEXT-' lsr_text->key into l_name.
assign (l_name) to <l_text>.
if sy-subrc = 0.
get reference of <l_text> into lr_address.
endif.
As vwegert pointed out this is probably not the best solution, for error handling rather use message classes or exception objects. This is useful in other cases though so now you know how.
I have a simple grammar that works for the most part, but at one place it reports error and I think it shouldn't, because it can be resolved using backtracking.
Here is the portion that is problematic.
command: object message_chain;
object: ID;
message_chain: unary_message_chain keyword_message?
| binary_message_chain keyword_message?
| keyword_message;
unary_message_chain: unary_message+;
binary_message_chain: binary_message+;
unary_message: ID;
binary_message: BINARY_OPERATOR object;
keyword_message: (ID ':' object)+;
This is simplified version, object is more complex (it can be result of other command, raw value and so on, but that part works fine). Problem is in message_chain, in first alternative. For input like obj unary1 unary2 it works fine, but for intput like obj unary1 unary2 keyword1:obj2 is trys to match keyword1 as unary message and fails when it reaches :. I would think that it this situation parser would backtrack and figure that there is : and recognize that that is keyword message.
If I make keyword message non-optional it works fine, but I need keyword message to be optional.
Parser finds keyword message if it is in second alternative (binary_message) and third alternative (just keyword_message). So something like this gives good results: 1 + 2 + 3 Keyword1:Value
What am I missing? Backtracking is set to true in options and it works fine in other cases in the same grammar.
Thanks.
This is not really a case for PEG-style backtracking, because upon failure that returns to decision points in uncompleted derivations only. For input obj unary1 unary2 keyword1:obj2, with a single token lookahead, keyword1 could be consumed by unary_message_chain. The failure may not occur before keyword_message, and next to be tried would be the second alternative of message_chain, i.e. binary_message_chain, thus missing the correct parse.
However as this grammar is LL(2), it should be possible to extend lookahead to avoid consuming keyword1 from within unary_message_chain. Have you tried explicitly setting k=2, without backtracking?