I was building dojo from util/buildscripts/build.sh and including my custom modules resulted in a layer file(example dojo.js) to be just containing text "//>>built".
The issue is discussed here and solves the problem
http://dojo-toolkit.33424.n3.nabble.com/Building-of-1-7-2-custom-module-leaves-some-js-files-empty-td3781592.html
Related
Qt 5.15 introduces (at least I believe it is new to 5.15) .ts files, to allow for properly handling multi-locale text in an application. I'm updating an iOS Qt app from 5.X, where X knows nothing about .ts files. On startup, I'm getting a warning that indicates that there is an app-specific translation set (which is true), but that there is no translation for Qt's own text (things like warning text and dialog prompts). The documentation says, that these translations are in the Qt5 source directory (currently usually /tqtc-qt5) in the qtttranslations folder. Thus sayeth this doc https://doc.qt.io/qt-5/ios-platform-notes.html#application-assets. Examples show only app-unique text translations, not Qt's "built-in" text. So real quick, I'm going list my assumptions, so that they can be corrected or confirmed.
Qt has always had embedded text of its own, but 5.15 introduces a way to ensure that your multi-locale ready app has all the correctly translated "built-in" text available.
Only the app-writer knows what modules they are using, so it is the app-writer's responsibility to specify which set of translations are added to the app's resources for handling different locales. (per this document - https://doc.qt.io/qt-5/qmake-variable-reference.html#translations)
According to the above two docs, for example, if I use basic Qt functionality and QML, AND I have a single app with tier-one language support for, say, English, German, and French, it appears that my app's .pro file should include something like
TRANSLATIONS += <path_to_qt5>/qttranslations/qtbase_en.ts
TRANSLATIONS += <path_to_qt5>/qttranslations/qtbase_de.ts
TRANSLATIONS += <path_to_qt5>/qttranslations/qtbase_fr.ts
TRANSLATIONS += <path_to_qt5>/qttranslations/qtdeclarative_en.ts
TRANSLATIONS += <path_to_qt5>/qttranslations/qtdeclarative_de.ts
TRANSLATIONS += <path_to_qt5>/qttranslations/qtdeclarative_fr.ts
CONFIG += lrelease embed_translations
I've traced though the Qt source in the debugger to the point where it is complaining about the missing translations. It is looking for qt*_*.qm, where the first wildcard is your module ("base", "declarative", etc) and the second is your two-letter language code. So, should I be explicitly adding .qm files as resources in my iOS bundle, or is TRANSLATIONS += foo_ln.ts implicitly doing this embedding in response to CONFIG += lrelease embed_translations. One things is certain: right now, my naive porting of an older .pro file does nothing with respect the TRANSLATIONS property AND Qt is cranky about the missing .qm files in my bundle. It's a warning, not a critical fail, so I assume in a pinch, it would put up US english text, which seems to be the baseline for translations and is embedded in the source (not the bundle) by default. Do my example additions to the .pro file in point 3 above seem sufficient, or is there more to do? Or is there less to do? Is there a .pro directive that I've missed in the docs that says "do the right thing with international translations of Qt-inherent strings"? There is in a addition to the listed .ts files a "qt_*.ts" file set. Is this just everything whether I need it or not, for lazy people who don't care about lugging around a few extra strings? Finally, there is also EXTRA_TRANSLATIONS which is like TRANSLATIONS, only it does not go through the lupdate during the build. Now I'm pretty unclear on the function of lupdate relative to lrelease, but is it the case that one is for "stock" Qt strings, and the other for App-specific translations (because they may be "updated" due to changes during development)? The semantics just don't make sense to me right now, nor do my responsibilities to handle these matters in the "right" way.
I'd like to answer my own question because it turns out many of the above assumptions were just wrong, and it took deeper dives into the source code and the debugger to get my head straight, but now I have Wisdom. The documents I was reading was about how to include raw translation files "(.ts files)" into an app being built with qmake. As is typical with Qt, building with qmake or Qt Creator solves most of your problems automatically, with your part being to provide only the small amount of specification needed to execute your app. The app I'm working on however is monstrously huge, old, and overly-complicated, so I spend a lot of time hunting down the most obscure Qt and CMake features to cobble this Frankenstein's monster of an app together. The problem I was trying to solve is simply providing to Qt its own text localization files for a multi-locale app. The app-specific ones were fine, but Qt was wagging its finger at me and complaining that it couldn't find its own. So the .ts files it turns out are not a thing for this kind of task - they are simply part of the pipeline of getting data from a translation house in a consumable form. During Qt's own configure and build (yes we build Qt from source), it handles the compiling of raw .ts files into .qm files, suitable for use by the framework's translator objects. Those are all just sitting in qtbase/translations ready to be integrated into the app installation. The problem was that we (the group who developed this app long ago and which I am now reviving) didn't handle the iOS case. This is a special case that requires some choices. You can put translation files in the app's bundle at a specific path, you can home-brew some exotic URL resolution whereby you feed the translator the contents of the .qm files on demand, or you can compile them all into a .qrc file and position them in your resource tree. That last is what we did with the app-specific translations, so I mimicked it for Qt's, filtering the total set of .qm files for the modules we use and for the locales in our tier-one localization target languages. This involved a complicated python script, and a few extra lines of Cmake, including one very elusive one (QINIT_RESOURCES) that gated everything until I realized it was needed for this platform. I'm only wrapping this up, so if anyone else is confused enough to find this question, that there are some general comments to set things straight.
This issue describes the concept
https://github.com/dart-lang/source_gen/issues/272
To summarize:
I am using source_gen to generate some dart code.
I am using json_serializable on the generated dart code.
I wish to output all of the results to a source directory adjacent or below my target source.
The desired directory structure
src
feature_a
model.dart
gen
model.g.dart
model.g.g.dart
feature_b
...
I have considered building to cache however it seems json_serializable doesn't support this and even if it did I don't know if its even possible to run a builder on files in the cache.
I've also considered an aggregated builder that is mentioned here.
Generate one file for a list of parsed files using source_gen in dart
But json_serializable is still an issue and the source_gen version in that post is super old and doesn't describe the solution well.
This is not possible with build_runner. The issue to follow is https://github.com/dart-lang/build/issues/1689
Note that this doesn't help much with builders that you don't author, and wouldn't work with things like SharedPartBuilder.
I am trying to embed LaTeX formulas inside Markdown cell in a locally running Gorilla worksheet. For example, the following Markdown text should render an inline formula and a standalone formula:
This is an inline formula, ##\sin(x)##, and this is on its own line:
$$\int_0^{2\pi}\sin^2(x) \textrm{d}x$$
However, when I run Gorilla locally (using lein gorilla) what I see is the raw code. Markdown itself is rendered absolutely fine. On the other hand, when pushing the worksheet to GitHub and using an online viewer LaTeX formulas are rendered as expected.
Gorilla's documentation is saying the following, which I'm not sure I fully understand:
Note: currently you will need to be online in order for LaTeX to render properly.
What I thought is that it means that I have to have a network connection while trying to render LaTeX, but, if this is indeed the meaning, than I do not understand why it is not working. Another meaning I could think about is that currently LaTeX can only be rendered with the online viewer, but this interpretation dose not make much sense to me.
Any ideas? Thanks to any one pointing me to the right direction!
With some help I have found the solution to this problem—I was using an outdated version of lein-gorilla plugin. With version 0.5.3 LaTeX is rendered just fine[1]. The exact plugins line in project.clj should be similar to
:plugins [[org.clojars.benfb/lein-gorilla "0.5.3"]]
Also, it seems I was not aware that I could use the app-gorilla template for creating gorilla projects (I was using lein new app and then manually edited project.clj to add the plugins line). The command
$ lein new gorilla-app <project-name>
generates a project.clj file with the right version of the lein-gorilla plugin already in the file.
I guess this is the right way for creating gorilla apps, and that it ensures that the plugin will always be up to date.
[1] Some very specific LaTeX formulas seems to have rendering problems, but it needs some more testing and maybe a separate question.
I need to apply xdt transformations to other files than *.config ones.
I found the SlowCeetah extension which seems to provide this kind of feature as authors and extension page says, but, even if I setup the trasformation for xml files, and note that the
preview tool works well.., according to solution configuration manager configuratoins, no
transformation is applied.
For example I setup the trasformation for log4net.xml file, by using the tooling command "Add Transformation" which added log4net.{configname}.xml files but nothing happen when I deploy the solution or simply build with the specific build configuration.
Anyone has seen this issue?
Googlin' around I found that trasnformations to xml files should be applied to files setup as Content and Copy Always, anyone has suggestion about that?
I 'm very sad becaues I made all my configurations with transformations, and if I cannot solve that issue I lost 2 days of boring config job and I just can do that manually
Thanks in advance
Cheers
I'm seeking C++ help in writing HTML code to a new tab in Firefox within an extension.
Our C++ code has been partially wrapped by an XPCOM wrapper and embedded within a Firefox extension thanks to the work of a consultant we have lost contact with, and still partially implemented by calling out to a standalone executable.
To get our output displayed from the standalone executable, the C++ code writes the output to a file and simply calls system(firefox file.html) which then comes up with a file:-based URI.
This no longer works in all situations, based on a report from a user running Vista. So it seems to be time to do it right, and navigate the DOM, likely integrating the rest of the C++ code into the XPCOM-wrapped part. Perhaps there's a right way to do it from the standalone executable using the DOM model?
The "current working directory" seems to no longer match the directory in which the extension installed the standalone executable, with a "VirtualStore" path element.
We also generate parallel output in a different MIME type, VRML to be specific.
Any suggestions or examples for how to properly generate output into a Firefox browser pane under C++ programmatic control would be very much appreciated.
You could call Firefox with a fully specified file:/// URL, not a relative URL (file.html).
Or you if you want to dump a separate executable, you could implement a protocol handler or a simpler about module (where ios.newChannel would be replaced by your own channel implementation that generates the data).
I'd say keeping the file-generation solution is OK and doesn't seem very bad, so I'd go with (1), perhaps changing the generated file location to a temporary folder and specifying it fully both for the executable that generates it and for Firefox.