The Uniswap router contract has a few methods ending in *SupportingFeeOnTransferTokens, e.g. swapExactTokensForETHSupportingFeeOnTransferTokens.
https://github.com/Uniswap/uniswap-v2-periphery/blob/master/contracts/UniswapV2Router02.sol
I vaguely (think I) understand that these methods are supposed to be called for swapping tokens that somehow take a tax/rake during transfers.
I have a few questions regarding these:
In a nutshell, what is the difference in behavior for these functions different from the regular swap functions? Do they somehow interact with the minOut parameters?
How does the Dex UI know which method to call? How does it know the SupportingFee version needs to be called instead of the standard swap?
What happens if my web3 script calls the wrong version of the method? Failures? Wrong amounts out?
Related
There is an answered question which will help you understand what exactly I want to say.
How does the function passed to http.HandleFunc get access to http.ResponseWriter and http.Request?
There are many built-in Go functions where the function parameters get assigned this way. I want to use that coding style in my daily coding life.
I want to write a similar function/method which will get its parameter values from somewhere just like http.Handlefunc's w and r.
func (s SchoolStruct) GetSchoolDetails(name string){
// here the parameter "name" should get assigned exactly like http.HandleFunc()'s "w" and "r".
}
What http does is that it registers a callback and uses it when the time comes. You don't have to pass the arguments it takes, as servers implementation provides these arguments with correct state. If you want to copy this approach, first you have to ask:
Is there some kind of generic abstraction that computes these parameters? Is the function I write just reacting to something? Does this function have any side effects? Does it return value back to the system?
This approach is very good when you are modifying existing system, extending its behavior with independent units. So to speak, integrating into robust API.
You may be correct that this is a style of doing things, but you cannot use this style on everything. Its just too specific and good at certain group of tasks.
As #mkopriva pointed out, declaring rules and requirements, your logic should satisfy, is known way to execute this style in Go. You have to realize that your logic, encapsulated behind function pointer or interface, has to be passed and controlled by some other code you call indirectly.
I cannot possibly imagine going to such lengths when all components of the system are under your control and system has only one logic to run.
I am taking a udemy course and I encounter a code like this
https://github.com/acloudfan/Blockchain-Course-Basic-Solidity/blob/93ca256bcf8c436c144425291257dcff5c3b269f/test/constants_payable.js#L45
I am confuse why the call to a method is called directly instead of using .call or something, wherein if I do google, the way to call a method of a contract is either using .call or .send but at this point the author just calls it directly, is this allowed, why?
here is the contract code
https://github.com/acloudfan/Blockchain-Course-Basic-Solidity/blob/master/contracts/ConstantsPayable.sol
More or less, what is the context of calling smart contract method from a truffle test here? is it like the real environment where it waits for the transaction to be mined before returning or do tests just directly calls it like an ordinary function?
I am posting it here since the author of the udemy course is non responsive and its almost a week and more than a dozen Q&A question are not answered, so the author probably is busy or forgets about the course already (as it is kinda old course but reviewed well).
Before Truffle returns the contract instance (line 41), it uses the ABI interface (provided by the Solidity compiler) to build a map of JS functions for interacting with the contract, including receiveEthers().
what is the context of calling smart contract method from a truffle test here
Even though Truffle JS tests can be connected to a public testnet or mainnet, it's usually used together with another Truffle tool - local EVM and blockchain emulator called Ganache (see the config file where the author defines connection to a local blockchain). By default, Ganache mines a block after each transaction so that you (as a developer or a tester) don't need to worry about mining and other processes in setting up the network, and the response from the local blockchain it returned almost instantly.
if I do google, the way to call a method of a contract is either using .call or .send
Answering only about Truffle. Other packages such as Web3js or Ethers.js might have slightly different rules. And there are .call() and .send() methods in Solidity (for interacting with other contracts or addresses), that also behave differently than explained here:
You can interact with a contract in two different ways:
transactions (can make state changes - change contract storage, emit events)
calls (only read the contract data - no state changes)
By default, if you don't specify whether you want to make a transaction or a call, Truffle makes a transaction. You can override this decision and make a call instead by using the .call() method.
The .send() method is only used for low-level built transactions. A common use case is sending ETH - you need to build the transaction data field, fill the (ETH) value, and call the .send() method (assuming you have configured Truffle to use your private key to sign the transaction).
I'm working on updating some smart contracts to deploy on the Ethereum blockchain, however the cryptographic primitive for this project are really outdated and I don't know enough about cryptography to update them. Can anyone help me to rewrite the code? The repo is here -> [https://github.com/kCox96/smart-contracts/blob/master/contracts/Secp256k1_noconflict.sol]
Please don't write your own crypto!
If you just want to verify ecdsa-signatures you can use ecrecover() a builtin function to verify signatures, or this library https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/cryptography/ECDSA.sol
If you really need these curve functions there are some libraries out there (e.g. https://github.com/tdrerup/elliptic-curve-solidity) but they also seem to be not well maintained
I have a Google Assistant action with fulfilment through Firebase Cloud Functions. I understand that Cloud Functions may share instances between invocations, and that you can use the Global scope to do heavy lifting and preparation. My function instantiates a global class that has serialised some JSON and handles returning data and other tasks in my function. I have variables in this class that are set when the function is called, and I have been careful to make sure that the variables are all set using the conv.data session data object that is unique to the current conversation. The hope is that although the class instance may exist between different invocations, and possibly by different users, it will still be contextualised to the local scope, and I wont see any variables being overwritten by other sessions.
Which brings me to the question, which is, how can I test this? I have tried to test on my mobile device using the Google Assistant app, at the same time as testing in the browser console. I witnessed the two sessions getting merged together, and it was an unholy mess, but I am not sure if that was the global scope, or just that I was testing two sessions with the same user account.
Can anyone enlighten me on whether it is possible to run two of the same action using the same user account? It looked like the conv.data object had a mix of the two different sessions I was running which suggests it was using the same conversation token for both sessions.
Another question would be, do you think using a global class to store state across invocations is going to be an issue with different users? The docs do state that only one invocation of the function can ever happen at a time. So there shouldn't be any race condition type scenarios.
Dialogflow should keep the data in conv.data isolated to a single session, even sessions from the same user. When you're using Dialogflow, this data is stored in a Context, which is session specific.
You can verify this by turning StackDriver logging on, which will let you examine the exact request and response that Dialogflow is using with your fulfillment, and this will include the session ID for tracking. (And if you think it is mixing the two, posting the request and response details would help figure out what is going on.)
Very roughly, it sounds like you're getting something mixed into your global, or possibly something set in one session that isn't cleared or overwritten by a different one. Again - seeing the exact requests and responses should help you (and/or us) figure that out.
My attitude is that a global such as this should be treated as read-only. If you want to have some environment object that contains the relevant information for just this session - I'd keep that separate, just from a philosophical design.
Certainly I wouldn't use this global state to store information between sessions. While a function will only be invoked, I'm not sure how that would work with Promises - which you'll need once you start any async operations. It also runs the risk that subsequent invocations might be on different instances.
My approach, in short, (which I make pretty firm in multivocal):
Store all state in a Context (which conv.data should so).
Access this via the request, conv, or some other request-specific object that you create.
Global information / configuration should be read-only.
I don't use this pattern, maybe there are some places where it would have been appropriate and I used something else. Have you used it in your daily coding? Feel free to give samples, in your language of choice, along with your explanation.
Callbacks aren't really a "pattern" - more like a building block. A number of the gang of four design patterns use virtual methods in a callback-like way. Justin Niessner has already mentioned Observer.
Callbacks are much older than OOP (and probably older than 3GLs and even assembler). Another old idea is the parameter block - the C interpretation being a struct full of related members to be passed to a function so that function doesn't need a huge parameter list.
OOP classes build upon the parameter block (and add a philosophy to it). The class instance itself is a parameter block passed by reference to its methods. The virtual table is a dispatch-handling parameter block. Every virtual method has a callback pointer in the dispatch-handling parameter block. A pure virtual method reserves space for the callback pointer in the parameter block, and promises to provide the actual pointer later.
Since the class is the building block for object oriented design patterns, and parameter blocks and callbacks are the building blocks of classes - well, you could claim that all OOP design patterns are built from these ideas.
I'd like to be able to say "parameter blocks and callbacks, plus style rules guiding their use, inspired object orientation" but as appealing as it sounds, I don't know whether it's true.
I use callbacks pretty much every day in the following scenarios:
Events: When the user clicks their mouse on a control, presses a key or otherwise interacts with the UI in a way I need to handle, I subscribe to the delegate that the control publishes for the event. I can then handle it by updating the UI, cancelling the event in certain circumstances or otherwise taking some special action.
Multithreaded Programming: When programming a GUI, it's important to keep the UI responsive and indicate the progress of a long-running background event to the user. To do this, I kick off the task in a separate thread and then publish delegates (events in the .NET world) that provide my UI with the opporutinty to notify the user about progress that's happening.
Lambda functions: In .NET, lambda functions are a form of a delegate, one that lets me interact with another piece of code's operation at a later point in time. LINQ is a great example of this. I can create a small matching function and then supply it to a LINQ query. Later, when I execute my query against a collection, the matching function is called to determine if there is a match for the query. This allows me to not have to build or worry about the query mechanism. I just have to tell the query mechanism where to go to find out if a comparison is a match or not.
These examples just scratch the surface, I'm sure. But they are useful examples of how I use callbacks every day.
The .NET platform uses callbacks heavily to implement the Observer pattern.
They also get used for handling Asynchronous processes.
Objective C and the Cocoa framework make a lot of use of it. An example would be NSURLConnection, which will inform an object given to it (called its delegate) when something happens on the connection:
NSURLConnection *foo = [[NSURLConnection alloc] initWithRequest:request delegate:self];
Note the passing of delegate there. The request proceeds in the background, and the instance will then send messages to the delegate (in this case, self), like:
connectionDidFinishLoading:
connection:didFailWithError:
You get the idea. I believe this is called the "observer pattern". It's all tied in to Cocoa's event loop (as far as I know, I'm still learning) and is cheap 'n easy asynchronous programming. A lot of frameworks in a variety of languages follow this approach.
.NET has delegates as well, which are similar. Think events.
I use it a great deal in javascript to let me know when an asynchronous call has finished, so the result can be processed.
But, in javascript, and now in C#3, I pass in functions as a parameter, so that the processing can go on without explicitly setting up a delegate to be called.