how to access translations from javascript

Hey, sorry if this is already documented but I wasn't able to locate the answer
I love your package and have been using it in my apps that use Laravel Blade
But now I am transitioning to using more and more Vue and I am finding myself needing to access these translated strings from inside the javascript
And I am wondering what is the optimal way of accessing what I need from a JS content. I am looking for a way that is not too hard on performance.. any advice would be much appreciated!
Thanks!

@vesper8, actually there is not an easy implementation at the moment.
I am sure it can be easily implemented by adding a JSON method to the translator web ui controller or to create a new controller to take in Laravel style translation keys and responding with the translations for these keys. This will allow getting translations in bulk instead of making a single request at a time.
Unfortunately at the moment I am swamped to implement this but will see if I can make time in the next few days to merge #110 and add this interface.
Since you are going to be using this do you have any preferences for the JSON protocol for this exchange?

Hello! Thanks so much for the super quick response!
I am still shocked that this repo has only ~100 stars! It should have thousands! I have tried a few other packages and yours has much better active development and complete functionalities.. and then there's this amazing support like in this issue!
Well to answer your question, I plan to use https://github.com/kazupon/vue-i18n which is by far the most popular localization package for Vue. It is able to handle some of the same features as your package.. but I prefer to use your package to manage all my translations and only use the vue-i18n package to load the json generated from your package and use it in the vue code
So basically.. I don't need anything special.. the vue-i18n package is capable of loading json files formatted like this:
en.json
{
  "test1": "English test 1",
  "test2": "English test 2"
}

So as long as you can export with this simple model then it should work fine!
Let me know if you have any other questions. Thanks!!

@vesper8, I think this would be addressed if the library implemented import/export of json style translations for Laravel. It could be the same issue as #104
I am going to make time to address. it has been outstanding for too long. I haven't used Laravel for a while and will need to brush up on the details of this feature.

@vesper8, thank you for the appreciation. For lack of library popularity I don't have an answer but suspect it has more to do with not caring enough about popularity to promote it.

hey @vsch
I could be missing something but it seems like this should be super easy to implement, considering that your package already outputs files which are almost exactly the format that is needed
For example, currently your package outputs
/resources/lang/en/locale.php
<?php

return [
    'en'    => 'English',
    'fr'    => 'Français',
];

All you would need to do is do the same thing but instead of writing a php array, you would wrap the php array with json_encode() and change the filename to json
and that would produce
/resources/lang/en/locale.json
{
  "en": "English,
  "fr": "Français"
}

And I could work with that. I actually prefer the ability to keep things separated in groups this way I can make a group which only contains translations that are needed in the javascript

@vesper8, the issue has never been generating or reading the files. That's a one liner, easier than PHP. The issue was the JSON keys which can be any old crap, of unlimited length, and not generally passable as a URL query param nor can be used in JavaScript for ID. Both of which are done in the code.
I implemented the changes by creating automatic old style translation keys for JSON imported files. These are put into the LTM table under JSON group. That is also where they show up in the Web UI. The mapping of LTM keys to JSON keys is stored in the LTM table under JSON group, json locale. That way import/export will correctly map JSON keys to translation keys and back.
On publish the JSON files are exported, and also a json.json file is output. This one saves JSON to LTM translation keys so that JSON keys could be efficiently converted to LTM keys for added functionality like usage tracking, missing key tracking and in database publishing for systems where translation files are read-only but there is a need to update translations.
For new keys, created in LTM, the JSON key will be taken from the translation value of the PRIMARY locale as configured in LTM config file. Failing that it will take the first translation value for any other locale.
I will push out a new version. Let me know what you find. I don't use Vue or javascript translations so don't have any real test cases to try.

@vesper8, its out. Please let me know if you encounter any issues.
PS. It was fun. I haven't worked in PHP or Laravel in almost two years. Took about 30 minutes to start remembering where things are but then it came back like I never stopped using it.

thank you so much for putting it out so quickly :)
I will be sure to let you know if I run into any problems using it.
I don't have time to implement it quite right away but will for sure be getting around to it within a few weeks tops
Glad you took pleasure in diving back into Laravel! Wow 2 years! Things have changed a bit since 5.2!
I wonder how you managed to make all those commits without ever needing to dive in!

@vesper8, most of the commits were either mechanical Laravel version necessitated changes for which I just followed the Laravel upgrade docs, or user submitted changes. I have been too busy to spend much time on this project beyond necessities.
As for the speed of this request, it was first requested in #104, last year so I cannot claim fast response on this. Your request showed why using this format was necessary. Since I did not follow the evolution of Laravel, I was not party to all the JavaScript integration.
No rush. I will be focusing on other work for a while and only addressing bugs that may come up.

Hey @vsch !
So I am finally getting around to using this!
I set up my vue-cli project to work with vue-i8ln and made it able to import files that look like this:
{
  "about" : "About"
}

Then I started populating my vue app with calls like these:
{{ $t('about') }}

Then I wanted to use pa translations:find to auto-populate the keys and here's when things got a little bit hairy
Well first of all I had to modify the vendor files because I could see no other way to make the translations:find command be modified for y needs
It would be nice if you could abstract
        $functions = array(
            'trans',
            'trans_choice',
            'noEditTrans',
            'ifEditTrans',
            'Lang::get',
            'Lang::choice',
            'Lang::trans',
            'Lang::transChoice',
            '@lang',
            '@choice',
            '__',
        );

and
        $pattern =                                  // See http://regexr.com/392hu
            "(" . implode('|', $functions) . ")" .  // Must start with one of the functions
            "\\(" .                                 // Match opening parentheses
            "(['\"])" .                             // Match " or '
            "(" .                                   // Start a new group to match:
            "[a-zA-Z0-9_-]+" .                  // Must start with group
            "([.][^\1)]+)+" .                   // Be followed by one or more items/keys
            ")" .                                   // Close group
            "['\"]" .                               // Closing quote
            "[\\),]";                               // Close parentheses or new parameter

and
$finder->in($path)->name('*.php')->name('*.twig')->files();

To the configuration file to allow for more flexibility
And it would be nice if there was a way to pass a path to the translations:find, but I saw that I could edit the paths inside the config/view.php file as an alternative, which is what I did
For now I changed the file to this:
        $functions = [
            '\$t',
        ];
        $pattern =                                  // See http://regexr.com/392hu
            '(' . implode('|', $functions) . ')' .  // Must start with one of the functions
            '\\(' .                                 // Match opening parentheses
            "(['\"])" .                             // Match " or '
            '(' .                                   // Start a new group to match:
            '[a-zA-Z0-9_-]+' .                  // Must start with group
            "([.][^\1)]+)+" .                   // Be followed by one or more items/keys
            ')' .                                   // Close group
            "['\"]" .                               // Closing quote
            '[\\),]';                               // Close parentheses or new parameter

        // Find all VUE files
        $paths = $path ? [$path] : array_merge([$this->app->basePath() . '/app'], $this->app['config']['view']['paths']);
        $keys = [];
        foreach ($paths as $path) {
            $finder = new Finder();
            $finder->in($path)->name('*.vue')->files();
            ...

Since this is what I need for my vue-cli app
I then ran pa translations:find and it found my keys
After a bit of trial and error I realized that in order to generate the json files, I need my keys to be in a JSON group (all caps). So I changed my keys inside my .vue files to:
{{ $t('JSON.about') }}

Which I found a bit redundant. I would have preferred to be able to use named groups so I could seperate my "nav" keys from my "article" keys. I kind of understand why you went through the extra trouble with how JSON keys are handled.. however I personally didn't need this and all my keys are going to be straightforward, short and not including any weirdness so what you did turns out to be an extra hurdle that wasn't really needed in my case at least.
After running it, this is what my fresh installation's ltm_translations table looks like:

Then after adding the translations through your GUI interface for English and French it looks like this:

And finally after hitting "publish all" or "publish group" it looks like this:

And here's the content of the 3 files it published:

I only need the en.json and fr.json however. I guess you need the json.json internally
In any case, I don't know what I'm doing wrong, but it didn't set any key at all as you can see. Even though in the database it shows all 3 rows to have 'about' set as the key.
As far as I can undertstand form what you wrote
For new keys, created in LTM, the JSON key will be taken from the translation value of the PRIMARY locale as configured in LTM config file. Failing that it will take the first translation value for any other locale.

It should have defaulted to the key 'about' ? Is this a bug that I've run into? Having to set the key manually in the DB is going to be tedious for 100s of translations so I'll wait for your answer
Can you tell me, would it be simpler (the intended way) for me to create regular groups (not JSON) and then somehow export those to JSON ? It's not clear how I can do that.. I was looking for some kind of "Export to json" button but couldn't find one.
Also I guess this is a problem now because I need to add $t('JSON.mystring') or otherwise $t('mygroup.mystring') in order for translations:find to locate my keys, but when I export it to json those keys won't work. Easy to fix with a find/replace but still.. I think I am not getting the proper workflow to do this efficiently so maybe you can chime in and let me know your thoughts.
Many thanks for your continued hard work on this!

@vesper8, thank you for such detailed feedback. I will go through your information thoroughly, but after a quick run through I have the following comment:
The JSON group is only needed for the translation manager. The json translation file keys are just text used in the primary locale to create the entry. On the LTM side I generate automatic unique keys for LTM use, based on the non-ltm key. I save the original key in the json locale so that I can correctly generate the json translation files and in case of re-importing files will re-use the same key, otherwise the database will be messed up with multiple keys for the same json entry.
That is what the json.json file is for. It allows to keep track of previously generated keys that should be re-used. If you delete that file then all the keys will be re-generated.
The json translation files are generated so that in Laravel they can be used without specifying the group, at least as far as I could tell. These files are generated with their original keys.

The vue t() requiring the group seems to be a requirement on the the vue side.

Is there an option to set default namespace? Is it not using i18next module? It is used with react and has this option for default name-space. If you set it to JSON then you will not need to specify it for every translation. Option for i18next would be defaultNS: 'JSON', it will automatically use that if the key has no NS in it. The default NS for i18next is 'translations'

I am using LTM translations in React but opted out for downloading the translations myself since I am learning react and wanted to understand the lower level stuff so I can make LTM work better with it.
I needed to learn react for a project. Creating an app from scratch, to understand the nuts and bolts of it, was easier and faster than trying to figure things out from an existing 12MB react project.
The React UI for LTM will probably released within a day. I expect some issues since I haven't figured out all the laravel mix, babel presets and how to configure it for a vendor package sourced assets. I'll probably just make a prod version and copy the files from my public to ltm package public. The view file is already generic so it should work.
The source I will add to the package but it will need config changes if someone wants to develop with it. I had to get some hacks in so I can use the bootstrap-xedit control. Modules  available for react are not fit to shine the boots of this barely supported and aging implementation. I could not see LTM without it.
Took some hacking but it works beautifully and the exercise forced me to understand react better.
I will go through the rest of your recommendations and don't see why they cannot be added to make life easier. It has been a long time since I used the find translations and I am sure "it could use a little attention".

Thanks for the explanations @vsch :)
No I'm not using i18next and I am lost as to what you mean about namespaces. I've also never used React but my understanding is that Vue is pretty similar. I'm not using any namespaces in the context of my translations inside my vue-cli app.
Just to be clear, my vue-cli front-end code is completely detached from my laravel backend, where LTM resides. They are not even in the same folder. As a result I also don't make use of Laravel Mix at all since I only use Laravel for the backend APIs. In order to have translations:find be able to search for keys inside my vue project I actually used a symlink since it's in another folder.
The reason I named my keys
{{ $t('JSON.about') }}

