I was looking at the code of a cryprocurrency and I thought what will happen to the cryprocurrency if it's genesis block is change.Will a new cryprocurrency can be created if genesis block is changed
Genesis block is the first block of a block chain.
Of course, if you change this block, you will be creating another currency or restarting the network.
If you do this in a blockchain that already exists, I believe you may have future problems, as the new nodes will try to pick up the information from the genesis block when you start synchronization.
If the code that you changed is, for example, the one of the BTC and compile it and then put to run, will have no effect on the network, since the main nodes are unaware of this block, making its configuration invalid.
Related
In my Tcl extension, a secondary thread is filling the Tcl event queue with events; the events contain pointers to structures with a dynamic life time.
What is the right strategy for ensuring that no events with dangling pointers to de-allocated structures remain in the event queue? I can prevent the secondary thread from creating new events; currently I call Tcl_DoOneEvent(TCL_DONTWAIT) in a loop till it returns 0 (i.e., event queue is empty) after ensuring no new events can be created and before de-allocating the structure.
Is that the right way to do it?
On a related note, I am unsure of the purpose of Tcl_ThreadAlert(): if this is needed after every call to Tcl_ThreadQueueEvent(), why isn't the alert included in Tcl_ThreadQueueEvent()?
Finally, my code does not call Tcl_CreateEventSource(), since it doesn't seem to be needing a setup nor a check procedure as a second thread is involved. Is that cause for concern?
On the first point, that seems OK to me. It is very much like running update at the TCL level.
I'm not sure about the second point, as it isn't part of the API that I have explored a lot. It might be that way to allow multiple events to be scheduled per notification, or because there are other uses for the call, but I really don't know.
On the third point, it sounds fine. I think you never need special event sources just to do inter-thread messaging.
I am using Drupal 7.51. I've changed the block status to --none--, but it is still out there.That is very strange.
By "block status" I am assuming you are talking about the block's placement on /admin/structure/block.
If the block is turned off there, there are only a few other usual ways to place the block.
Context
Panels
Some other module like LoginToboggan that creates a replacement block.
I'd check those three to make sure they aren't affecting anything.
Turn off those modules if they are on and flush your caches to see if the block disappears.
The block could also be created by a custom module if you have any of those.
If none of that helps, use your browser's inspector to see if there are any clues around the block code to indicate what might be providing the block.
I was reading about the .settings file on msdn and I noticed they give 2 examples of how to set the value of a item in the settings. Now my question is what is the real diffrence between the 2 and when would you use one instead of the other, since to me they seem pretty mutch the same.
To Write and Persist User Settings at Run Time
Access the user setting and assign it a new value, as shown in the following example:
Properties.Settings.Default.myColor = Color.AliceBlue;
If you want to persist changes to user settings between application sessions, call the Save method, as shown in the following code:
Properties.Settings.Default.Save();
The first statement updates the value of the setting in memory. The second statement updates the persisted value in the user.config file on the disk. That second statement is required to get the value back when you restart the program.
It is very, very important to realize that these two statements must be separate and never be written close together in your code. Keeping them close is harakiri-code. Settings tend to implement unsubtle features in your code, making it operate differently. Which isn't always perfectly tested. What you strongly want to avoid is persisting a setting value that subsequently crashes your program.
That's the harakiri angle, if you saved that value then it is highly likely that the program will immediately crash again when the user restarts it. Or in other words, your program will never run correctly again.
The Save() call must be made when you have a reasonable guarantee that nothing bad happened when the new setting value was used. It belongs at the end of your Main() method. Only reached when the program terminated normally.
I've recently been asked by my supervisor to prepare a solution in which multiple pieces of logic throughout our application can be reverted back to an earlier piece of code while the application is live. In effect, I need to prepare something like a flag or an indicator that can be dynamically activated to switch all instances of code in our application, from the new version back to the old one.
The new logic was prepared by a new member of our team and we are concerned about memory leaks that will emerge once the code goes to production, and we want a solution in place that will allow us to turn those changes off and return to the original code if necessary.
if (new_code == ON)
{
New Logic
}
else
{
Old logic
}
This project was originally meant to help get rid of build and compile warnings during our build process so it affects code ranging from function arguments to variable declarations, so there's no one single type of code that will be affected. We are running off a tuxedo stack but implementing a tuxedo config file to effect this change isn't recommended according to one of our senior developers. I'm not aware of a similar solution, though.
Any ideas? Thanks!
Would it work? Sure. Is it a good idea? No. You now have the risk of the new code, plus the risk of bugs in your switch code, plus the risk of what happens if you switch from one to the other in mid-run. You shouldn't be doing this, its far more likely to cause trouble than just deploying the changes directly.
What you should do- if you're really concerned about it, don't deploy it. Put it through additional testing until you're comfortable with it. Then when you do deploy it, have a plan to roll back to a previous version without these changes if something slips through testing.
call the function using function pointers.
make an API to change the function pointer to old or new depending on your need.
I set up a number of custom regions for my home page, which uses a custom template, and was able to position them and assign blocks to them as I wanted.
However, at random, any blocks I assign to these regions will disappear. When I look in the _block table of the database, the value set to the region field is -1 (ie., not assigned), and I have to go in and reassign the blocks for these regions.
This happens whether I cache my blocks or not.
It does not happen when I run a cron or clear my cache. As this only happens to my custom fields, I feel like there is something else I should be doing in addition to setting up my regions in the theme's and subtheme's .info files, that would make block assignments to these regions as persistent as they would be to a standard region.
A number of people have reported this over at Drupal.org, but no one has been able to come up with an answer. I've researched this for the last several weeks, and looked through any scripts that might store or rewrite my database to those values.
It always happens overnight, but not at any reliable interval: I can go a week without it happening, or I can go a day.
It does not happen on the offline XAMPP stack I use as my development server. There may be something going on with my web host, but as this is a very specific problem, I am thinking it has to do with how my custom regions are set up.
I used the directions at this blog: http://megadrupal.com/blog/add-new-regions-in-drupal-7-themes.
I have posted a question about it there, but have not received a reply yet.