How to express lists in ICU - icu

I'm trying to get into ICU syntax and would like to be able to express
lists in the ICU message format.
For instance, given the data:
items:
- cool
- handy
- neat
I would like to be able to generate a messages like:
StackOverflow is cool, handy, and neat.
StackOverflow is cool and handy and nice.
ie. I would like to be able to define how to construct lists.
Is this at all possible within the ICU message syntax?

As far as I know, ICU message syntax does not support lists.
A potential workaround would be to check if your platform supports lists in their
localization implementation (e.g. Android) or to wrap that "list logic" into the ICU Select kind of message.
ICU Select message example:
{
type,
select,
comma {StackOverflow is cool, handy, and neat.}
and {StackOverflow is cool and handy and nice.}
other {StackOverflow is: cool, handy, and nice.}
}
Note, ICU messages can be clumsy and hard to maintain.
Some free online ICU editors can help you to easily check and validate them (e.g. DevPal ICU message editor).

ICU has a ListFormatter. You can use that separately and then include it as a string in the message format.
There is a new working group discussing the next generation of message formatting, and there is already an issue discussing list formatting.

Related

Passing filenames to python.subprocess across different platforms

I have a (cross-platform) script which invokes Excel/LibreOffice to open a file. Under Linux I don't have any problem, but with Windows there are problems when spaces are in the path of the file. This is a known issue, I've read quite some posts, but none seems to answer the specifics. Here is what I do:
subprocess.run([self.settings.excel, path])
The problem I end up with is the following: Excel complains that the file Your%20Preferred%20Path%20With%20Spaces cannot be found (obviously) although the parameter I give to subprocess isn't url-encoded like this.
So: who is garbaging my string ? Is it Excel, subprocess…?
I have found a workaround, using os.startfile, but it is not cross-platform. While having to execute different code according to the underlying platform may work as a patch, caring about so low-level details is hardly pythonic.
Therefore: what should I do to have a cross-platform, standard code solving this issue (and avoiding big libs like webbrowser if at all possible)? How could I build path so that it is passed to Excel in the expected format? 

How to use helm-semantic-or-imenu for code navigation with type annotated python code

I would like to use the helm-semantic-or-imenu command to navigate components of type annotated Python code, but whatever code analyzer is used to dentify the components doesn't seem to recognize the type annotated python code. Functions with the return type annotation doesn't get recognized at all and functions with annotated arguments show the type instead of the arguments names in the signatures
The main problem I have is that I do not properly understand the components that is involved in making this work (when it does work). Obviously it might help to somehow update the code analyzer, but in which project do I find that? helm? semantic? imenu? or as someone mentioned somewhere else with regards to code analysis python.el? I could really use some help getting started to solve this. If the code analyzer is found in python.el, can I then try to modify and make emacs use a local version preferentially over the installed one?
EDIT:
After making the initial post I finally made a break through in trying to figure out where the components come from. I searched for python*.el in all of the file systemsystem and discovered these:
./usr/share/emacs/26.2/lisp/cedet/semantic/wisent/python.elc
./usr/share/emacs/26.2/lisp/cedet/semantic/wisent/python-wy.elc
I found the source for emacs 26.2 and discovered that indeed it seems python-el is responsible for parsing python files for semantic. It also internally uses the python-wy for recognizing a large portion of the language components. But unfortunately that is where I hit a brick wall. I was hoping to be able to monkey patch the function that recognizes a function definition via an re or something, but semantic actually solves the problem the right way. So python-wy seems to be auto-generated from a formal grammar definition file (in emacs git admin/grammars/python.wy) and figuring out how to modify that it is unfortunately much beyond my abilities.
The semantic python backend doesn't appear to parse type annotations correctly (and there hasn't been much recent development on those libraries as far as I can tell). Since helm-semantic-or-imenu favors semantic when it is active, you can disable semantic altogether for python buffers unless you use its other features (personally I only use it for C/C++).
When the semantic mode-specific libraries are loaded they set imenu-create-default-create-index and imenu-default-goto-function, causing imenu to use semantic instead of python.el's imenu function.
To disable semantic support for your python files you can customize the semantic-new-buffer-setup-functions, only adding entries for modes you want semantic support for, eg. in your semantic hook (or alternatively with the customize UI),
(setq semantic-new-buffer-setup-functions
'((c-mode . semantic-default-c-setup)
(c++-mode . semantic-default-c-setup)
(srecode-template-mode . srecode-template-setup-parser)
(texinfo-mode . semantic-default-texi-setup)
;; etc.
;; (makefile-automake-mode . semantic-default-make-setup)
;; (makefile-mode . semantic-default-make-setup)
;; (makefile-gmake-mode . semantic-default-make-setup)
))