Is because translations.find has a regex requirement that all keys start with a group name. I could comment out those regex lines. But I also noticed that if the found keys are not part of the JSON group then there is no json files created when you publish.. instead it generates php files
The php files have proper keys, but the json ones do not as I detailed above.
I'm looking forward to your answers because I feel I may have encountered a bug or simply I am not understanding the correct workflow for using LTM exclusively for managing javascript translations
Thanks!

@vesper8, name-spaces in i18next terminology are groups in Laravel. Just a prefix separated from the key and you can configure how it is parsed. I suspect that there must be an option in vue for a default group.
The JSON files do not have proper keys because this is how Laravel expects it: https://laravel.com/docs/5.6/localization#using-translation-strings-as-keys
Can you make use of JSON translation files that you ajax from the server? The same way I am doing it for LTM react UI?

@vesper8, make the above JSON translations, not translation files.

I could potentially load the json files over ajax. However I have chosen to simply copy/rsync the compiled json files into my vue-cli app so that it can be included in the build bundle
also I'm not using json translations IN laravel.. in my particular case.. laravel is strictly an api and doesn't make use of any translations. I'm only using it to build the translation file themselves because I like using your package to do so
I'm sorry but I still don't understand how to use this. As you can see in my above screenshots, with the reproducible steps I've detailed, I end up with no keys for my translations which is not what I need.
If I manually set the value of the json locale row, only then are keys populated for my en.json and fr.json
Frankly I think there's a bug, I'm pretty sure that en.json and fr.json should never end up like they do in this screenshot

For new keys, created in LTM, the JSON key will be taken from the translation value of the PRIMARY locale as configured in LTM config file. Failing that it will take the first translation value for any other locale.

I don't think this is happening?

@vesper8, the key is taken from primary json file, which I assume is in your case is en. Laravel uses JSON files assuming that the key will be anything, but the default is that it is same as the primary translation. So that missing translations will return the key which is the default locale value.
You should have the en.json be:
{
     "About": "About"
}

fr.json
{
     "About": "À Propos"
}

Then your json.json will be:
{
     "About": "about"
}

The json.json converts the anything as key to LTM valid translation key.
Here is a set of small test files I use:
en.json:
{
    "a very long sentence for the key including some large % of ___nonaladf ja;lsdf fjas;lf jas;fl fl;jasf;ld l;j@@@J@$#$#%$#@#$@#$": "a very long sentence for the key including some large % of ___nonaladf ja;lsdf fjas;lf jas;fl fl;jasf;ld l;j@@@J@$#$#%$#@#$@#$",
    "a very long sentence for the key including some large % of ___nonaladf ": "a very long sentence for the key including some large % of ___nonaladf ",
    "new translation": "new translation",
    "new translation key": "new translation key",
    "test translation": "test translation",
    "un autre môt": "un autre môt",
    "новый ключ": "новый ключ"
}

fr.json
{
    "a very long sentence for the key including some large % of ___nonaladf ja;lsdf fjas;lf jas;fl fl;jasf;ld l;j@@@J@$#$#%$#@#$@#$": "une phrase très longue pour la clé, y compris certaines grandes % de ___nonaladf ja;lsdf fjas;lf jas;fl fl;jasf;ld l;j@@@J@$#$#%$#@#$@#$",
    "a very long sentence for the key including some large % of ___nonaladf ": "une phrase très longue pour la clé, y compris certaines grandes % de ___nonaladf",
    "new translation": "nouvelle traduction",
    "new translation key": "nouvelle traduction",
    "test translation": "traduction test",
    "un autre môt": "un autre môt",
    "новый ключ": "новый ключ"
}

json.json:
{
    "a very long sentence for the key including some large % of ___nonaladf ja;lsdf fjas;lf jas;fl fl;jasf;ld l;j@@@J@$#$#%$#@#$@#$": "a_very_long_sentence_for_the_key",
    "a very long sentence for the key including some large % of ___nonaladf ": "a_very_long_sentence_for_the_key_1",
    "new translation": "new_translation",
    "new translation key": "new_translation_key",
    "test translation": "test_translation",
    "un autre môt": "un_autre_môt",
    "новый ключ": "новый_ключ"
}

@vesper8, it sounds like you are not really using the JSON translations of Laravel so this is the reason why it does not work as you would expect.
The JSON translations for Laravel are really geared towards using the Laravel API, you are only copying them and trying to use them as regular i18n translation files.
In your use case json translation files should have normal translation keys, then LTM will generate identical keys and your whole json.json will have identity mapping. In this case you will have what you can use in JavaScript without issue.
Nothing in Laravel prevents you from doing this since there is no limitation on what can be a key in JSON.

This is getting complicated and I feel like we are not on the same page.
What I am looking for is something really simple.
Currently LTM is able to export a file such as
/lang/en/nav.php
<?php

return [
    'about' => 'About',
];

If the group is set to "nav"
ALL I'm really looking for is for a way to export that to
/lang/en.json
{
    "about": "About"
}

I'm beginning to think it may just be simpler to make a custom command that does this. But I thought this is what you had recently added, this is what I wanted all along
Currently the only way to achieve this is if my translations are part of a group called "JSON" in caps. And then this extra json locale row is created without a key and I need to add the key manually in the database otherwise it creates these files:
/lang/en.json
{
    "": "about"
}

/lang/json.json
{
    "": "about"
}

Now this doesn't look right at all to me.. how come neither of these files have a key!
Are you planning on adding/fixing it so that my straightforward use-case is able to be dealt with?
That would be fantastic

@vesper8, the blank key is a bug!.
I tried adding a new key to json translation files to match yours and it imports correctly and exports correctly.
It looks like your json.json file is out of sync with your translation files in the database and LTM failing to handle it properly.

Publish your JSON translation group from LTM so you have all the translations
Fix any keys that are blank in the JSON files so that these files are correct.
Delete the JSON translation group in LTM
Import All with (Only add new translations) option so the JSON files get imported. The keys should be fixed.

If you modify the JSON files manually, you will need to delete the JSON translation group and json.json file and re-import the translations until I fix LTM to handle discrepancy between files being imported and the database so that it will not get out of sync.
Or for now modify JSON translations only in LTM.

In the meantime this SQL query does the job of filling out the missing keys
UPDATE ltm_translations SET value=`key` WHERE locale='JSON' AND value IS NULL

The workflow is to
Publish All
Run the mysql command
Publish All
And then the en.json and fr.json are just what I need

@vesper8, yes this will fix the database corruption. I will need to fix the code to prevent it.
I think it happens if a key is added in LTM, which results in json locale to have empty translation which means the key is null. I will add code to set the json locale to the key when a key is created in LTM.
I will add this fix to the import and publish operations.

