In Solidity, it's possible to use block.number and blockhash(uint blockNumber) returns (bytes32) to obtain the current blockhash from inside a function. I need do the same thing inside a Solana program. I'm using Anchor.
I went through Anchor docs and found a (deprecated) method to get recent blockhashes, but not the current blockhash. I've also tried finding similar projects that might rely on the current blockhash, but I haven't found anything yet.
Is it possible to access the current block hash from inside a Solana program function?
You were looking in the right place -- RecentBlockhashes is on its way out, but you can use the SlotHashes sysvar: https://docs.rs/solana-program/1.10.19/solana_program/slot_hashes/struct.SlotHashes.html
It's tougher to use since you can't deserialize the whole thing into memory on-chain, but you can at least deserialize slices of it.
Related
In Rust, you can use the black_box function to force the compiler to
assume that the function's argument is used (forcing it not to optimize away code that generates that value)
not be able to inspect how its return value is produced (preventing it from doing constant-folding and other such optimizations).
Is there a similar facility in Go (to accomplish either task)?
Is there a similar facility in Go (to accomplish either task)?
No.
If you want to use a result: Assign to an exported global.
I believe runtime.KeepAlive is recommended, as per the following Github issue. Unfortunately, it's unclear whether anything exists for function arguments, or whether KeepAlive is even guaranteed to work.
https://github.com/golang/go/issues/27400
This is a follow-up to this Dart question.
Since Flutter doesn't support reflection and we can't use mirrors, how would you go about debugging, let's say an instance of firebase_database DatabaseReference ?
I'm trying to write tests, and knowing what key/values my reference contains will make it easier for me to write a proper test.
since Dart 3.12 you can use inspect(object) to achieve this
If you expect to have a built-in easy solution, then sorry : You can't.
BUT you can use plugins to serialize your own code, such as built_value. And print the serialized object.
On the other hand, if you want to print external code (DatabaseReference for instance), you'll have to manually transform that object in a combination of Map, List, and int/String/double.
As a continuation of this question and the subsequent answer, does anyone know how to have a job created using the Parallel Computing Toolbox (using createJob and createTask) access external toolboxes? Is there a configuration parameter I can specify when creating the function to specify toolboxes that should be loaded?
According to this section of the documentation, one way you can do this is to specify either the 'PathDependencies' property or the 'FileDependencies' property of the job object so that it points to the functions you need the job's workers to be able to use.
You should be able to point the way to the KbCheck function in PsychToolbox, along with any other functions or directories needed for KbCheck to work properly. It would look something like this:
obj = createJob('PathDependencies',{'path_to_KbCheck',...
'path_to_other_PTB_functions'});
A few comments, based on my work troubleshooting this:
It appears that there are inconsistencies with how well nested functions and anonymous functions work with the Parallel Computation toolkit. I was unable to get them to work, while others have been able to. (Also see here.) As such, I would recommend having each function stored in it's own file, and including those files using the PathDependencies or FileDependencies properties, as described by gnovice above.
It is very hard to troubleshoot the Parallel Computation toolkit, as everything happens outside your view. Use breakpoints liberally in your code, and the inspect command is your friend. Also note that if there is an error, task objects will contain an error parameter, which in turn will contain ErrorMessage string, and possibly the Error.causes MException object. Both of these were immensely useful in debugging.
When including Psychtoolbox, you need to do it as follows. First, create a jobStartup.m file with the following lines:
PTB_path = '/Users/eliezerk/Documents/MATLAB/Psychtoolbox3/';
addpath( PTB_path );
cd( PTB_path );
SetupPsychtoolbox;
However, since the Parallel Computation toolkit can't handle any graphics functionality, running SetupPsychtoolbox as-is will actually cause your thread to crash. To avoid this, you need to edit the PsychtoolboxPostInstallRoutine function, which is called at the very end of SetupPsychtoolbox. Specifically, you want to comment out the line AssertOpenGL (line 496, as of the time of this answer; this may change in future releases).
I'm considering how to do automatic bug tracking and as part of that I'm wondering what is available to match source code line numbers (or more accurate numbers mapped from instruction pointers via something like addr2line) in one version of a program to the same line in another. (Assume everything is in some kind of source control and is available to my code)
The simplest approach would be to use a diff tool/lib on the files and do some math on the line number spans, however this has some limitations:
It doesn't handle cross file motion.
It might not play well with lines that get changed
It doesn't look at the information available in the intermediate versions.
It provides no way to manually patch up lines when the diff tool gets things wrong.
It's kinda clunky
Before I start diving into developing something better:
What already exists to do this?
What features do similar system have that I've not thought of?
Why do you need to do this? If you use decent source version control, you should have access to old versions of the code, you can simply provide a link to that so people can see the bug in its original place. In fact the main problem I see with this system is that the bug may have already been fixed, but your automatic line tracking code will point to a line and say there's a bug there. Seems this system would be a pain to build, and not provide a whole lot of help in practice.
My suggestion is: instead of trying to track line numbers, which as you observed can quickly get out of sync as software changes, you should decorate each assertion (or other line of interest) with a unique identifier.
Assuming you're using C, in the case of assertions, this could be as simple as changing something like assert(x == 42); to assert(("check_x", x == 42)); -- this is functionally identical, due to the semantics of the comma operator in C and the fact that a string literal will always evaluate to true.
Of course this means that you need to identify a priori those items that you wish to track. But given that there's no generally reliable way to match up source line numbers across versions (by which I mean that for any mechanism you could propose, I believe I could propose a situation in which that mechanism does the wrong thing) I would argue that this is the best you can do.
Another idea: If you're using C++, you can make use of RAII to track dynamic scopes very elegantly. Basically, you have a Track class whose constructor takes a string describing the scope and adds this to a global stack of currently active scopes. The Track destructor pops the top element off the stack. The final ingredient is a static function Track::getState(), which simply returns a list of all currently active scopes -- this can be called from an exception handler or other error-handling mechanism.
I call Ruby functions from my C++ code through the embedding commands (rb_eval and the like). Is there any way to stop the execution of the code partway, save the local variables, and restart it from the same spot later?
If you want to store Ruby variables for use later, you want to use a feature called Marshaling. Create a class in which you can store all variables you wish to save, and use Marshal::dump to store the class into a file. The data can be reconstituted into a Ruby variable again later by using Marshal::load.
Restarting your code from a particular point might not be as easy. You can marshal classes and data but not necessarily the state of the entire Ruby interpreter itself. One possibility is to store enough state information in your marshaled data to let you re-load the data and figure out where you need to pick up.