Which IDE supports gtpl (groovy templates)? - groovy

So, IntelliJ/Idea can't seem to find time to support Groovy's templating language (IDEA-96594) - especially markuptemplateengine.
Which IDE supports GTPL's? Are there any?

just renaming ".gtpl" to ".gsp" will do the trick

Related

Searching for Python MSDOS parser library

Does anyone knows a good Python library to parse MSDOS files and obtain metadata and start()'s bytecodes? Like an alternative version of pefile library but for MSDOS? I can't seems to find any via Google.
If there isn't, is there a good source to refer to on MSDOS's file format? This way, I can create my own parser instead. I know there are tools like IDA Pro and Reko decompiler but I need a MSDOS file parser to automate some stuff. Thank you in advanced!
Reko decompiler maintainer here. For what it's worth, you can use Reko's MS-DOS source code and translate it to Python. It's not a lot of code and MS-DOS executables aren't that complex to parse -- it's quite a simple format. The relevant files are:
https://github.com/uxmal/reko/blob/master/src/ImageLoaders/MzExe/ExeImageLoader.cs
https://github.com/uxmal/reko/blob/master/src/ImageLoaders/MzExe/MsdosImageLoader.cs
You could also try executing the Reko code directly from Python. The Reko binaries are available as a nuget package: https://www.nuget.org/packages/Reko.Decompiler.Runtime
Use the class Reko.ImageLoaders.MzExe.ExeImageLoader in the Reko.ImageLoaders.MzExe class. Integration could be done with http://pythonnet.github.io/

MissingTranslation Errors after Upgrading to Gradle 3.3

Since upgrading to Gradle 3.3 I'm having trouble building my code due to missing-translation errors:
Error: xxx is not translated in "af" (Afrikaans), "am" (Amharic), "ar" (Arabic), "az" (Azerbaijani), "az-AZ" (Azerbaijani: Azerbaijan), "be" (Belarusian), "bg" (Bulgarian), "ca" (Catalan), [...], "zh-TW" (Chinese: Taiwan), "zu" (Zulu) [MissingTranslation]
The majority of the reported languages are those supported by a 3rd-party module included in my project, and it now seems to define the supported languages for the entire project, giving me this kind of error for all strings that are not translated into above languages. Before upgrading to Gradle 3.3 this was not causing any problems.
I considered the following solutions:
Remove surplus translations from other modules. I want to avoid that because those modules are external and needlessly altering them would really hurt maintainability of my project.
Disable the "incomplete translation" Lint inspection - the most common suggestion for similar questions on SO. This is sub-optimal because I want to be made aware of translations that are missing in my code (working so far). Besides that, disabling the check does not get rid of the error.
Define the supported configurations in build.gradle as described in this answer. I like this option (specifying languages instead of relying on translations available in the modules), but it also does something strange: I'm getting missing-translation errors for strings that are marked translatable = false.
For now, I'm downgrading again to the previous Gradle version. But what is the best apporach for fixing these build errors?
Hoping that there might have been corrections since I posted this question a few months ago, I checked the situation.
It seems that the issues were introduced with the Gradle plugin 2.3.0 and not Gradle 3.3 itself as I suggested in the question. Downgrading the plugin avoids the errors but can hardly be a long-term solution.
I found that option 3 in the question is the best way to handle it: add this to the app's build.gradle:
android {
defaultConfig {
...
resConfigs "en", "fr"
}
}
This is described in Googles documentation and, as mentioned, also in this answer. It removes all unnecessary resources - and the warnings/errors along with them.
Quoting the documentation:
The Gradle resource shrinker removes only resources that are not referenced by your app code, which means it will not remove alternative resources for different device configurations. If necessary, you can use the Android Gradle plugin's resConfigs property to remove alternative resource files that your app does not need.
For example, if you are using a library that includes language
resources (such as AppCompat or Google Play Services), then your APK
includes all translated language strings for the messages in those
libraries whether the rest of your app is translated to the same
languages or not. If you'd like to keep only the languages that your
app officially supports, you can specify those languages using the
resConfig property. Any resources for languages not specified are
removed.
The "false positives" (missing translation error for a non-translatable string) I got were for strings that were defined in more than one module. Renaming the strings or providing translations for them solved the problem. This, too, seems to be introduced with Gradle plugin 2.3.0.
In build.gradle add below code
lintOptions {
disable 'MissingTranslation'
}