@vesper8, issue with JSON fixed. The cause was that I forgot to set the json locale keys when JSON group is being published. Until the group is published the keys remain empty.
React UI also released. It is the first incarnation but already quite good.

@vesper8, I made a new release without this function. It is simply a wrapper for Config::get('app.debug', false) for convenience with options to disable debug mode by using URL query params so I can test in a simulated prod environment. I replaced by config access.

@vesper8, its the expected issues I was talking about. The manifest for mix is missing from public directory for mix to know how to map:
file name: mix-manifest.json
Contents:
{
    "/vendor/laravel-translation-manager/js/index.js": "/vendor/laravel-translation-manager/js/index.js",
    "/vendor/laravel-translation-manager/css/index.css": "/vendor/laravel-translation-manager/css/index.css",
    "/vendor/laravel-translation-manager/js/index.js.map": "/vendor/laravel-translation-manager/js/index.js.map",
    "/vendor/laravel-translation-manager/css/index.css.map": "/vendor/laravel-translation-manager/css/index.css.map"
}

@vesper8, remove the map entries, they're for dev.
I have to check laravel docs to see how to merge vendor mix manifest, otherwise the UI has to be built on each client. I don't think it is the latter. There has to be a way to tell in the  webpack.mix.js that there are pre-built assets that need to be added to the manifest.

@vesper8, you can add the following lines to your webpack.mix.js to have LTM React files copied and added to the mix-manifest.json every time you compile your  assets:
mix.combine(['vendor/laravel-translation-manager/public/js/index.js'], 'public/vendor/laravel-translation-manager/js/index.js')
    .combine(['vendor/laravel-translation-manager/public/css/index.css'], 'public/vendor/laravel-translation-manager/css/index.css')
;

I'll update installation procedure for the next release, which should be soon. I am re-working a few parts of the UI and adding better auto view update when server ops are performed.

sounds good, thanks!!
Ok I guess one last detail that I'm not getting, the react-ui is loading now, but the translation file for the UI itself doesn't seem to be loading.. I just see messages.xxx everywhere
I do have the /resources/lang/en/messages.php
am I supposed to do something so that this is converted to usable json by the interface itself?

@vesper8, my bad, they are taken from the database. I forgot that not everyone has the LTM translations managed.
I'll fix it. There is no quick fix for it in the config.  Even if you add the vendor package to importable files it will still be vnd: while the code looks for wbn:
Thank you for taking the time and sorry for the hassle. I will fix this and make a new release.

@vesper8, actually there is a quick fix. The config is flexible enough.

In your LTM config, under language_dirs change the vendor entry to:

        'vendor' => [
            'include' => ['vsch/laravel-translation-manager'],
            'root' => '/vendor/{vendor}/{package}',
            'files' => 'resources/lang/{locale}/{group}',
        ],

        'vsch/laravel-translation-manager' => [
            '__merge' => ['workbench', 'vendor',],
            'db_group' => 'wbn:{vendor}.{package}::{group}',
        ],

Effectively, you are changing the vendor definition to include LTM and LTM definition to map its translations to wbn: prefixed instead of vnd:, LTM translations will show up as wbn:laravel-translation-manager.messages,

Import all to import ltm messages and it will show the messages in the React GUI.

I am in the middle of some code changes and this is the quickest way to get around the issue.

Thanks for trying to get a quick-fix going.. but I can wait until your next release I think.
Anyway I did try your suggestions. First, the mix.combine is missing the 'vsch' in the path, so it should be like this:
mix.combine(['vendor/vsch/laravel-translation-manager/public/js/index.js'], 'public/vendor/laravel-translation-manager/js/index.js')
    .combine(['vendor/vsch/laravel-translation-manager/public/css/index.css'], 'public/vendor/laravel-translation-manager/css/index.css')
;

Then npm run dev works well and adds the files to the manifest.json
Just a note that it's not possible to run npm run prod because it complains about being unable to minify the index.js, it suggests using mix.babel instead and then complains about a missing transform-vue-jsx plugin
I then made the modifications to the config file and added the entries you noted above.
I then performed an 'import all'
And it added two new groups.

The 'vnd' group has all the entries populated, but the 'wbn' group has all the entries empty (no translations). As for the interface.. it still displays 'messages.xxx' everywhere

@vesper8, I will be making a release today with the fixes.

@vesper8, new version released. Now the React UI translations work like all other translations.
Added instructions to how to configure it for mix. use mix.copy instead of combine. https://github.com/vsch/laravel-translation-manager/wiki/React-App-UI
You should remove the config lines added for LTM translations and delete the group from the LTM database so it does not override the LTM package translations.

@vsch almost there now I can feel it!
What do you mean remove the config lines? you mean the ones you suggested earlier? I reverted to the package's configuration so I undid all those workaround fixes if that's what you meant
What do you mean remove the group from the LTM database?
I'm noticing now that if I truncate both the ltm_translations and ltm_user_locales table then the React UI loads fine with no errors in the console or under the Network tab
But if I leave my JSON translations in ltm_translations then everything blows up
The user-list, summary and trans-filters API endpoints all go red with errors
I thought the problem might be the json locale so I removed those rows.. but that doesn't fix the problem.
How can I keep using my hundreds of translations I had before? They are all under the JSON group
Lastly, the mix.copy trick works well, but using mix.react throws the same error as before with a missing plugin

I tried to start over to see where that would lead. I truncated both tables. Then I ran the pa translations:find command again, with my customizations from my PR
And it found 58 keys and added them to the table, under the group "JSON" since all my keys are named JSON.something
But now this group won't appear anywhere in the interface like it did before
Basically is there a new workflow for managing json translations now?

@vesper8, no new work flow. I try to keep that unchanging. It sounds like there is a bug. See below.
I use JSON in my test setup and not getting the exceptions but that is because my JSON content is contrived and does not represent what is possible. No truncation should be done or acceptable. It sounds like in my setup I am missing something that causes a bug in your setup.
Q: Can you make your JSON translations available so I can add them to my translations and have the same data. It also could be config
Reply to points raised in your comment:

Yes

What do you mean remove the config lines? you mean the ones you suggested earlier? I reverted to the package's configuration so I undid all those workaround fixes if that's what you meant

You no longer need to have LTM translations in the database which was the reason for 1.

What do you mean remove the group from the LTM database?

You should not have to truncate your translations. I never clear my table, only run migrations. I have all the usage information in the tables which I don't want to loose.

I'm noticing now that if I truncate both the ltm_translations and ltm_user_locales table then the React UI loads fine with no errors in the console or under the Network tab

But if I leave my JSON translations in ltm_translations then everything blows up

The user-list, summary and trans-filters API endpoints all go red with errors

I thought the problem might be the json locale so I removed those rows.. but that doesn't fix
the problem.

How can I keep using my hundreds of translations I had before? They are all under the JSON
group

Lastly, the mix.copy trick works well, but using mix.react throws the same error as before with a missing plugin

The copy should be done in your project's webpack.mix.js. You don't need to run the vsch/laravel-translation-manager webpack.mix.js
The copy should just copy the compiled assets from the vendor directory. Are you getting these errors just by including the mix.copy lines to your webpack.mix.js?

@vesper8, what groups and locales do you have in your database?
JSON locales?
Non JSON locales?
I think it is a lack of data or something unexpected (not wrong, just not expected by the code) in the data that is causing the bug to be triggered.

I only touch my own webpack.mix.js not the vendor's one
mix.copy(...) works perfectly and that's all I need really.
I was just saying that adding mix.react(...) does however fail, because of a missing plugin
Here's a dump of my ltm_translations which is causing the issues
https://www.dropbox.com/s/m5lf7pawpbkgik8/vue-translations.sql?dl=1

@vesper8, I am able to duplicate a whole bunch of errors on my system. Thank you for the files. I'll have it fixed shortly.

@vesper8, fixed a couple of bugs that prevented display but not sure if this is what is causing issues on your system. It could be.
Your files helped me debug the show source feature. Mine don't have any sources so that feature was broken too.
Thank you very much for taking the time to help resolve these issues.
Please let me know if this version has any issues or whether the same problems persist.
If there are upgrade issues In the future, please let me know. You should not have to truncate any data to try and make LTM work. The upgrade procedure has to handle that.

no problem @vsch
Unfortunately I'm still having problems
So I just ran composer update and updated to 2.6.22
Then I restored my vue-translations.sql
So my ltm_translations has all my previously working translations and my ltm_user_locales is blank from being previously truncated)
I accessed /translations and there was simply no group.. I figured maybe this is a cache issue
So I clear my laravel cache.. and then try to access /translations again and this time I get the same error I've seen earlier
ErrorException: Undefined offset: 0 in file /DEV/_POC/new.classementpoc.com/vendor/vsch/laravel-translation-manager/src/Classes/TranslationLocales.php on line 80

From here.. if I truncate both tables.. clear cache/view/everything
I am still getting the above error.. can't access neither the old /translations or /translations/ui anymore
if I dd($userTranslatableLocales) on that line that's crashing I get
$userTranslatableLocales array (1)
⇄1 => string (2) "fr"

