I'm wondering, when I try to receive sms text message from a SIM using AT+CMGL, can a message contain OK<CR><LF>? if so how should I know where is the end of the message?
Thanks
This is a good question, and as you have identified if the information text contains a final result code you loose, because there is no way to know.
This is partially covered in V.250 which forbids the modem to introduce false final result codes if it breaks up lines:
Note that the DCE may insert intermediate characters in very long
information text responses, in order to avoid overrunning DTE receive
buffers. If intermediate characters are included, the DCE shall
not include the character sequences "0 " (3/0, 0/13) or "OK"
(4/15, 4/11, 0/13), so that DTE can avoid false detection of the end
of these information text responses.
And also several command (+GMI, +GMM, +GMR, +GSN, +GOI and +GCAP) are explicitly forbidden to produce text that embed the OK final result code (but it does not mention anything about ERROR...).
Similarly for 27.007 it forbids some commands (+CGMI, +CGMM, +CGMR, +CGSN, +CEER and +CLAC) from containing OK (and again no mention of ERROR...).
27.005 does not specify anything regarding embedded final result codes, so to avoid the issue of embedded final result codes for AT+CMGL you need to read the message in PDU mode, there you have a guarantee that the information text will not contain OK, ERROR, etc.
Related
I'm using AWS Textract to pull information from PDF documents. After the scanned text is returned from AWS and persisted to a var, I'm doing this:
phone_number = '(555) 123-4567'
scanned_pdf_text.should have_text phone_number
But this fails about 20% of the time because of the non-deterministic way that AWS is returning the scanned PDF text. On occasion, the phone numbers can appear either of these two ways:
(555)123-4567 or (555) 123-4567
Some of this scanned text is very large, and I'd prefer not to go through the exercise of sanitizing the text coming back if I can avoid it (I'm also not good at regex usage). I also think using or logic to handle both cases seems to be a little heavy handed just to check text that is so similar (and clearly near-identical to the human eye).
Is there an rspec matcher that'll allow me to check on this text? I'm also using Capybara.default_normalize_ws = true but that doesn't seem to help in this case.
Assuming scanned_pdf_text is a string and the only differences you're seeing is in spaces then you can just get rid of the spaces and compare
scanned_pdf_text.gsub(/\s+/, '').should eq('(555)123-4567') # exact
scanned_pdf_text.gsub(/\s+/, '').should match('(555)123-4567') # partial
scanned_pdf_text.gsub(/\s+/, '').should have_text('(555)123-4567') # partial
I'm building a Slack App which is only interested in actual user input in message, regardless if it's bold, italic, or a web link.
What would be the best way to remove all the formatting characters, such as _, *, etc, and leave actual text only?
The best solution is actually to ignore the text param entirely, as it is inherently lossy, and to instead parse what you want from the blocks param, which gives an exact representation of what the user saw in their slack client message field when they posted their message.
To demonstrate this, here's a simple example
what you type
WYS
text
blocks[0]["elements"]["elements"]
parsing text from blocks
[a][space][*][b][*]
a b
a *b*
[{"type":"text","text":"a "},{"type":"text","text":"b","style":{"bold":true}}]
a b
[a][*][b][*][←][←][←][space]
a *b*
a *b*
[{"type":"text","text":"a *b*"}]
a *b*
Unfortunately for now, the Slack API does not give you the blocks param in command events, only message events. Hopefully they will fix this, but until then you may wish to use regular messages instead of slash commands.
If you are using node.js there is a module for this:
https://openbase.io/js/remove-markdown/documentation
Note that this is for markdown and not Slack's variant mrkdwn so it might not work.
Managed to get the unformatted message in python by looping through the array.
def semakitutu(message, say):
user = message['user']
# print(message)
hasira = message['blocks']
hasira2 = hasira[0]['elements'][0]['elements']
urefu = len(hasira2)
swali = ''
for x in range(urefu):
swali=swali+hasira2[x]['text']
print(swali)
say(f"Hello <#{user}>! I am running your request \n {swali}")```
I've recently encountered all sorts of wrappers in Google's protobuf package. I'm struggling to imagine the use case. Can anyone shed the light: what problem were these intended to solve?
Here's one of the documentation links: https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/string-value (it says nothing about what can this be used for).
One thing that will be different in behavior between this, and simple string type is that this field will be written less efficiently (a couple extra bytes, plus a redundant memory allocation). For other wrappers, the story is even worse, since the repeated variants of those fields will be written inefficiently (official Google's Protobuf serializer doesn't support packed encoding for non-numeric types).
Neither seems to be desirable. So, what's this all about?
There's a few reasons, mostly to do with where these are used - see struct.proto.
StringValue can be null, string often can't be in a language interfacing with protobufs. e.g. in Go strings are always set; the "zero value" for a string is "", the empty string, so it's impossible to distinguish between "this value is intentionally set to empty string" and "there was no value present". StringValue can be null and so solves this problem. It's especially important when they're used in a StructValue, which may represent arbitrary JSON: to do so it needs to distinguish between a JSON key which was set to empty string (StringValue with an empty string) or a JSON key which wasn't set at all (null StringValue).
Also if you look at struct.proto, you'll see that these aren't fully fledged message types in the proto - they're all generated from message Value, which has a oneof kind { number_value, string_value, bool_value... etc. By using a oneof struct.proto can represent a variety of different values in one field. Again this makes sense considering what struct.proto is designed to handle - arbitrary JSON - you don't know what type of value a given JSON key has ahead of time.
In addition to George's answer, you can't use a Protobuf primitive as the parameter or return value of a gRPC procedure.
I intent to use gsdll32 to display postscript in a Win32 window (not ghostview).
I need help with the parameters needed by gsdll_init_with_args.
The function immediately returns error -0x12 or -0x100.
I tried several parameter combinations in various sequences:
-sDisplayFormat=16#030804
-dDisplayHandle="1234"
-dDisplayResolution=96
-sDEVICE=display
postscriptfile.ps
As a second question:
What should the parameters be if I want to pipe in the postscript data programmatically ?
Examples would be nice.
Seppe
The supplied source code for Windows uses gs_dll_init_with_args(). If you look in /ghostpdl/psi/dwmain.c, function new_main(int argc, char *argv) then at about line 328 you can see the call happening.
You can follow this through in a debugger to see what the arguments look like (they get sanitised before arriving here). Get it to work the way you want on the command line, then break here with those arguments and you can see what your own code should be providing.
To send the data buffer-by-buffer, we don't have an example. However, you start by calling gsapi_run_string_begin(), then repeatedly calling gsapi_run_string_continue() until you exhaust the data, then call gsapi_run_string_end(). Obviously you will have to check the return code to see if an error occurred.
Finally; please check the AGPL to be sure you can conform to the license restrictions.
Can I determine if the user entered a phone number that can be safely formatted into E164?
For Germany, this requires that the user started his entry with a local area code. For example, 123456 may be a subscriber number in his city, but it cannot be formatted into E164, because we don't know his local area code. Then I would like to keep the entry as it is. In contrast, the input 089123456 is independent of the area code and could be formatted into E164, because we know he's from Germany and we could convert this into +4989123456.
You can simply convert your number into E164 using libphonenumber
and after conversion checks if both the strings are same or not. If they're same means a number can not be formatted, otherwise the number you'll get from library will be formatted in E164.
Here's how you can convert
PhoneNumberUtil phoneUtil = PhoneNumberUtil.getInstance();
String formattedNumber = phoneUtil.format(inputNumber, PhoneNumberFormat.E164);
Finally compare formattedNumber with inputNumber
It looks as though you'll need to play with isValidNumber and isPossibleNumber for your case. format is certainly not guaranteed to give you something actually dialable, see the javadocs. This is suggested by the demo as well, where formatting is not displayed when isValidNumber is false.
I also am dealing with this FWIW. In the context of US numbers: The issue is I'd like to parse using isPossibleNumber in order to be as lenient as possible, and store the number in E164. However then we accept, e.g. +15551212. This string itself even passes isPossibleNumber despite clearly (I think) not being dialable anywhere.