Strange CLR compilation

So I'm doing this DirectX 11 project and had to use ...array<T>^ arr from the System header and I had to switch my Common Language RunTime Support settings to /clr. After fiddling with the other setting to get the project to compile I seem to have messed something up ,because now I cant use breakpoints and all the objects I have seem to not exist I dont know how else to put it. Please help.
Unless you need to work with .NET types, I'd recommend not using /CLR. Instead of using array<T>^, you can just use std::vector<T> and eliminate the dependency on the common language runtime.

Solution for missing std::wstring support in Android NDK?

I have a game which uses std::wstring as its basic string type in thousand of places as well as doing operations with wchar_t and its functions: wcsicmp() wcslen() vsprintf(), etc.
The problem is wstring is not supported in R5c (latest ndk at the time of this writting).
I can't change the code to use std::string because of internationalization and I would be breaking the game engine which is used by many games ...
Which options do I have?
1 - Replace string and wstring with my own string classes
This would give me better platform independency, but it is ridiculous to reimplement the wheel.
I've already started with a COW implementation of strings. I need it to be COW because I use them as keys in hash_maps.
This is of course lots of work and error prone ... but it seems it is something I can do.
2 - Try to fix the NDK recompiling the STLPort with my own implementations of the wide char string functions of the C standart library (wcslen, mbstowcs ... )
This would be the preferable way ... but I have no idea how to do it :(
How do I replace a function (lets say wcslen) in the libstdc++.a or libstlport_static.a? (not sure where they are :()
And as well I'm not sure which functions I need to reimplement, I know wcslen is not working so I guess they should be all ...
3 - Do you have any other idea?
I can't wait for an official fix for this and I will have to go with option #1 if I can't realize how to do #2.
I've read somewhere that if you target 2.3 you can use wstrings, but I ought to target Android 2.1.
PS: Forgot to say I need to use STL of course, but no RTTI and I can live without exceptions.
Thanks in advance!
Try out CrystaX's NDK. It has had stl support long before the official google one. The current version (r5), which is based off the of the official ndk r5, is still beta 3, but it does have wchar_t support.
http://www.crystax.net/android/ndk-r5.php
I'm suffering from the same problem as you, but my only other thought is to load the strings via the JNI (as jstring* in native land), then convert them to UTF characters as necessary. Take a look at the available JNI string functions here:
http://download.oracle.com/javase/1.5.0/docs/guide/jni/spec/functions.html#string_operations
Qt provides an excellent copy-on-write, international-friendly string implementation, QString, that is LGPLed.
You could, in theory extract it from the Qt source and use it in your own project. You will find the QString implementation in src/corelib/tools/qstring.h and .cpp in a Qt source download. You would also need the QChar, QByteArray, QAtomic, and QNamespace includes/classes (all under the corelib folder,) and you should define QT_NO_STL_WCHAR when compiling. (For this I would compile by hand or using my own script/Makefile.) Not simple, but once you get it up and running your life will be a lot simpler. It's better than reinventing the wheel, because it comes with loads of convenience functions and features.
Rather than stripping out just QString, you could also just use the QtCore module as a whole. See the android-lighthouse project for a Qt port to Android. (Also, it might be better to get your sources from there than from the above "vanilla" link, regardless of what you do.)

TitleCase In Visual C++

I'm currently trying to find an easy way to convert a Visual (Managed) C++ string to title case.
In VB.NET, you can use either:
StrConv(sampleString, vbProperCase)
or
sampleString = System.Globalization.CultureInfo.CurrentUICulture.TextInfo.ToTitleCase(sampleString)
In C# you use:
sampleString = System.Globalization.CultureInfo.CurrentUICulture.TextInfo.ToTitleCase(sampleString)
How do I do it in Visual C++? Is it something similar that I just can't seem to find?
Check the documentation on TextInfo.ToTitleCase it has examples for Managed C++
If you're talking about managed C++, you can use the same functions as in C#/VB.Net.
If you mean native C++, then:
Pretty certain there's nothing of the sort in the language itself.
AFAIK not in the Win32 API as well.
Your best hope then is to find such a function in some library (I personally can't think of one).

Resources