Maybe this is the part that I forgot to mention, which is that the only one change that I make to the default configuration file, besides adding my Yandex_key is that I add 'fr' to
    'locales' => [
        'en',
        'fr',
    ],

This seems to be causing these issues somehow? why? am I not supposed to do that? english and french are the two languages I care about and want to manage translations for

so for kicks I removed 'fr' from the locales in the config file (this is with my ltm_translations still blank) and then I was able to access the UIs
but then I restored my vue-translations.sql once again
And then I'm getting the error again
if I print out the array as above now I'm getting
$userTranslatableLocales array (2)
⇄1 => string (2) "fr"
⇄2 => string (4) "json"

This is with my configuration locales only containing 'en'

@vesper8, it definitely is an issue with the calculation of user translatable locales and display locales. I try to put the locales that are part of the working set at the head of the locale list.
I can see where the first exception is caused. I will load your tables and set the config locales to what you have. That way I will be able to duplicate your system. Once I can do that, fixing the bug is a cake walk.

@vesper8, locale only adds locales that you want to have even if there are not translations in the table for that locale. ie. it is a minimum list.
show_locales is a maximal list. Only locales from this list will be shown.
What is your primary locale, the one you work with as the source to translate? en I assume.

@vesper8, new version pushed. It was my mixing Java, JavaScript and PHP. In PHP array diff does an associative diff on the keys, even if it is an indexed arrays. So entry [0] may be removed and first element starts at [1].
Your config was necessary to have the issue arise.
I am leaving your translations until you confirm its working for you.

wheee! Finally!! it all works good now!! hooray
now if you could get around to merging my PR so I don't have to modify the vendor code every time you make an update :)
Otherwise I think you can finally close this issue!

ooh no.. boo.. I spoke too fast
almost perfect! But the same problem with the missing JSON keys is still happening
I ran translations:find just now and it found 1 new key
I entered the value for English, and then French.. and then I clicked publish
And it did the same thing as before, where it published it with an empty key in the en.json and fr.json
And inside the json.json file there's also no key, just like before

ahh.. but if I publish again.. then it properly filled it
so no big deal.. just gotta publish 2x in a row

you know there's just one more annoyance that i'm dealing with
in order for translations:find to work.. I've had to name all my keys as JSON.something
but then when I publish this, it creates a file that looks like this:
{
    "about": "About"
}

But what I actually need is for the file to look like
{
    "JSON": {
        "about": "About"
    }
}

Right? Otherwise I have to hack it.. I've been manually editing the files but it gets tedious
Honestly what I would really like is to have group support like LTM normally has.. for php translations.. and not be forced to use a group called "JSON"
Instead I could have a group called "nav" and "ads" and "whatever", just like normally
And then there'd be a button to "export to json"
And what this would do is it would concatenate all my groups into a single en.json that looks like this:
en.json
{
    "nav": {
        "about": "About",
    },
    "ads": {
        "buy": "Buy",
    },
    "whatever": {
        "whee": "Hooray"
    }
}

And then I'd really be in heaven

@vesper8, the issue is that JSON support is made for Laravel JSON files which dictates how the files are named and laid out. Your use case is for vue to use laravel files.
I still don't understand why do you need to specify JSON if vue cannot use Laravel translation files and therefore the group names make no sense. It always grabs the default JSON translations. You should be able to specify just the key.
What needs to be done in your case is a service to take the translations and massage them to your format on publishing. Including translations in the PHP files. Then out of the box you can use all the php translation groups and not have to worry about JSON group at all because it would be generated from the php groups.
The WebUI generates a TranslationsPublished($group, $errors) event after publishing a group or all groups (group is '*' for all groups).
On getting that event you should generate your translation files. They are easy to manipulate since they are nothing but associative arrays. Then you json_encode() your assoc array  and write it out to the file for the locale.
With that implementation you can plugin vue javascript into a laravel project and have all the existing translations available for it. It would probably be easier to write this code than to keep manually modifying the file.
I cannot make this conversion standard part of LTM because then it would generate JSON files that Laravel cannot use.

Ok.. I might do that
It's not vue that requires this format.. rather.. it's your own translations:find that requires that keys follow the pattern of group.keyname
I tried modifying the default regexp so that it didn't require a group, but then it failed at some later point which I didn't investigate
I'd be happier not having to name all my keys JSON.keyname

@vesper8, if you explained yourself earlier we might have found a better solution.
BTW, Its not my find since I only cleaned it up originally to have less false positives and gave up when I realized that it is not reliable. Now that i merged your PR its more like your find. ;)
The issue with find is that it needs to be constrained otherwise it will trigger on so many false positives you will get tired of deleting them from the database. I got tired of even the improved version and haven't looked at that code it in years. Until it was brought up by you, I forgot it existed.
I don't use it because it misses dynamic key use, which I do a lot. I tend to define things like dialog or message box type translations with a unique key for id, then add -title, -footer, -message,  etc. for the different parts of the dialog/message/email. That way to display the information I only need the id and can get the other parts by adding standard suffixes. Hence, the add suffixes button in suffixed keys. It allowed me to quickly create the relevant new keys.
Then I added Missing Key tracking to eliminate key creation all together. My workflow is to create and use translation keys in the code. Display the view, e-mail, etc, once to trigger use of new keys. Then go into LTM and add translations to all the missing keys. The overview shows all groups with missing translations. All these features were added to avoid having to use find.
BTW, the primary locale I fill in with auto-fill, it helps if the keys are relevantly named. Then auto-fill will be close to the desired content 80% of the time. The rest I auto-translate and massage.
In my JavaScript code I intercept missing key event from i18next and accumulate missing translations. Then pump them after a short delay to the server. I also trigger a refresh of the translation table if the group being displayed is the one triggering the missing key event. So I don't even need to refresh the table. Just trigger the GUI with new translations and they appear in my table. In your case you would need to refresh the translation table since your app is running separately but accumulating missing keys and sending them to the server would probably be better and easier than trying to perfect find. It also means that any translations that were not caught by find will at least be caught when you run the app.
It is a 100% fool proof method of getting keys you create during development. It will not add keys that you did not translate but since you are developing you need to try the code at least once so it takes care of the new keys.
It is something to consider implementing then you won't need find and can use whatever keys as Laravel JSON files allow. I am going to fix the empty keys in the code. So that created missing keys will not be an issue.

hrmm.. really interesting how you intercept missing keys.. although I'm not sure how you do that exactly.. an example would really help.. how does triggering a view or an email once trigger the interception of untranslated keys exactly?
in my case the find command will always work perfectly since all my translation keys are wrapped either in either of these patterns:
$t('JSON.somekey')
i18n.t('JSON.somekey')
this.$i18n.t('JSON.somekey')

depending on scope
And my find settings are:
    'find' => [
        'functions' => ($functions = [
            '\$t',
            'this.\$i18n.t',
            'i18n.t',
        ]),
        'pattern' => [                              // See http://regexr.com/392hu
            '(' . implode('|', $functions) . ')',   // Must start with one of the functions
            '\\(',                                  // Match opening parentheses
            "(['\"])",                              // Match " or '
            '(',                                    // Start a new group to match:
            '[a-zA-Z0-9_-]+',                       // Must start with group
            "([.][^\1)]+)+",                        // Be followed by one or more items/keys
            ')',                                    // Close group
            "['\"]",                                // Closing quote
            '[\\),]',                               // Close parentheses or new parameter
        ],
        'files' => [
            'vue',
            'js',
        ],
    ],

So it's pretty much impossible for false-positives to be returned. I'm confused how it is that translations:find was getting false-positives in your case since I assume all of your translations are also always wrapped in translation methods that are easily picked up by the regex in the find manager
Anyway in my case it works well enough that I don't have a need for the keys to be preceded by a GROUP.
I tried to comment out the part of the regex that requires the key to be preceded by a group but I think I just didn't do it properly.. I'll try again. However I wonder what will happen if the find command finds keys that have no group.. what group will they be added to in that case? I'd still need for that group tbe "JSON" if I want these to be exportable to json
I'm still confused about why this is a requirement and why you can't just "export any group to JSON" even if the group is called something else
Anyway in the meantime using the TranslationsPublished event sounds like a good enough solution!

I'm trying to use the TranslationsPublished event now. I've created a listener and it's working, but the $event only contains the group, in this case "JSON".
I tried looking into your export function to see if I could reuse it in a way that would let me manipulate the structure.. but I decided that was not very easy.. instead I quickly put this together which is a bit hacky and very specific to my use-case but it works
<?php

namespace App\Listeners;

use Vsch\TranslationManager\Models\Translation;
use Vsch\TranslationManager\Events\TranslationsPublished;

class TranslationsPublishedListener
{
    /**
     * @param Vsch\TranslationManager\Events\TranslationsPublished $event
     */
    public function handle(TranslationsPublished $event)
    {
        if ($event->groups === 'JSON') {
            $locales = [
                'en',
                'fr',
            ];
            foreach ($locales as $locale) {
                $translations = Translation::where('group', $event->groups)
                    ->where('locale', $locale)
                    ->get()
                    ->pluck('value', 'key')
                    ->toArray();

                $translations = ['JSON' => $translations];

                \File::put(base_path("resources/lang/{$locale}.json"), json_encode($translations, JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE));
            }
        }
    }
}

