Although I'm still poking around in the docs and online, I figured I'd ask this one here, for future folks who run into it.
Using copylocale for localization, I made a typo (e.g., "en_FR" instead of "fr_FR") and mistakenly created a locale I don't want. What's the proper way to remove it? Is it enough to simply delete it from my framework directory, or is there a helper app somewhere that handles the cleanup if there's more to it than that?
Thanks in advance!
you should be able to simply delete it from the locale directory. The copylocale just creates a copy, nothing more. Just nuke it and you should be good to go. More information here:
http://labs.adobe.com/wiki/index.php/Flex_3:Feature_Introductions:_Runtime_Localization
Related
Why some data on server-side are still stored in DBC files, not in SQL-DB? In particular - spells (spells.dbc). What for?
We have a lot of bugs in spells and it's very hard to understand what's wrong with spell, but it's harder to find it spell...
Spells, Talents, achievements, etc... Are mostly found in DBC files because that is the way Blizzard did it back in the day. It's true that in 2019 this is a pretty outdated way to work indeed. Databases are getting stronger and more versatile and having hard-coded data is proving to be hard to work with. Hell, DBCs aren't really that heavy anyways and the reason why we haven't made this change yet is that... We have no other reason other than it being a task that takes a bit of time and It is monotonous to do.
We are aware that Trinity core has already made this change but they have far more contributors than we do if that serves as an excuse!
Nonetheless, this is already in our to-do list if you check the issue tracker at the main repository.
While It's true that we can't really edit DBC files because we would lose all the progress when re-extracted or lost the files, however, we can modify spells in a C++ file called SpellMgr.
There we have a function called SpellMgr::LoadDbcDataCorrections().
The main problem while doing this change is that we have to modify the core to support this change, and the function above contains a lot of corrections. Would need intense testing to make sure nothing is screwed up in the process.
In here by altering bits you can remove or add certain properties to the desired spells instead of touching the hard coded dbc files.
If you want an example, in this link, I have changed an Archimonde spell to have no cast time.
NOTE:
In this line, the commentary about damage can be miss leading but that's because I made a mistake and I haven't finished this pull request yet as of 18/04/2019.
The work has been started, notably by Kaev. I think at least 3 DBCs are now useless server side (but probably still needed client side, they are called DataBaseClient for a reason) like item.dbc.
Also, the original philosophy (for ALL cores, not just AC) was that we would not touch DBC because we don't do custom modifications, so there was no interest in having them server side.
But we wanted to change this and started to make them available directly in the DB, if you wish to help with that, it would be nice!
Why?
Because when emulation started, dbc fields were 90% unknown. So, developers created a parser for them that just required few code changes to support new fields as soon as their functionality was discovered.
Now that we've discovered 90% of required dbc fields and we've also created some great conversion tools for DBC<->SQL, it's just a matter of "effort".
SQL conversion is useful to avoid using of client data on server (you can totally overwrite them if you don't want to go against EULA) or just extends/customize them.
Here you are the issue about DBC->SQL conversion: https://github.com/azerothcore/azerothcore-wotlk/issues/584
My package introduces registry entries. Changes by site administrator should not be overwritten on reinstall of the package.
Many ways to Rome. I chose ftw.upgrade. I like the declarative way of the upgrade step syntax. Its possible to use an upgrade directory for generic setup xml-Files like propertiestool.xml. No need to define handler python code. The upgrade works well. The admin can upgrade from control panel and in my case the new property is added. Insomma: For a new property just these have to be added: an upgrade-step declaration for source and destination version and directory where to find the properties.xml. Thumb up! –
You can pilot what to do when installing a Plone add-on by providing an Extension/install.py file with a install method inside:
def install(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-your.pfile:default')
This way you are driving what Plone should do when installing.
If you need it: the same if for uninstall:
def uninstall(portal, reinstall=False):
if not reinstall:
setup_tool = portal.portal_setup
setup_tool.runAllImportStepsFromProfile('profile-example.gs:uninstall')
This way you can prevent the uninstall step to be run when reinstalling.
Warning: as Mathias suggested using quickinstaller -> reinstall feature is bad.
Warning: this will not probably work anymore on Plone 5 (there's open discussion about this).
I think what you describe is one of the problems upcoming with the increasing complexity of Plone's stack, and one of the reasons, why it is not recommended to execute a re-install anymore, but to provide a profile for each version of the Add-On, via upgrade-steps (as Mathias mentioned). That increases dev-time significantly and results in even more conflicts, of my experience. Here are the refering docs:
http://docs.plone.org/develop/addons/components/genericsetup.html#add-upgrade-step
Elizabeth Leddy once wrote an Add-On to ease that pain and I can confirm it does:
https://github.com/ampsport/amp.ezupgrade
And the great guys from FTW, too, I never used it, but looks promising:
https://pypi.python.org/pypi/ftw.upgrade
Neither used this one, even claims to have some extra goodies, like cleanup broken OFS objects and R. Patterson's on it:
https://github.com/collective/collective.upgrade
As we're here, the first good doc I could find about it ~ 1.5 years ago, comes from Uwosh, of course:
http://www.uwosh.edu/ploneprojects/docs/how-tos/how-to-use-generic-setup-upgrade-steps
Another solution can be, to check, if it's an initial- or re-install, and set the properties programatically via a Python-script, conveniently called 'setuphandlers.py', like described in this answer:
How to check, if my product is already installed, when installing it?
That way one can still trigger re-installs without blowing it all up.
Lastly, a lot of the GS-xml-files understand the purge-property, setting it to False, will not overwrite the whole file, just your given props. This might, or not, apply to your case, you can find samples in the above referenced official doc.
Is it possible to add or remove scripts from a bundle based on the debug setting of the application?
I.e. Given a bundle definition of-
var jQueryBundle = new ScriptBundle("~/js/main").Include(
"~/Scripts/jquery-1.{version}.js",
"~/Scripts/jquery-migrate-{version}.js",
"~/Scripts/script.js");
Remove the jquery-migrate reference when the site is not running in a debug profile, or conversely add it under debug.
Nb. I actually came up with a solution to this whilst formulating the question, I have tested it and it seems to work. I have answered it but left it unaccepted for now should a better solution present. In the mean time the answer will at least now be available for reference should anyone want to make use of it.
I actually came up with an answer to this whilst writing out the question. Since I hadn't been able to find an answer through searching I decided to post the question anyway and answer it - both so it is available as reference for anyone else wanting to do the same thing, and to get feedback from wiser minds than mine if this the most performant way of achieving this - or even a sensible thing to do.
var jQueryBundle = new ScriptBundle("~/js/main").Include(
"~/Scripts/jquery-1.{version}.js",
"~/Scripts/script.js");
if (HttpContext.Current.IsDebuggingEnabled)
{
jQueryBundle.Include("~/Scripts/jquery-migrate-{version}.js");
}
bundles.Add(jQueryBundle);
I have tested this and whilst debugging the script is listed (I have retained the defaults of bundling and minification left off in debug mode) and whilst running normally the contents of the migration script were not in the combined minified script. Over the next couple of days I will profile this to compare to "vanilla" bundling to see what (if any) performance impact this has on application start.
I figured out how to do a lot of things in the JGit library, such as commit files, find out the status of all files (ie. changed, modified, untracked etc), but i can't figure out how to unstage files i added to the index. Could someone let me know how to do this and maybe point me to some documenation as the eclipse site has none, and i can't find any on Google.
Also if anyone know how to ammend a commit i would much appreciate knowing that too.
Thanks.
Looks like you found a way to unstage files but ran into trouble as explained in your other question:
repository.getIndex().remove(getWorkignDirectoryAsFile(), new File(getWorkignDirectoryAsFile(), fileName));
repository.getIndex().write();
Did you solve your issue with the above? I notice that repository.getIndex() is deprecated and org.eclipse.jgit.dircache.DirCache should be used instead.
To amend a previous commit, you should look at
org.eclipse.jgit.api.CommitCommand.setAmend(boolean)
Would be great if you could report on your own answers if you found any.
My team now has an SVN + Ankh setup in ASP.NET with trunk, branches, and tags. We switch branches and work on code, but many times there will be inexplicable conflicts in files after simple changes. Why is this? I suspect we simply don't understand enough of how this works. Are there any do's and don'ts, or how should we be approaching our daily changes and commits, without causing conflicts? Is there a basic pecking order of operations to perform to achieve SVN zen? Are we updating before committing or something? Any help is greatly appreciated.
Always update before commit. If you really work with branches don't use switch or only if you really undstand the switch command and how it works otherwise checkout a branch into a fresh working copy in other words create a new one.
Always branch, merge on the solution element, make sure you're fully up to date before merging (ankhsvn will warn about this), also make sure you have no modified files before merging.
Read up on svnbook for when to use normal merging and when to use reintegrate.
Finally, if a conflict does occur, make sure you have a good 3way merge tool to solve the conflict. AnkhSVN recognizes a lot of them automatically, but I really like source gear diffmerge