Duplicate protocol implementations in dependent projects

I have problems with consolidation of protocol implementation in my Elixir project. To be more specific I use Ecto and some simple project called Gold (doesn't matter much atm). The problem is, both of them (Ecto and Gold) use Poison to serialize Decimals (and implement proper Protocol).
Implementation for Ecto looks somewhat like this:
defimpl Poison.Encoder, for: Decimal do
def encode(decimal, _opts), do: <<?", Decimal.to_string(decimal)::binary, ?">>
end
During development there is a warning saying that the module is duplicated:
warning: redefining module Poison.Encoder.Decimal (current version loaded from /(...)/_build/dev/lib/gold/ebin/Elixir.Poison.Encoder.Decimal.beam)
lib/ecto/poison.ex:2
But when I try to use for instance exrm to build a release, then I get errors saying that I have duplicate_modules
===> Provider (release) failed with: {error,
{rlx_prv_assembler,
{release_script_generation_error,
systools_make,
{duplicate_modules,
[{{'Elixir.Poison.Encoder.Decimal',
gold,
"/(...)/rel/bitcoin_api/lib/gold-0.12.0/ebin"},
{'Elixir.Poison.Encoder.Decimal',
ecto,
"/(...)/rel/bitcoin_api/lib/ecto-2.0.2/ebin"}}]}}}}
How should I deal with this? The case here is I actually use my own version of Gold, so I can tamper with it to fix it asap. I know I can just add Ecto to Gold as a dependency, but that seems a bit overkill to just implement one Protocol like this. Isn't there some kind of a macro to check if a module has already been implemented?
A quick fix could be to wrap Gold's implementation in a Code.ensure_loaded?/1
unless Code.ensure_loaded?(Ecto) do
defimpl Poison.Encoder, for: Decimal do
def encode(decimal, _opts), do: <<?", Decimal.to_string(decimal)::binary, ?">>
end
end
Its a little icky but then you don't have to add Ecto, but just check if something else already pulled it in

What is imported using the Gjs imports statement?

If I'm looking at Gjs code and see this line near the beginning:
const Gio = imports.gi.Gio;
How can I know what methods, constants, events, etc. are on 'Gio' (without doing a Google search)? Is there a file somewhere on my installation that contains that information?
Obviously I'm asking for any 'imports' statement, not Gio specifically.
Some of imports statements import other javascript files:
imports.ui.* -> /usr/share/cinnamon/js/ui/*
imports.misc.* -> /usr/share/cinnamon/js/misc/*
imports.[cairo, dbus, format, gettext, jsUnit, lang, promise, signals] -> /usr/share/gjs-1.0/
For the imports.gi imports, Gnome Introspection is used to allow gjs to use C library.
So to get informations about those libraries I suggest you to look at the Gnome reference manuals:
Gio
Gtk
St
But to conclude, there is a huge lack of documentation and examples. That makes difficult to develop with gjs.
UPDATE
Here other useful links:
Seed documentation (seed is another javascript implementation for GNOME)
Gjs exemples
Since I got no answers I kept searching online and found this excellent blog post on how to generate HTML-formatted documentation from typelib files (such as Gio-2.0.typelib):
http://mathematicalcoffee.blogspot.com/2012/09/developing-gnome-shell-extensions_6.html

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.)

Resources