@vesper8, in your case you don't dynamically generate the translation key. I do that a lot in my code. In your case you don't need the group just have to double check the find command to make sure it does not filter out any references that do not have  a group.
As for missing keys, it is any translation that equals its key:
Translator.php
This is the reason I love having code I can modify.

I'm still confused about why this is a requirement and why you can't just "export any group to JSON" even if the group is called something else

JSON group in Laravel has special handling and so in LTM. The location of translation files are in locale subdirectories, for JSON in files named with the locale. So for Laravel there is only a single group with JSON translations. No group resolution if using _() translations for JSON. Only keys are specified. At least according to the docs. I don't use this function.
Now it is possible to export any group but then it would still be just one group so there is no reason to call it or not to call it JSON. In your case the only reason you call it JSON is because this is how you extract the keys from source and how you tweak the output files for i18n. It is not an LTM requirement.
I am doing major clean up of Manager code. I have been hacking at it with little tweaks trying to disturb as little as possible. Plus some original recursion in publish code that I have hated since the beginning and finally today I had enough and decided to clean up.
Too many condition plus recursion made it impossible to understand. Now it is more straight forward. Also cleaning up handling of JSON key generation on export. Already no blanks and there is a setting to turn off any garbage as json key so for new keys it will export LTM keys when this mode is set.
Also, now any missing keys get added with whatever key is being used. So export will use the correct key for JSON.
I'll probably release it some time today/early tomorrow. Want to make sure nothing in the import/export is broken first. I could really use having unit tests but I don't have to maintain the code much less write tests for it.

@vesper8, in Translator::getTranslations Translator.php
Takes namespace, which for Laravel means vendor package, group and locale and returns an assoc array of key to translation.
You can get any translations from there. I added this function, which is protected in Laravel translator, so I can get LTM translations for React. You can use that too. Then the translations you are looking for don't need to be in the table.
Nothing wrong with a hack that solves a problem. All of LTM started out mostly as hacked features I needed to address immediate needs then evolved into something that I find hard to believe I spent time creating. ;)

@vesper8, new release is out. Stick a fork in me. I'm done. I think it is all fixed. Just realized that I forgot to add your PR to the version notes. Sorry. It'll be there next git push.

Add: config options for customizing JSON translation key generation: You want the first option set to false. They keys will be LTM by default.
/**
 * Set to true to have newly created JSON group entries get primary locale translation string as their key
 * false for having new keys default on export to ltm key. true by default
 *
 * @type boolean
 */
'new-json-keys-primary-locale' => true,
/**
 * What character to use for separating words in json generated keys. Only first char is used.
 *
 * @type string
 */
'new-json-keys-separator' => '-',

If you have no objections, I will keep your translations in my database so I have some real JSON to test against. Let me know if it presents a problem and I'll ditch them.

@vesper8, what I was referring to is the name used in LTM for Laravel JSON translations. Outside of LTM the group name JSON has no significance and does not appear anywhere in the use of JSON translations.
Laravel JSON translations have no group name and are stored in lng.json files where lng is the locale of the translations.
LTM gives a fixed name to these translations so that they fall in line with LTM expectation of all translations being associated with a group. The choice of this group has no effect on any code using Laravel translations. Only code that deals with translations through LTM internal API.
Your use of JSON in your code is independent of the JSON group name in LTM. This is what I was referring to when I said it could be anything. You can make that anything you want. Access to other Laravel groups is done through Laravel API and whether they can be accessed through JavaScript or not is dictated by Laravel. Including making these groups available in JSON format.
However, conversion from PHP to JSON is a simple matter of loading the translation file and json_encode() and save it in a new or the same location.
If you would like to see standard Laravel translation files also saved in a JSON format then this is something that can be easily added via a configuration item. Something like publish_include_json with an array of group names.
However, the export of these JSON files would be one way. To have JSON files used in import is also doable but more complex and would require code changes. It would also make import use only the JSON file and ignore PHP on import. Export would still export both formats.


cmd/compile: binaries contain many ..type.eq funcs

