I noticed a strange behaviour of gettext in a Shiny application running on an Ubuntu 14.04 machine.
From ?gettext, we learn that:
If domain is NULL or "", and gettext or ngettext is called from a function in the namespace of package pkg the domain is set to "R-pkg".
But when I develop a package using gettext to perform the internationalization in an associated Shiny app, messages are not always translated.
I have developed a small reproducible example that you can find at Github :
devtools::install_github("tutuchan/gettext")
It is a very simple package with three functions:
hello() calls gettext("Hello, world!"), implicitly specifying the domain as R-gettext,
hello2() calls gettext("Hello, world!", domain = "R-gettext"), explicitly specifying the domain as R-gettext,
app() is a wrapper around shiny::runApp() to launch the app directly
The package includes the .po file for a French translation (which requires you to have a "fr_FR.UTF8" locale on your system to try it out).
If I call app(), both strings are translated:
But if I run the app directly, either by opening the file and clicking the Run App button in RStudio or by calling shiny::runApp("inst/app"), only the message with the domain called explicitly is translated:
I may have misunderstood the help from gettext but I'd be glad if anyone could shed some light on this.
Does gettext consider the top-level calling function when trying to match the domain ? Because in that case, it would make sense that when calling app(), all messages are translated while when calling shiny::runApp(), only those with explicit domains are translated (because for implicit domains, gettext would look for .po files in the namespace of the shiny package).
But I figured it would look for the domain of the function actually calling gettext.
It looks like gettext looks indeed in the namespace of the toplevel function for translation files when the domain is not specified.
I created another package that contains translation files and calls the app from my gettext package. When gettextpo::app() is called (which calls gettext::app() internally, the translation when the domain is implicit is found in the namespace of the gettextpo package, and not gettext.
Related
I'm attempting to use Hydra's compose API to launch runs programmatically instead of via CLI. This works for the most part. However, overriding hydra.run.dir to change the base directory doesn't seem to have the effect when using the compose API. I.e.:
with hydra.experimental.initialize_config_module(config_module=config_module):
cfg = hydra.experimental.compose(
config_name=config_name,
overrides=["hydra.run.dir=/tmp/workdir", ...],
return_hydra_config=True
)
hydra.core.hydra_config.HydraConfig.instance().set_config(cfg)
with omegaconf.open_dict(cfg):
del cfg["hydra"]
generates a DictConfig with the appropriate entry for hydra.run.dir, but the working directory is not changed.
The compose API documentation states that not using #hydra.main entails forfeiting Hydra's working directory management. Is there a workaround for this?
The Compose API is stateless and is intentionally not changing the working directory, configuring the logging or changing global state and not integrating with the command line. If you need these functionalities you should consider using #hydra.main().
As a workaround, you can call chdir programmatically on your end (with os.chdir). You will probably also need to mkdir first.
I am writing my first meteor package. I started writing an app and thought it would be nice, to make one of the main functionalities available for others as open source.
I know in meteor you can make a variable globally accessible by adding an export in the package.js, but how could I do something like the following, assuming my export variable is called "MyPackage"(pseudo code):
.on(AppDefinedMyPackage, function(){})
in the moment this part of the app's code is run(outside of the package, of course):
MyPackage = new Meteor.Collection('test');
I'd like to host the TimeLineJS library on my Meteor app locally and not use the smart package because I need to fine tune it. I've tried declaring the createStoryJS function in the Meteor space like this in create Timeline.js. However, there are other dependencies (storyjs-embed.js, storyjs-embed-generator.js, storyjs-embed.js, and everything under locale) which rely on the document object on the browser. How can I ensure that Timeline.js is loaded in a template with all of its dependencies locally managed, while successfully accessing the window.document object?
Put all the files in client/compatibility in your app, such that the dependencies load first via Meteor’s load order (e.g. put dependencies in client/compatibility/lib, for example). That’s all you have to do: no script tags, no declaring anything. Initialize TimeLineJS within a template’s onRendered callback.
I usually follow the unofficial Meteor FAQ on how to structure my codebase, but I can't figure out where I should put my global constants.
To give an example: I have some database entries with a constant GUID that I need to reference in many points of my app. So far I just attached the constants to the relevant collection, such that in collections/myCollectionWithGuids.coffee it would say:
#MyCollectionWithGuids = new Meteor.Collection "myCollectionWithGuids"
#MyCollectionWithGuids.CONSTANT_ID = "8e7c2fe3-6644-42ea-b114-df8c5211b842"
This approach worked fine, until I need to use it in the following snippet, located in client/views/myCollectionWithGuidsView.coffee, where it says:
Session.setDefault "selectedOption", MyCollectionWithGuids.CONSTANT_ID
...which is unavailable because the file is being loaded before the Collections are created.
So where should I put my constants then, such that they are always loaded first without hacking in a bunch of subdirectories?
You could rely on the fact that a directory names lib is always treated first when it comes to load order.
So I would probably advise you to organize your code as follow :
lib/collections/collection.js
client/views/view.js
In your particular use case this is going to be okay, but you might find cases when you have to use lib in your client directory as well and as the load order rules stack (subdirectories being loaded first), it will be loaded BEFORE the lib folder residing in your project root.
For the moment, the only way to have full control over the load order is to rely on the package API, so you would have to make your piece of code a local package of your app (living in the packages directory of your project root).
It makes sense because you seem to have a collection and a view somehow related, plus splicing your project into a bunch of collaborative local packages tends to be an elegant design pattern after all.
Creating a local package is really easy now that Meteor 0.9 provide documentation for the package.js API.
http://docs.meteor.com/#packagejs
I would put your collection definitions in a lib directory. File structure documentation explains that all files under the lib directory get loaded before any other files, which means your variable would be defined when you attempt to access it in your client-side code.
Generally speaking, you always want your collections to be defined before anything else in your application is loaded or executed, since your application will most likely heavily depend upon the use of the collection's cursor.
I am writing a Qt application that calls QProcess::startDetached("wscript.exe script.vbs") to show the delete confirmation dialog in Windows.
this is the script:
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace("-")
Set objFolderItem = objFolder.ParseName("-")
objFolderItem.InvokeVerb("Delete")
the arguments for Namespace and ParseName are from the arguments passed to the script.
This may be inefficient because it opens an external application first before running the script. I was wondering if i can run VBScripts in a Qt application.
If not, what alternatives can i do?
My VBScript is very weak, so I'm not 100% sure I understand what you are trying to do. My assumption is that you are trying to delete a folder, but want to give the user the normal confirmation box and animation while the action is occurring. If that is not correct, please let me know and I will remove this answer.
A few ideas:
You could call the Windows API directory within your C++ code to do this. I believe the correct call would be to use IFileOperation (Vista and later) or SHFileOperation (pre-Vista)
Qt already has message box dialogs. Although you might not get the exact same functionality as the native shell, you could use this (QMessageBox::warning) and then delete the folder using QDir. This would also be cross-platform portable.
If you stick with the VBScript, I doubt you would see any performance issues unless this is being called many, many times in a loop or something. You know, the old "premature optimization is the root of all evil" thing.
You should read up on the IActiveScript COM interface. You can create an instance of an interpreter that implements IActiveScript to provide a runtime for evaluating scripts. VBScript and JScript can both be used for this and a number of other third-party scripting languages also provide IActiveScript support.
The overview for working with this is you create a language runtime (an instance of VBScript for instance) then add some custom objects to it. Typically if you are embedding an interpreter into your application then exposing an Application object is a good place to start. This can be just an IDispatch interface or something more concrete with an IDL generated typelibrary and all the trimmings. Once you have added the necessary named items into the runtime you load one or more scripts. Any public functions or subroutines declared in the scripts now get exposed via the IDispatch interface of the live runtime once you switch its state to active or running. To actually run the script program, I invoke the Main function for my stuff - you could choose some other scheme as applicable to your environment.
The nice thing about ActiveScripting, is to change language you just change the runtime CLSID. So if people prefer Perl they can use PerlScript or PythonScript etc. Your Application object remains the same hence you don't have to write additional code to support the new languages. The only requirement is that everything is COM.