When swapExactTokensForETHSupportingFeeOnTransferTokens is implemented, does the Uniswap UI show how much fees are sent?
The UI has no way of knowing the fee of a token. The one you see on the main interface is an expected output using standard erc20 code. Slippage is needed to cover this change for Fee-On-Transfer tokens. For everything, it's best to check the minimum out.
Related
I sent my token to dead address(0x000000000000000000000000000000000000dead)
At first I was trying to burn all my token so I sent the token to the dead address using meta mask.
Now I can see the my token(https://bscscan.com/address/0x0083a5a7e25e0Ee5b94685091eb8d0A32DfF11D4)'s total supply isn't reduced. And the dead address is the holder of the token. How can I fix this out?
Actually I want to remove all tokens minted from my tokne.
I'm afraid you have misunderstood the concept of burning coins. Burning does not destroy coins. It sends them to an address/wallet/account that can only receive but cannot send (or spend) them, making them effectively lost forever as this is recorded in the immutable ledger.
This means that the supply of tokens in circulation (those tokens that can still be used to make transactions) is reduced, but not the total supply. So actually, everything that happened in your case is completely expected.
Here is one among many internet resources that explains the concept of burning coins:
https://www.investopedia.com/tech/cryptocurrency-burning-can-it-manage-inflation/
I see that you used the regular transfer() method to send your tokens to the zero address (link).
Your contract implements the burn() function that effectively reduces the total supply as well.
Expanding on Marko's answer: In this particular case, you should use the burn() function instead of just regular transfer. However, different token contracts might use different function names or not implement a burn mechanism at all - it all depends on the token contract implementation.
I have a contact flow that is using a pre-recorded voice prompt with a lex bot for voice rec. This is the main menu verbiage:
“Thank you for calling. If you would like to use your keypad to select the menu options, say “keypad”, otherwise please listen to the following menu options. For billing questions, say “billing”. To report a missed pickup, say “missed pickup”. If you are a current customer with recycling or other account questions, say “other”. If you are not a current customer, and have questions, say “sales”. To hear the menu again, say “repeat menu”. For all other questions, please remain on the line.”
I have set the error handling in the Lex bot to speak "Sorry, I'm having a hard time understanding you. Let's try using the keypad instead to make sure we route your call properly."
This is working when an utterance is not matched or an invalid option is spoken or pressed. However, I cannot figure out if it's possible to allow the lex bot to timeout like in a normal DTMF contact flow and send the caller to the next step in the menu without playing the error handling in from the Lex bot.
Is this possible?
That's the thing, Lex is not meant to be used this way. It MUST have an input to process, and if it reaches Lex's timeout, then it will always return an error and deliver the error handling response.
So you will have to get fancy in the Connect Flow to catch the Lex error message, and turn it into your own handling of it. But it will be hard to know whether Lex is erroring because it didn't understand, or because the user chose not to respond.
Therefore, I would personally avoid building the bot in a way that allows the user to remain silent. The user must direct Lex every step of the way and have easy ways of backing out of an unwanted action.
Remember that Lex is much more powerful than the old automatic call systems, so trying to force Lex into that old system won't work well. Depending on how you design your bot, you can make the conversation much much more natural, accepting a very wide range of responses and directing those into proper actions.
Tips:
Things may have changed more recently, but when I was building Lex/Connect, it was not possible for the user to interrupt a playback message. So I had to also avoid what you are trying to do in the welcome message:
If you would like to use your keypad to select the menu options, say “keypad”, otherwise please listen...
Naturally, a user who does want to use the keypad will try to immediately say "keypad" and probably get frustrated by having to listen to the rest of the playback message. So I design every playback message to be short, deliver information first, and always end on the question. Often breaking the conversation up into more branching points to make the questions as specific as possible.
Don't worry about going back and forth with the user too many times. It gives the user comfort knowing they are on the right path to what they want and are able to control the conversation in smaller steps. They will get stressed, having to listen to long list of options and remembering what they are while figuring out which one best applies to them.
So make each question as clear as possible and avoid spoonfeeding options. It feels less natural to explicitly state to the user what they should say:
To report a missed pickup, say “missed pickup”.
That is unnatural.
A good middle ground would be asking one question with a list of options and pausing between each option. The user will understand that these are responses they should make, but won't feel unnaturally pressured into exact phrases. For example:
Would you like to, check your billing, report a missed pickup, ask about sales, or something else?
That is natural.
We are comfortable handling those types of questions because we often do that when speaking with humans. You may even want to use a question mark instead of commas so that the playback voice uses a questioning intonation with each option. It looks less natural in written form, but would probably sound more natural.
Last tip: Don't design your bot based on your experience talking with bots. Design your bot based on your experience talking with humans.
I am trying to simulate a buy side client who could send order to an exchange, receive execution reports and further cancel / replace orders. QuickfixJ Banzai swing based UI seems like an ok fit given it’s free and our startup doesn’t want to spend a lot of money for this.
Currently the Benzai UI only has specific text boxes to send orders with fields for symbol, qty etc. I was wondering if someone has come across an extension to this swing UI example which takes messages in a freeform text area so that we are not limited by the number of economic fields exposed in the UI and could send any other fix messages in the text area.
Another tool that comes to my mind is http://fixpusher.sourceforge.net/
AFAICT it is not maintained anymore and probably is capable of more than what you want.
But if you have a little of Java coding experience, how hard can it be to add a text box to Banzai and call MessageUtils.parse() on its contents?
Would like to maintain a local record of the price of all the phone calls that my application makes.
Am not sure what a good pattern for this would be. It looks like the price is not available in the arguments provided during the status call back when the call is closed. I assume this means I'll need to query Twilio's servers to find the price of the call. Can I do this immediately or do I need to wait a certain amount of time for the price to populate?
Is there another pattern that would be simpler, require fewer steps, or be less error prone that I am not seeing here?
Thanks!
Twilio evangelist here.
I'd recommend checking out the Usage Records API. These handy API's give you an easy way to get rollup data for your account, like how much your account spent yesterday, or how many outbound calls it made.
You can also set up Usage Triggers to proactively notify you when threshholds are met.
Hope that helps.
My team communicates a lot with IM. We'll sometimes use IM to ask a question even to someone who's in the next cube over. The reason for this is that we all find that answering an IM is much less disrupting than talking.
Still, I find that the blinking message window can be disrupting when I'm heads down coding. I can't help but look at what people have written and it often keeps me from finishing my thought. This type of multitasking is a productivity killer. I've therefore turned off the alert feature (I'm using Pidgin). My Windows task bar is hidden so I need to drag my cursor to the bottom of the screen, let the task bar pop up, and look if the pidgin tray icon is flashing orange to find out about new messages.
This works well except that sometimes people have a quick question to ask for which they need a quick answer.
It would be great to have the ability to send priorities on messages:
Priority 3: Check this out when you can
Priority 2: Normal chat
Priority 1: Please reply quickly
The priority level would then be used to determine the alert method. E.g. (1)Give focus to window, (2)blink in task bar, (3)blink in tray.
Any ideas on an easy way of accomplishing this?
Thanks
We use e-mail or internal twitter for your Priority 3.
We use IM for Priority 2.
We use walking over to someone's desk for Priority 1.
Edit: I'm sorry I didn't realize you were asking an implementation question. If you didn't want to institute new policies/standards for methods of contact (ala introducing an internal twitter or the like), you would need to standardize everyone in the office on the same IM application/protocol. And then you'd need to modify one. Trying to add something into the jabber spec (if it doesn't have it, I don't know) would be tedious and not worth the effort.
If you really wanted to pursue that route, you would probably be better off moving to IRC and using scripts to alert you if people talk to you while preceding their message with a pound! or something similar.
I think that as soon as you introduce a "priority message" function, all messages will start to be high priority. Human nature. I just set my status to "busy" and don't reply to messages that come in when i'm "busy" unless it is important. People get the point quickly.
While I agree with the statement that being able to make certain messages a higher priority will result in ALL messages being high-priority, you can always just shut off the IM, and then people will have to actually talk to you. If they are on your team, they should know when you are heads-down, and take some personal responsibility in making the decision to disrupt you.
I do roughly the same thing that Codingscape does - I set my status to Away. Many clients will display an 'away text' message when your status changes, so I just use "I'm very busy" or a similar message.