We have a meta bug for binary size (#6853), but as one specific item:
Go binaries contain many ..type.eq funcs to support == on types at runtime.
The compiler & linker could probably omit provably unneeded ones. Or even do some with slower reflect if they're large & unlikely to be needed at runtime.
Background:

https://twitter.com/bradfitz/status/1255704982893912064,
https://go-review.googlesource.com/c/go/+/231118 (http)
https://go-review.googlesource.com/c/net/+/231119 (http2)
https://go-review.googlesource.com/c/go/+/231239 (runtime)

In https://go-review.googlesource.com/c/go/+/191198 I did a similar thing for hash functions. Only the ones we know are needed are generated. The rest are done reflect-like inside the runtime.
The slowdown wasn't too bad (20%) and it saved a lot of binary size (1%). The nice thing about maps is we know most of the hash functions we need, as interface-keyed maps are the only exception and they are fairly rare (rarer still, non-pointer interface keys). It's less clear for == because those comparison functions are used in more places.

I saw some [x]interface{} algs in @bradfitz tweet which may be created as part of variable functions.
We might have a few places left were we create algs for compiler generated arrays. I should do a pass to find out and then close the issue: https://github.com/golang/go/issues/28639

I tried to noalg slice backing store arrays, but trybots didn't like me:
https://go-review.googlesource.com/c/go/+/151497
Never got around to figuring out why.

I tried to noalg slice backing store arrays, but trybots didn't like me:
https://go-review.googlesource.com/c/go/+/151497
Never got around to figuring out why.

I think the reason is the same as https://github.com/golang/go/commit/343b7fa6261a5b0ceaafed535438249ffa5686de


Webpack seems to want to resolve devDependencies of modules in node_modules when target is "node"

Do you want to request a feature or report a bug? Bug

What is the current behavior? When attempting to bundle a module from node_modules, webpack attempts to resolve the modules listed in that packages devDependencies, and since devDependencies aren't included when installing a package, the resolution fails
If the current behavior is a bug, please provide the steps to reproduce.

https://gist.github.com/rossipedia/69d434e281cd466a06fbd826d2aa5774
What is the expected behavior?
The module and it's runtime dependencies are included in the bundle, but not the devDependencies
If this is a feature request, what is motivation or use case for changing the behavior?
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
Windows 10
NodeJS v7.7.2
Webpack v2.2.1
Less v2.7.2

What exactly are you expecting? I dont fully understand I think.
If your bundle needs devDependencies they are no devDependencies?

@rossipedia Node doesn't care where dependency is declared. It looks into node_modules folder. Dependency even can be declared nowhere. Webpack behaves in the same way. Adding restrictions will affect for example test cases which use devDependencies and won't be run on install. It's all developer responsibility.

webpack doesn't read devDependencies nor dependencies. If you don't install your dependencies it doesn't work. Just like node.js.

That was my understanding as well, but it doesn't explain the behavior. Webpack is failing with an error because a package that is only listed in less's devDependencies can't be found.

This message in particular would lead me to believe some parsing of package.json is going on:
resolve 'time-grunt' in 'C:\code\scratch\node_modules\less'
  Parsed request is a module
  using description file: C:\code\scratch\node_modules\less\package.json (relative path: .)
  after using description file: C:\code\scratch\node_modules\less\package.json (relative path: .)
    resolve as module


chore: fix missing deps in CI

Which issue does this PR close?
Closes #
Rationale for this change
Protobuf is required in CI.

What changes are included in this PR?

Are there any user-facing changes?

How does this change test

CI itself.

Codecov Report

Merging #603 (cc0cfd6) into main (2306aac) will decrease coverage by 0.08%.
The diff coverage is 49.30%.

:exclamation: Current head cc0cfd6 differs from pull request most recent head af1b0d6. Consider uploading reports for the commit af1b0d6 to get more accurate results

@@            Coverage Diff             @@
##             main     #603      +/-   ##
==========================================
- Coverage   66.07%   65.99%   -0.08%
==========================================
  Files         284      285       +1
  Lines       43799    44342     +543
==========================================
+ Hits        28938    29262     +324
- Misses      14861    15080     +219

Impacted Files
Coverage Δ

server/src/grpc/mod.rs
0.00% <ø> (ø)

server/src/grpc/storage_service/mod.rs
41.42% <0.00%> (ø)

server/src/grpc/storage_service/write.rs
38.99% <0.00%> (-3.67%)
:arrow_down:

server/src/handlers/sql.rs
0.00% <0.00%> (ø)

server/src/http.rs
0.00% <0.00%> (ø)

server/src/mysql/worker.rs
0.00% <0.00%> (ø)

server/src/server.rs
0.00% <0.00%> (ø)

sql/src/partition.rs
0.00% <ø> (ø)

server/src/handlers/prom.rs
68.11% <68.11%> (ø)

sql/src/parser.rs
89.49% <92.30%> (+0.26%)
:arrow_up:

... and 5 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Add option to set report title in cmd mode

This adds an additional command-line option -cmd-title which allows to
overwrite the default title (i.e. dashboard name). Depending on the dashboard
naming scheme, or the particular time-range of the report, the user might want
to set a custom title (like `Daily report for...') without having to use custom
templates.

Thanks for this. It looks like it is also available as a query parameter? I would not like an option to be only accessible from the cmd line.
If it is could you did not add it to the query parameters section of the readme?
Also is there any automated test that one might think of for this? E.g. here to test the url parsing and here to verify that the custom title is correctly passed through to the generated report?
If you add these I would gladly accept the PR.


NTR: selenium supplementation and selenium avoidance

Keshan disease
Kashin-Beck disease PMID: 27171069

Added new terms


Mark support for isEmpty and notEmpty

Powered by both https://github.com/phpstan/phpstan-src/pull/1317 and https://github.com/phpstan/phpstan-src/pull/1781 🎉

Thank you!


Update to esri-loader 2.5

Quick fix to update the esri-loader dependancy to the newest version.
#59

Thanks @NindroidX!


[Panic] index out of bounds

I just experienced a reproducible crash. This seems to be caused by the combination of +D and -D212; it also prints the following warning: 'one-blank-line-before-class' (D203) and 'no-blank-line-before-class' (D211) are incompatible. Ignoring 'one-blank-line-before-class'.

Command: ruff --select D --ignore D212 src --fix
Backtrace:thread '<unnamed>' panicked at 'index out of bounds: the len is 29 but the index is 29', crates/ruff/src/source_code/locator.rs:83:9
stack backtrace:
   0:        0x10d897cfa - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h521420ec33f3769d
   1:        0x10d2cc20a - core::fmt::write::h694a0d7c23f57ada
   2:        0x10d894a5c - std::io::stdio::_eprint::hce138c1c2856ce51
   3:        0x10d897aca - std::time::Instant::elapsed::h513af9279b3b413c
   4:        0x10d89bf93 - std::panicking::default_hook::hfeeab2c667b2d7c2
   5:        0x10d89bcf7 - std::panicking::default_hook::hfeeab2c667b2d7c2
   6:        0x10d526270 - <regex_syntax::hir::HirKind as core::fmt::Debug>::fmt::ha120f21aa78097c1
   7:        0x10d89c697 - std::panicking::rust_panic_with_hook::h1b5245192f90251d
   8:        0x10d89c435 - <std::panicking::begin_panic_handler::StrPanicPayload as core::panic::BoxMeUp>::get::h9f4a61dc8b1a8670
   9:        0x10d89a8e8 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h521420ec33f3769d
  10:        0x10d89c142 - _rust_begin_unwind
  11:        0x10d922713 - core::panicking::panic_fmt::h0097ad8ec0b07517
  12:        0x10d922856 - core::panicking::panic_bounds_check::h1c89633b3be15e5a
  13:        0x10d7036e8 - <ruff::source_code::indexer::Indexer as core::convert::From<&[core::result::Result<(rustpython_compiler_core::location::Location,rustpython_parser::token::Tok,rustpython_compiler_core::location::Location),rustpython_parser::lexer::LexicalError>]>>::from::h495512723e7b0d12
  14:        0x10d703ce8 - ruff::source_code::locator::Locator::slice::h8cda49452a10e3a1
  15:        0x10d64e55c - ruff::linter::lint_fix::h4a770bbd14b0f19a
  16:        0x10d51025a - <regex_syntax::hir::HirKind as core::fmt::Debug>::fmt::ha120f21aa78097c1
  17:        0x10d49ffaa - <regex_syntax::hir::HirKind as core::fmt::Debug>::fmt::ha120f21aa78097c1
  18:        0x10d457931 - <regex_syntax::hir::HirKind as core::fmt::Debug>::fmt::ha120f21aa78097c1
  19:        0x10d4a0d67 - <regex_syntax::hir::HirKind as core::fmt::Debug>::fmt::ha120f21aa78097c1
  20:        0x10d457a75 - <regex_syntax::hir::HirKind as core::fmt::Debug>::fmt::ha120f21aa78097c1
  21:        0x10d4a0d67 - <regex_syntax::hir::HirKind as core::fmt::Debug>::fmt::ha120f21aa78097c1
  22:        0x10d457931 - <regex_syntax::hir::HirKind as core::fmt::Debug>::fmt::ha120f21aa78097c1
  23:        0x10d4a0d67 - <regex_syntax::hir::HirKind as core::fmt::Debug>::fmt::ha120f21aa78097c1
  24:        0x10d457931 - <regex_syntax::hir::HirKind as core::fmt::Debug>::fmt::ha120f21aa78097c1
  25:        0x10d4a0d67 - <regex_syntax::hir::HirKind as core::fmt::Debug>::fmt::ha120f21aa78097c1
  26:        0x10d4cff25 - <regex_syntax::hir::HirKind as core::fmt::Debug>::fmt::ha120f21aa78097c1
  27:        0x10d92b35a - rayon_core::registry::WorkerThread::wait_until_cold::h38f60dff60493700
  28:        0x10d3f0df7 - rayon_core::registry::ThreadBuilder::run::hd4e0e31ddec10142
  29:        0x10d3ee002 - <quick_xml::events::attributes::AttrError as core::fmt::Debug>::fmt::ha945229a9a8fc49b
  30:        0x10d3ef36e - <quick_xml::events::attributes::AttrError as core::fmt::Debug>::fmt::ha945229a9a8fc49b
  31:        0x10d8a0319 - std::sys::unix::thread::Thread::new::h135242531a117d11
  32:     0x7ff813b49259 - __pthread_start

ruff.toml:select = [
    "E",
    "F",
    "I002",
    "N",
    "UP",
    "PTH",
    "COM",
    "RET",
    "T",
    "S",
    "INP",
    "TCH",
    "SIM",
    "G",
    "ISC",
    "TRY",
    "DJ",
    "ARG",
    "PLW",
    "DTZ",
    "EM",
    "SLF",
]

ignore = [

    # S101: Assert usage
    # Not using assert is just bogus advice.
    "S101",

    # S104: Possible binding to all interfaces
    # We're running in Docker, where binding to all interfaces is explicitly
    # desired behaviour.
    "S104",

    # S324: Probable use of insecure hash functions in `hashlib`: `sha1`
    # We don't use SHA1 for confidentiality purposes, so this is okay.
    "S324",

    # PLW2901: `for` loop variable `<variable>` overwritten by assignment target
    # When applied judiciously this can make sense.
    "PLW2901",

    # TRY003: Avoid specifying long messages outside the exception class
    # Effectively, this suggests to create custom exception classes for every
    # possible error. This makes sense, but doesn't add much value now.
    # TODO: Revisit this decision
    "TRY003",

    # D100-D104: Existence of doc comments for public code
    # Again, this makes sense, but doesn't add much value now.
    # TODO: Revisit this decision
    "D100",
    "D101",
    "D102",
    "D103",
    "D104",

    # D212: Multi-line docstring summary should start at the first line
    # This just makes the comment harder to read.
    "D212",

    # DJ001: Avoid using `null=True` on string-based fields such as CharField
    # We have a reason to make a distinction between "" and NULL, so this is OK.
    "DJ001",
    "DJ008",

    # RUF100: Unused `<directive>` directive (non-enabled: `<rule>`)
    # These are usually signs of progressive enhancements and should not crash
    # the commit or build.
    "RUF100",

    # SLF001: Private member accessed: `<member>`
    # As we have properties in the index prefixed by a dash, we have to use
    # those names in attrs accessors. Hence, this is not a bug for 99% of cases.
    "SLF001",
]

[per-file-ignores]
# Imports are organized differently in the settings modules. This is important
# and should not be changed.
"src/sia/settings/__init__.py" = ["E402", "F403"]
"src/index/models.py" = ["N815"]
"src/manage.py" = ["INP001"]
"src/processing/management/commands/*.py" = ["TRY003", "EM101", "EM102"]
"src/ai/*.py" = ["T201"]
"bin/hash_rabbitmq_password.py" = ["INP001"]

Thanks so much! Do you happen to know which file is triggering this? Are you able to include a snippet to reproduce it (or a link to the repo)?

Unfortunately no, I accidentally ran black after this and cannot reproduce the bug anymore :(

Blerg ok. I'll close for now, but please ping back here if you see this again, I'd love to help!


bring back Modulation

i suppose it was removed long ago when there were no expressions?

Thanks for figuring it out. I have been wondering what's the cause.


Unable to access project when password is empty

When creating a project while not entering a password, the project is not accessable. No error message is shown. There is also no error in the log file.

Thanks for reporting this. Empty passwords were treated as not set passwords thats why the login didn't work.
33be2ceaa4abd74a68623e9ebdaa165091d52f90


Remove useless template

Coverage remained the same at 99.196% when pulling 776b166c80fcb3ce5f9031533a61d9665cc7ac85 on remove_mdtemplate into 37ea25b903aac0529f41865aaee1276fa255853e on master.

Coverage remained the same at 99.196% when pulling 776b166c80fcb3ce5f9031533a61d9665cc7ac85 on remove_mdtemplate into 37ea25b903aac0529f41865aaee1276fa255853e on master.


pdctl: should not use a format string

Signed-off-by: Shafreeck Sea<EMAIL_ADDRESS>
What problem does this PR solve?
There is a bug when constructs an URL string when does remove-tombstone
Failed to remove tombstone store parse http://pd-test-pd:2379/pd/api/v1/stores/remove-tombstone%!(EXTRA string=): invalid URL escape "%!("

What is changed and how it works?
Remove the unexpected fmt.Sprintf
Check List
Tests

Unit test

These Sprintf with non-literal format string looks dangerous. Maybe use a function to construct these strings is a better way to solve the root problem?

So no unit test covers it?

@disksing Good catch. I am afraid not.

@Luffbee I don't get your point too much. Why does Sprintf look dangerous?

@Luffbee I don't get your point too much. Why does Sprintf look dangerous?

There is no check for the format string and arguments during compile time in go. So, with non-literal format string, it's easy to write bugs like this one, and it's hard to discover this kind of bugs.

@Luffbee Good point. But I think this PR can be merged first. Maybe it's a little long term plan to reduce format output.

Why your previous test not work? I remember there is a test in tests/pdctl.

Anyway, I think this PR could be merged first. We can create issues for other problems.

/rebuild


Fix CPU spike when opening PodDetails from MonacoEditor

Don't mount the children of DrawerParamToggler when closed (default)

Signed-off-by: Sebastian Malton<EMAIL_ADDRESS>fixes https://github.com/lensapp/lens/issues/5154

@Nokel81 Just noticed that the issue https://github.com/lensapp/lens/issues/5659 is only presented in current PR.

@aleksfront I found the issue, it was because PodDetailsTolerations were adding to the styles of the DrawerParamToggler which then failed because I converted it to modules. So I have reverted away from modules and we can fix that later.


fix: resetting pinchScale.value to 1 when double tap performed

Details

zoom scale value didn't reset after double tap gesture
Fixed Issues

$ https://github.com/Expensify/App/issues/37248
PROPOSAL: https://github.com/Expensify/App/issues/37248#issuecomment-1965808408
Tests

Go to any chat
Send an image
Tap on the image preview
Zoom in until you can not zoom more
Double tap on the image to zoom out
Try to zoom in with 2 fingers

[x] Verify that no errors appear in the JS console

Offline tests

Go to any chat
Send an image
Tap on the image preview
Zoom in until you can not zoom more
Double tap on the image to zoom out
Try to zoom in with 2 fingers

QA Steps

Go to any chat
Send an image
Tap on the image preview
Zoom in until you can not zoom more
Double tap on the image to zoom out
Try to zoom in with 2 fingers

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/60419079/d68dc183-a045-40b0-a972-4c43c00892e6

Android: mWeb Chrome

android_web_app.webm

iOS: Native

https://github.com/Expensify/App/assets/60419079/9e9dee49-ef2b-4c48-b748-4e5b3dc2e3a8

iOS: mWeb Safari

https://github.com/Expensify/App/assets/60419079/070e5ea7-6cd2-4d29-b684-2527f977c171

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/60419079/81acb3c4-c22f-4145-a2bf-4add4803e763

MacOS: Desktop

https://github.com/Expensify/App/assets/60419079/1f5d8184-f240-4168-8fb5-a87342f9116b

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native
https://github.com/Expensify/App/assets/12595293/2ffe28a5-59ee-4914-9a66-7b7f3ac03297

iOS: mWeb Safari
https://github.com/Expensify/App/assets/12595293/4e996ffa-9155-4296-899e-2df833696338

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/12595293/c05d39d9-69b7-4bc4-936e-54f71bdbf706

MacOS: Desktop

@andreasnw please pull main – the TS check is failing at the moment.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to production by https://github.com/roryabraham in version: 1.4.48-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


GEOMESA-1122 Remove dependency on deprecated AbstractDataStore

Reorganized AccumuloDataStore methods

Moved bounds logic into separate trait
Separated GeoTools methods vs GeoMesa methods
Separated public vs private methods

Removed visibility checks for writing data - OBE due to feature level visibility
Removed calculation of spatial bounds when adding feature collections - not used

Signed-off-by: Emilio Lahr-Vivaz<EMAIL_ADDRESS>

awww "Removed calculation of spatial bounds when adding feature collections - not used" too bad :crying_cat_face: one day we'll actually implement spatial bounds

@jahhulbert-ccri never fear, it's being brought back imminently.

so far looks good. i'll test it out a little and see if anyone else has a comment.

@jahhulbert-ccri fixed per your comments

10fea24a17ba16b5525a25721b62172a1ff38288


Fixed a few syntactical & organizational things.

Moved styles to their own folder. Moved 'test.html' to its own folder. Updated paths accordingly. Added a new font to try out for Header. Linted 'index.js' file (automatically, then had to fix manually). Fixed some small syntactical things.

Thanks bro! I'll check it out here tonight.


Files cannot be downloaded from the admin site

Describe the bug
Since moving to the Azure storages backend, the links to download the files in the admin site don't work. The link redirects to the a fairly sensible URL, but azurite is the root instead of localhost when developing locally. Also no account key or SAS token is provided, so you get an authentication error if you swap out the root.
To Reproduce
Click the link in the admin site of any uploaded file.
Expected behavior
The file should be downloaded.
Proposed solution
Maybe we can modify the admin to use generate_sas_token() for downloading files.
Aha! Link: https://imperial-college-ict.aha.io/requirements/RSE-132-8

Work in progress on admin-download-files branch. Need to figure out how to also change the link in the list / table view.


RGB 530 Pro

I have an RGB 530 PRO, is there anything I could do to help you get this device supported?

what is the device name?
You should be able to scan it from bluetooth-inspector
https://apps.apple.com/ca/app/bluetooth-inspector/id1509085044

Tested with this light. It works.


Move consts, ipfs, and ipld to pkg

Description
This super simple PR moves the consts, ipld, and ipfs packages to pkg and that's it. I was strict in limiting changes of this PR in hopes of making the review process for this and future PRs simpler.
Part of #506

What is the next step with this? My understanding is that a lot of the code that currently uses this will actually be not using it anymore; is that right?

yeah, we'd definitely remove and refactor some code, this is only an intermediate step that will hopefully make the review process for the next steps easier. Those next steps would be to complete #506 and #505. Eventually, I think we'd move things into their own package as discussed in #296


Added Join and Leave Buttons for #queue channels

Added Join and Leave buttons for queue channel to make it easier to join and leave the queue! Functionality for the /enqueue slash command wasn't changed, there are now two ways to join the queue, either by using the /enqueue command or clicking on a button in the corresponding channel.
https://user-images.githubusercontent.com/63953483/165027003-fb6cb252-c920-4b0d-8524-e6fa1b844cc9.mp4
The "This Interaction Failed" error that shows up after you click the button can be easily fixed with interaction.deferUpdate() (which I have commented out in line 116 in app.ts). But this function causes the bot to crash if the duration between the button click and the call of deferUpdate is more than 3 seconds. I ran the bot locally on my MacBook, so the functions probably took a long time to run because of limited resources (I have had issues with time delay when running a different discord bot on my laptop before). You may try to see if it works when running the bot in the cloud. I shall try to find a permanent fix that doesn't depend on a guaranteed 3 second completion time.
PS. There is some code commented out for stuff I plan on working on soon

For now seeing as how students can only join a single queue, let’s stick to
using the same method.
If in the future you want to allow students to be in multiple queues, that
can be worked out. I think it’s tangential to this PR.
On Mon, Apr 25, 2022 at 10:07 PM Kaoushik Murugan @.***>
wrote:

@.**** commented on this pull request.
In src/server.ts
https://github.com/ECS-OH-Bot/BOB/pull/1#discussion_r858271156:

         }

     }))
     return queue_count
 }

async RemoveMember(queue_name: string, member: GuildMember, interaction_type: string): Promise {

the /leave command when called where-ever on the server will remove the
person from the queue. But there's a leave queue button for each queue. So
I don't want a user to press the leave button for one queue and get kicked
out of another. Also I'm planning on possibly allowing someone to join more
than one queue so it might be useful later
—
Reply to this email directly, view it on GitHub
https://github.com/ECS-OH-Bot/BOB/pull/1#discussion_r858271156, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACQLYGO2LGAFRRP3KIP3SODVG52XLANCNFSM5UHOBY3A
.
You are receiving this because you commented.Message ID:
@.***>


Question: are task capacities supported in RTIC 2?

I'm trying to move one small project to RTIC 2 and task capacities result in unexpected argument.

Hi, there is no capacity field attribute, instead you setup a channel. See https://rtic.rs/2/book/en/by-example/channel.html for more details. Let us know if something remains unclear.

(You can still initially spawn with an argument, similar to a 1-sized queue.)

Okay, understood and implemented. One more question however, previously I had a lock_free shared resource used in software tasks. Now it seems to be not allowed:
Lock free shared resource "xxx" is used by an async tasks, which is forbidden

Is this true? Do I need o lock now?

You can still have local resources (being lock free). The thing is that using async non atomic resources shared between async tasks at the same priority level might race each other (as an effect of the cooperative multi tasking).

You can still have local resources (being lock free). The thing is that async tasks at the same priority level might cause a race condition on non atomic shared lock free resources (as an effect of the cooperative multi tasking). Async tasks are no longer run-to-end.

Okay, thanks for quick response.

Sorry for commenting on an old issue, but I don't completely understand how channels replace the functionality of capacity. As I understand, channels are a way of communicating between tasks and do not aid in spawning the same software task multiple times. Or have I misunderstood something?

I'm not 100% sure, but I think you misunderstand the capacity. The capacity docs says:

In the example below, the capacity of task foo is 3, allowing three simultaneous pending spawns of foo.

These are "pending spawns", so equivalent to a channel/queue length.

Yes, exactly. I want to be able to queue 3 tasks at the same time, without having to redefine the same task 3 different times. I don't want to make my own logic for dispatching the tasks, I just want to say "when possible, run this task 3 times".
I am doing some benchmarking, and I want to try classical matrix multiplication using multiple tasks where each task is assigned their own iteration of the outer most for loop in a matrix multiplication algorithm.

I think you are misunderstanding how RTIC works in general. It doesn't allocate tasks dynamically. The tasks are static and additionally, in RTIC 1.x, are run to completion, especially for purely computational tasks (like matrix multiplication). In RTIC 2.x you can have async tasks, so concurrency is possible, but still, not for purely computational (non-blocking) tasks.

I am aware that tasks aren't allocated dynamically, which is why a capacity field is needed to begin with (to reserve space in the stack for up to a certain amount of tasks).
Another example of another test I am doing is having some sort of background task doing nonsense work while I have another task that is doing important stuff. Then, I want to be able to have multiple instances of that background task being queued for execution at the same time. Without the capacity field, I am unsure of how to implement this in RTIC 2.x. I don't want to create multiple tasks that has the exact same functionality, since it feels like an absurd way of implementing what it is I want to do.
For example, in the same page that was first sent by perlindgren in this thread to an example of channels. 3 different tasks are created doing the exact same purpose (acting as senders), which would not be needed if a capacity field was present. Then one task could be defined, and then 3 different variations if it being queued.

What you want is preemptive concurrency. RTIC, at least for the same priority tasks, is cooperative. There is no time slicing. This means that you would gain nothing spawning multiple tasks, as the other tasks would run only after the first task finishes. I think this is why this was removed from RTIC 2.x, as channels offer the same behavior + are a little more flexible. But as I said, @perlindgren is probably best to clarify.

The reason for running multiple tasks is to capture the overhead added by context switches, which would be lost if it was all one task running. But I also understand that there is no great value in using capacities in a normal situation, it would just be nice for my niche case :)

capture the overhead added by context switches

Oh yeah, so if measuring this is the goal I think your setup is no good for cooperative scheduler.

Well, partly. The goal is to compare it to a similar application written in C (FreeRTOS), so I also want to capture the performance of the languages as well as everything connected to the different RTOSs.

In RTIC 2.x you could try to measure the async tasks context switches. Create two async tasks sharing two channels and implement a simple ping-pong exchange and then measure the time it takes to do X ping-pongs.

There are different types of context switching:

RTIC binds hw tasks to interrupts, in this case no added OH to the hw interrupt dispatch.

sw tasks (RTICv1) use a single dispatcher per priority level. It will also allow passing arguments. The implementation is fairly simple each task holds a message queue. On top of that there is a timer queue, but its kept separate so no additional copy of message data is needed due to that. The scheduling cost is the underlying hw cost + dispatcher, so cost is payload dependent. The dispatcher and user tasks are compiled together in the generated code, so efficient in comparison to a traditional kernel, where the OS is compiled separately.

async tasks (RTICv2) binds to an async executor. The actual OH of the context, switch is largely up to how well Rust is able to generate code for storing/restoring context. The "glue" generated by RTIC is minimal. One can await "anything", including channels, overhead of that is completely up to the channel implementation and not part of the RTIC core.

If you access local resources (or shared lock free) these are accessed directly (no added oh), if you access shared (non-lock free), its zero-cost in Rust terms, and implemented by manipulating either interrupt enable register or BASEPRI (where available). This cost of resource accesses is independent of task type.
As mentioned in earlier comments, there is no time-slicing. Tasks runs to completion (or yield on await for v2). One can mimic capacity v1 through channels in v2, but they are not exactly the same.

How is starvation handled in this case? Let's compare RTIC v1 and RTIC v2 again. If one would want a task A to run 10 times in v1, one uses capacity to schedule the task 10 times. And then we schedule another task B, and then we schedule more instances of task A, Then, if Task A and B have the same priorities, B would run after the first 10 instances of A.
Let's imagine the same case for v2, where we use channels instead. I imagine that one would then have task A in an infinite loop reading from a channel and getting the arguments from that channel. If we send 10 values to that channel (as to have A run 10 times), schedule a task B, and after some time (before task A has worked through the first 10 items) send more items to the channel. Wouldn't B possibly be starved here if this continuous forever, or am I misunderstanding something?

Minor note: In one example in the docs there is a comment The capacity of foo is reached. It's a little confusing since "capacity" is no longer defined in this context.

@viloz1 If I understand correctly: In RTICv1, if task A and B have the same priority, B runs after the first instance of A, not the first 10 instances. (Well, really, the execution order is not guaranteed at all -- B may run first).
The same should hold with channels in v2. If task A awaits a channel receive in a loop, B may run as soon as A yields. (Note in v2 that a loop must contain an await point.)
In either case, if it's required that A does its work first, A must be assigned a higher priority. Then of course starvation is possible.


TouchableHighlight as a stack navigator doesn't work and throws this error

TouchableHighlight as a stack navigator doesn't work and throws this error. It's needed to navigate another page when user clicks on the CardItem. Here is my code.
CardItem
<TouchableHighlight onPress={() => this.props.navigation.navigate("Post")}>
 <CardItem>
              <Left>
                <Thumbnail source={{uri: 'Image URL'}} />
                <Body>
                  <Text>NativeBase</Text>
                  <Text note>GeekyAnts</Text>
                </Body>
              </Left>
            </CardItem>
            <CardItem cardBody
            onPress={() => this.props.navigation.navigate('post')}
>
              <Image source={{uri: 'Image URL'}} style={{height: 200, width: null, flex: 1}}/>
            </CardItem>
<TouchableHighlight>

app.js
import React from 'react';
import {StyleSheet, Text, View,ScrollView,Image,Icon } from 'react-native';
import {
Asset,
AppLoading,
} from 'expo';
import WelcomeScreen from './screens/WelcomeScreen';
import SigninScreen from './screens/SigninScreen';
import SignupScreen from './screens/SignupScreen';
import HomeScreen from './screens/HomeScreen';
import ProfileScreen from './screens/ProfileScreen';
import SettingsScreen from './screens/SettingsScreen';
import ContactScreen from './screens/ContactScreen';
import ForgetpassScreen from './screens/ForgetpassScreen';
import { TabNavigator, DrawerNavigator, StackNavigator,contentOptions} from 'react-navigation';
import DrawerContent from './components/DrawerContent'

export default class App extends React.Component {

render() {

const MainNavigator = TabNavigator({

  Welcome: { screen: WelcomeScreen },

  Signin: { screen: SigninScreen },

  Signup: { screen: SignupScreen },

  main: {
       screen: DrawerNavigator({
         Home: { screen: HomeScreen },

         Profile : { screen: ProfileScreen },
         Settings : {screen: SettingsScreen},
         Contact: {screen:ContactScreen},
       },
       {
   drawerPosition: 'Left',

           contentComponent: props => <ScrollView>< DrawerContent {...props} /></ScrollView>,
           contentOptions: {
        inactiveTintColor: '#1414fc',
        activeBackgroundColor: '#383838',
        activeTintColor: '#1414fc',

       }

      }

    ),
      links : {
             screen: StackNavigator({
               Forgetpass:{screen: ForgetpassScreen},
               Post: { screen: PostScreen },

             },
           )
         }
     }
   },

   );

return (
  <MainNavigator />

);

}
}

The navigation prop is only going to be available to components registered with a navigator. If you want to access it via a child component you'll need to either

Pass the navigation prop down manually
Use withNavigation on the child component to grab navigation from context

Sorry but I am a bit confused. Documentation is a bit unclear. Will it look like to this?
TouchableHighlight onPress={() => this.props.withNavigation.navigate("Post")}>
it shows the same error. As I need to add this code for navigating through card item I don't find how to use it.

Sorry but I am a bit confused. Documentation is a bit unclear. Will it look like to this?
TouchableHighlight onPress={() => this.props.withNavigation.navigate("Post")}>
it shows the same error. As I need to add this code for navigating through card item I don't find how to use it.

No, sorry you would use it like this
import { withNavigation } from 'react-navigation';
class CardItem extends React.Component {
  render() { ... }
}

export default withNavigation(cardItem);

The main problem with this approach is that component is the Posts while inside are 4 cards which include those CardItems so CardItem is not a component that is why it becomes so challenging to use this approach.