I wrote a plugin for babel that relies on the opts.filename and opts.filenameRelative properties. It seems to be working within babel-loader for the purposes of analyzing the adjacent files, but the filename itself seems to be modified.
I'm wondering if theres a way, using babel-loader, to get access to the full source file path to use for generating a legible id and hash.
babel-loader does indeed pass the filename into the transform function. In my particular case, I was preprocessing typescript files with awesome-typescript-loader, and that was messing with the file path.
Is there a way to limit SugarCRM to just one language (us_en)? Right now everything we do generates 40+ language files which we'll never use. It makes finding things in the folders very difficult.
After removing all the languages except en_us my /sugarcrm/config_override.php contains the following:
<?php
/***CONFIGURATOR***/
$sugar_config['disabled_languages'] = 'bg_BG,cs_CZ,da_DK,de_DE,el_EL,es_ES,fr_FR,he_IL,
hu_HU,hr_HR,it_it,lt_LT,ja_JP,ko_KR,lv_LV,nb_NO,nl_NL,pl_PL,pt_PT,ro_RO,ru_RU,sv_SE,
th_TH,tr_TR,zh_TW,zh_CN,pt_BR,ca_ES,en_UK,sr_RS,sk_SK,sq_AL,et_EE,es_LA,fi_FI,ar_SA,uk_UA';
/***CONFIGURATOR***/
I then created test with a new package, named Dan, which has one module named Pets. When I look in version control I still have a file for each available language in the sugarcrm/custom/modulebuilder/packages/Dan/modules/Pets/languages
It seems you can accomplish that by modifying the language array in the sugar config.
Make sure to make a backup of your config.php, so that you have the original language array if you need it back. This is important even although our change will be in another file, because Sugar might recreate config.php automagically, using the resulting array, losing the original one.
In your config_override.php add this line:
$sugar_config['languages'] = array('en_us' => 'English (US)');
Be aware that above line will make 'en_us' the only available language on that instance and Studio/etc. should now only create en_us files. If that is not the solution you're looking for - let me know please.
EDIT:
Above steps only seems to disable file creation spam for Dropdown Editor.
If you also want to make Module Builder not create any non-en_us language files, I found this - quite invasive - method of accomplishing just that:
Create a Backup of the instance, then remove all *.lang.php files from the directories of include/ and modules/, except for en_us.* files. On Linux you can do this with find include modules -name '*.lang.php' -not -name 'en_us.*' -print -delete
Delete the contents of the cache/ folder
In Sugar run Administration -> Repair -> Quick Repair and Rebuild
This made my Module Builder only create en_us language files.
Note: If anybody should ever consider doing this for any other language than en_us, make sure to not only keep your language of choice, but also keep the en_us files additional to that! Those files are expected to exist in Sugar, as they are e.g. used for fallbacks of missing strings in any other language. Deleting the en_us files may lead to unexpected side-effects!
I'm using Eclipse and Doxygen on a Linux platform. My teams code is controlled with Clearcase. My question is can I use an environment variable as part of the path to excluded?
example: every one on the project has a custom view as part of their path. And I don't want to see that in the documentation.
/view/me/a/b/src/.../...
/view/you/a/b/src/.../...
in each developers view their is an environment variable defined with their view name. ex: $CLEARCASE_ROOT = /view/me
So I'm trying to setup a single Doxygen file for whole team to use..
So I want to do something like EXCLUDE ${CLEARCASE_ROOT}/a/b
Then everybody that generates docs will get the same paths.. Can I do this??
Thanks.
Yes, doxygen supports environment variable expansion in its configuration files, see http://www.doxygen.nl/manual/config.html.
The EXCLUDE option controls which files are parsed by doxygen. It sounds like you want the files to be included, but you want them to be displayed with a relative include path, in that case you probably want to use the STRIP_FROM_INC_PATH option. If there are other absolute paths in the documentation you're attempting to make relative, the STRIP_FROM_PATH option may also come into play.
The syntax is a little different than what you proposed, $() vs. ${}, so you'll want to specify something like:
STRIP_FROM_INC_PATH = $(CLEARCASE_ROOT)/a/b
STRIP_FROM_PATH = $(CLEARCASE_ROOT)
Is it possible to exclude files from debugging in Eclipse?
There are my files which I have written and I am interesting in going through these files using debugger Step Over command.
But there are also many imported library files and Step Over goes into these files, which I'd like to avoid. So is there an option eother to specify which files to debug or which files to exclude?
If you're using a JVM based language (as you didn't specify), under Preferences, filter for Step Filtering.
You will see a list of packages. Add your packages to the list, and ensure Use Step Filters is selected.
Assuming it's an entire package you want filtered out, and you're using Java, this should do what you want.
I have used file search functionality in eclipse to replace a specific occurrence of text with a replace text which contains a java method name in all files across the workspace.
But now in all those files I have to add the import statement (for the method name to resolve).
Is there an automatic way of doing this instead of manually searching and importing the package myself in all files?
P.S.: I can't use java refactoring since the text I have changed is not a java element and Organize import option will make changes to lot of files (re-ordering imports) which will be problematic when I need to commit, I again have to manually check differences to see which files have actual changes instead of just organize import statements.
Instead of doing this with search and replace, try to use Refactor->rename which will do it correctly.
another options is to use organize imports, you can do it for an entire project as well (source -> organize imports).