Fix C/C++ header issues

There are a number of issues with C and C++ filetypes and header files which need to be resolved. This issue will capture all of them, so discussion doesn't get fragmented.
It is worth noting that it is not probably not possible to detect the location of header files for 100% of projects. Some manual configuration on the part of users will be needed. (See the most popular C projects on GitHub for examples.)
TODO

[x] Support #include lines for quoted headers in the same directory.
[x] Somehow detect the location of other header files, and use -I to include those. (See #379.)
[x] Solve some strange issue with capitalized header names? (See: #318. Probably just how the system reports a missing header file.)
[x] Ensure that errors in headers are not reported as errors inside C files. (See #321, #211. A filename filter for errors may be needed, or a filter for <stdin>, etc.)
[x] Fix some kind of issue with #pragma once in C++ header files. (See #356)

Somehow detect the location of other header files, and use -I to include those. (See #379.)

I think this is not a job for ale. User should provide the necessary -I and -isystem switches to the appropriate ale_c_*_options/ale_cpp_*_options. Guessing would probably break horribly in more complicated projects, e.g. self-contained build systems, cross-compile scenarios etc.
As for #include "header" syntax - per C standard, this type of include is implementation-specific. This typically means that the header search starts in the directory containing the file with the #include statement. In this case - if the actual gcc/clang command is not executed in the source code directory (when ale runs the linter), I would add an implicit -I<c-source-directory> to the gcc/clang command line. Also, this might need an on/off behaviour (e.g. let g:ale_c_gcc_autoinclude_source_dir = 1 or similar), because if using a preprocessor which doesn't support #include "" syntax and treats it as #include <> instead (allowed by C standard), then this might break things..

For the #include "foo" syntax, all I did was fix it so the directory the file is in will be included in the search path, which is how gcc and clang work, which are the only supported compilers for linting. If some other compilers are added, they can be implemented differently.
For -I paths, it would be very useful to parse a project's configuration files, or follow a common project structure, etc., and determine how to include headers automatically. If it doesn't break anything, or it can just be turned off, it will only be benefit.

I think for basically any functionality, you should be able to turn it off. Everyone wants different behaviour.

For -I paths, it would be very useful to parse a project's configuration files, or follow a common project structure, etc., and determine how to include headers automatically. If it doesn't break anything, or it can just be turned off, it will only be a benefit.

Configuration files? Is this Makefiles? CMakefiles? Automake/autoconf stuff? Custom perl scripts (yes, I've seen those)? This is not easy without understanding the build system... Doing a guesstimate will only work for trivial projects, where the added value is small. I wouldn't spend time on this ...
The only automagic stuff I can think of which could work kinda universally is to
1.) write a wrapper for gcc calls
2.) ask the user to do a clean build
3.) wrapper records command line for each C file, stores it in a DB
4.) when invoking linter, do a DB lookup for the proper set of flags and use those
this still has issues, example:
a.) if editing a new file, what flags do you use? typically, files in same dir would have the same set, but what if they don't?
b.) conflicts - files might be built multiple times in the same project (different feature sets, different architectures...)

That's why I said this above.

It is worth noting that it is not probably not possible to detect the location of header files for 100% of projects.

I would like to add some support for automatically detecting the location for header files, even if it's only for a minority of users.

The use of compilation database (compile_commands.json) seems reasonably common. Support for that would probably be a good step.

I didn't know about compile_commands.json. That sounds like a good idea. Here is a link to the documentation for the benefit of others: https://clang.llvm.org/docs/JSONCompilationDatabase.html

Maybe we can do it by reading a file like .clang_complete which is how https://github.com/Rip-Rip/clang_complete get the include path. And this project provide a script to generate .clang_complete  from Makefile, though it's hard to write by hand.

The way https://github.com/Rip-Rip/clang_complete handles compile_commands.json works perfectly for me. No need for external scripts since cmake outputs the json automatically.

I like the way YouCompleMe handles this:
https://github.com/Valloric/YouCompleteMe#option-1-use-a-compilation-database
and you can also manually provide flags on a per project basis:
https://github.com/Valloric/YouCompleteMe#option-2-provide-the-flags-manually

As somebody already mentioned YouCompleteMe I'll ask my question here. YouCompleteMe deactivates Syntastic for C/C++ projects and provides it's own syntax checking. Which is also asynchronous and very good. Do you know if YouCompleteMe and ALE can work together the same way?

I'm using YCM for tab completion and ALE for syntax checking without any
issues. ..
On Sat, Apr 1, 2017, 09:57 Christian Rapp<EMAIL_ADDRESS>wrote:

As somebody already mentioned YouCompleteMe I'll ask my question here.
YouCompleteMe deactivates Syntastic for C/C++ projects and provides it's
own syntax checking. Which is also asynchronous and very good. Do you know
if YouCompleteMe and ALE can work together the same way?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/w0rp/ale/issues/392#issuecomment-290904021, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABn33c55YOiwZEmretCERjoQQETl1gtAks5rrgN4gaJpZM4MbBk5
.

@klement thanks for the information I'll definitely try ALE this weekend...

I messed around a little bit with the commands, here's what I found out :

With my c(++) projects I'm used to having local .vimrc telling all the project-local settings, which included (when I used Syntastic) the flags to point to compilation databases for clang-tidy and clang-check linters.
I tried to add clang-check to the checkers since it's packaged in Fedora (to the contrary of clang-tidy)
Running the command using the %t substitution does not work, maybe because (it's a guess) the compilation database actually compares the paths of the temporary files with the paths stored in the json to get the includes. Temporary path is not in the json => no include is added => first user include gives an error. Specific management of temporary files could help (create them in the same folder as the opened file) but I am not sure how easy this would be to implement.
In order to make it work I had to use the %s substitution, which made clang-check work properly, using "-p path/to/build" as g:ale_cpp_clang_check_options

I still have 2 problems concerning this :

clang-check gives errors for all the files included for the compilation of the file in buffer, and using the gcc handler took all line/column locations like they were in the buffered file. This leads to having a warning popping up in fileA.cpp (in active window) at line 30 col 25 even if the actual warning was in fileB.cpp (or fileC.h) at line 30 col 25.
Currently clang-tidy checker has "--" in its command, which basically cancels the -p flag. Since the main point of clang-tidy checker is to use compilation databases, I think this should go, but I am really not sure about this point and am eager to learn more

I suppose we have two options for these linters, and we can only pick one.

Check the files on disk, and check for semantic errors requiring information files.
Check for syntax errors only, ignoring other files, as you type.

The good news is that the two can be combined. Two linters can be written for supporting both at the same time, with only one checking for problems while you type. Combining linters in this way is supported already, so nothing complicated will need to be done there.
I think a I'll recommend first changing pretty much every current C linter so they only check for what errors can be checked without knowledge of other header files, and then separately adding linter definitions which look at the file on disk, to check for more problems.
That is, unless there's some way to check for even semantic errors while you type. I'm relying on those with knowledge of these compilers to tell me how to do that. I don't really use them myself.
Having some example open source projects to test with would be very helpful. I can't really do anything without some code to test against.

I'm of two minds really. Ideally, I would like to check for all problems while you type, including semantic errors. The more error information, the more frequently, the better. If it turns out to be impossible, then it's impossible. If I knew more about C, C++, GCC, Clang, and so on, this might already have been implemented.

What confuses me about the clang-tidy linter is that it is set up like this.
let g:ale_cpp_clangtidy_options =
\   get(g:, 'ale_cpp_clangtidy_options', '-std=c++14 -Wall')

function! ale_linters#cpp#clangtidy#GetCommand(buffer) abort
    return 'clang-tidy %t -- ' . g:ale_cpp_clangtidy_options
endfunction

I was told that -- was needed to pass compiler flags, but I'm also hearing now that -- breaks clang-tidy so it doesn't pick up on the compilation database automatically. What should be done here?
Is there some additional argument which could be passed to have clang-tidy pick up on the compilation database? We could find the file ourselves and pass it to clang-tidy ourselves.
Should the options for clang-tidy be removed? How will you then configure your compiler flags? Is that something clang-tidy derives from the compilation database files? (I don't know much about it myself.)

I'll go do some reading later, as I'll have some time this evening, and see if I can find any example projects to test with, and some documentation on how all of this is supposed to work.

Compilation databases are json objects that contain (at least) 3 keys : "directory", "file" (specific to lookup the file in the src folder) and "command". Command contains the actual command run to compile the file, include directives and compilation flags. That means there is no need to pass compile flags to clangTools linters if they're given compilation databases (Flags are written in the json by CMake or bear...)
Personally, I think all tools from Clang tools, since they derive from LibTooling, are meant to be used with compilation databases. So in my opinion clang-tidy and clang-check linter should check files on disk and check for semantic errors, even if the linter is active only on write operations ; whereas clang linter can be used for local syntax errors only.
My 2 cents on the question "What should we do ?" is to put clang-tidy and clang-check in category 1, and clang in category 2. So clang-tidy/check could use %s and pass "-p build" as default flags (or find build subfolder in the path). And as a first step, we can dismiss all the warnings clang-* tools give for included files.

Cool, thanks for all of the information.
I'll also see about adding C and C++ tools to the Docker image, if possible, with some tests for those tools.

Okay, after a bit of tinkering around, the Docker image should now include every C and C++ tool, except from cppcheck, for now. (I couldn't easily install that one using the package manager.) Now it should be possible to write some tests which actually execute the C tools, for covering header issues with tests.

I have just pushed a commit now which might initially cause a couple of issues, but should hopefully be a start on fixing some header issues.
Now if there are any problems inside of code in included headers, those problems will be reported on the header #include line with the string 'Problems were found in the header (See :ALEDetail)'. Using :ALEDetail will just print all of the raw lines of output from GCC.
For example, for this output...
In file included from a.h:1:0,
                 from test.c:3:
b.h:1:1: error: unknown type name ‘bad_type’
 bad_type x;
 ^
b.h:2:1: error: unknown type name ‘other_bad_type’
 other_bad_type y;
 ^

:ALEDetail will print the following lines:
b.h:1:1: error: unknown type name ‘bad_type’
 bad_type x;
 ^
b.h:2:1: error: unknown type name ‘other_bad_type’
 other_bad_type y;
 ^

Similar adjustments will probably be needed for clang, some regex will probably need to be adjusted, etc.

I have also added some integration tests which execute GCC and check the errors that come out the other end.

The next step is to start parsing the compilation database files for at least the clang programs.

The same should be supported for Clang now too.

I'm moving the rest of these issues to the next milestone. I've fixed a variety of C and C++ header issues, but there's still a lot more that can be done.

I still do think that the Libtooling provided by clang should be used if you want to detect the other included headers. clang-check does the exact same analysis as clang -fsyntax-only as far as my understanding goes (probably not so far), so implementing clang-check linter to ale should help a lot with figuring out where header files are.
I'm working on a quick implementation right now, Pull request should fall this afternoon (GMT).
Also, I would like to add the option of giving the build path to clang-tidy linter, since these tools are made to work with a compilation database, and the path to find it is not always easy. In the end I really want to just use autocommands like this in my vimrc

The detection of include directories should be good enough for now. Support for using comple_commands.json and other similar things for more tools can be added later.

I've struggled a bit with the defaults. If I enable cppcheck it seems to check the whole project rather than just a single file. This is possibly a cppcheck issue though as running the command myself does the same.
For the other checkers, the projects I'm working with need a lot more compile options, which vary based on the sub-directory or individual file. I've hacked together a change for the c_gcc check to get the options from my compile_commands.json. Its pretty bodgy vim script though being my first attempt.
What's the best way to share this?

I don't know how gcc linter works with compile_commands.json, but now there is a function to that finds compilation command databases for c-language projects. See autoload/ale/c.vim
If you want to see an example of how it works, you can look at the clangcheck linter I added. clang-check wants the folder with compile_commands to be passed with the -p flag, and the doc for global cpp options to see how to interact with ale#c#FindCompileCommands.
The best way to share this is to fork the repo, create a branch with your changes there, and ask for a pull request.

I recommend creating a pull request for it. If there's some way to parse options from a file and pass them on to GCC which works reliably, then we could support that. From now on I'm tracking individual issues with C and C++ compilers, now I've fixed a large number of simple issues, like finding header files in simple projects automatically.

Yup. I've got as far as forking. I think I need to branch too? And then tidy what I've done up and make it a bit more correct in its parsing of the compilation database. And see if I can create tests for it as well. Probably not until the weekend at the earliest though.

Cool.  Whatever works best for you.

I'd like to get a reasonable workflow for using ALE to lint my C++ when only gcc is available on the system, it doesnt seem like a compilation database is needed, most if not all of the failure is from being unable to find headers. So, I just need some quick non-global way to inform ALE about what -I flags to set.
In YCM this would be to make custom .ycm_extra_confs that define those flags explicitly, which is fine, if extremely ugly due to the mass of boilerplate in there. The key here is for each little project I want to add just the specific header search paths and not others. For the time being I can dump them all into my .vimrc to make ALE always pick them up when linting any C++ but i'd like it to try to fetch this from a local dotfile like .ale_cpp_conf in the directory of the source file (or above it).

See :help g:ale_pattern_options. You can set up options for each buffer based on a regular expression pattern for filenames.

OK, that's useful, but i guess I'd prefer checking the local filesystem for project specific compile path config rather than polluting my global vim config with project-specific compile path config. Right?
This would also be a valid feature to use if there indeed is a way to get vim to auto load some vimscript in the same directory when opening a file from that directory.

You can use a plugin such as https://github.com/krisajenkins/vim-projectlocal to define settings based on a particular directory. I use this to set the CPLUS_INCLUDE_PATH environment variable, which is exported to calls to the compiler by vim.

That's very useful. Do you know how it is different from builtin set exrc?

exrc only looks in the cwd I believe. Projectlocal will identify the root of the project based on version control markers and automatically includes multiple configuration files from parent directories if present. The two don't differ too much though, the plugin is only about 30 LOC.

Yeah, okay. I think I can get by with exrc as my workflow often just has me leave my central vim's cwd in a particular place. But that does seem quite useful.

@dutchgecko there are moderately serious security concerns about the use of exrc or that plugin you linked.

Sorry I'm a bit confused. One issue I have with C++ and Ale is I get many false positives for includes from libraries that come from the cmake. Is there any solution to this? I also noticed in these files it will only show the first error, if there an error lower in the file that will not be marked.

What do you mean by false positives ?

Linting implementation files : If you use a linter like gcc that'll try to compile the file, if you get a compilation error, then the rest of the file will not be parsed, so you'll actually stop at the first error, I don't think you can really do much about this. And theoretically, for clang based linter the compilation command database is read for implementation files so you should get all the necessary includes to avoid errors. For gcc based linters, there's an open PR ( #725 ) to read the correct include arguments from the compilation db. Hopefully it will be ok soon.

Linting header files : nothing is really ready on this aspect, this will be done later I think.

So far in the past few months, g:ale_pattern_options has worked extremely well, and all I do is iterate through running :ALEInfo to get to the bottom of all the (mostly header path related) errors.
Today I have also figured out how to get clang_complete functioning very well with my projects.
My next step will be to unify the two systems by implementing in my vimrc some code (probably will just use python) that will implement the walking up the filesystem searching for .clang_complete and procedurally assemble a corresponding g:ale_pattern_options from that. This should give me that holy grail where I fully control the linting and completer flags, both use clang, and I have full clang powered completion and jump-to-definition together with live in-editor signs (complete with line highlighting). Full featured Vim IDE by this point.

I think .clang_complete should just be in your vim's path option, and then you can just use a built-in vimscript function to look for the .clang_complete file and be done with it. Also, it's probably already done in this case by this function : can you tell if it's good enough or if you have corner cases where it doesn't work ?
The only issue we had with these "Find smartly this file I need" is for the compilation database made by CMake for example, since the file is actually nested in a different subfolder and therefore is not easily findable by just setting the path correctly. To correct this we added a function to specifically look for compilation databases in out-of-source builds : It's there
I have not looked the code for a while, but if you make a translator from .clang_complete to ale_pattern_options, it's probably going to be needed in the plugin here in a location to confirm later. But it's also possible that it's been done.

Thanks for pointing me toward path. It does seem to be part of Vim's original design toward use in projects, stuff like this (and e.g. various ctags integration) sometimes get left on the wayside in the search for more "modern" tools but should not get overlooked. I can't say that ctags has much use in the presence of the glory that is clang, though 😄
I am not certain that using path makes the most sense here. I've never configured it in my vimrc, it seems like it is set to .,/usr/include,, which is sensible and rather minimal. I would not want to extend this with anything beyond the typical system header locations, though. And this is where it doesnt make too much sense to use this for finding .clang_complete flag files... those are going to get stashed within my projects' directories. I really don't want to put compiler flag configuration (which is really specific to a projects' dependency implementation detail) in a centralized place, which is where it has been (in my vimrc in g:ale_pattern_options) so far.
So it does feel like the logic I want (and hopefully to implement in pure vimscript) is to iteratively go from current working dir (and from file's containing dir) upward toward filesystem root looking for .clang_complete.

fast forward to 2020, ale complains not finding local header files, what is the right way to "fix" it? I do have compile_commands.json generated but they're not used by ALE it seems, do I need add the -I flags to ALE's gcc/clang flag variable manually for each project?

There are two settings that might help. g:ale_c_parse_compile_commands and g:ale_c_parse_makefile. Both are off by default as they aren't perfect.
I think the problem is with C itself. There's no standard for where headers should go, so there's no reliable way to detect them. You can guess there is an include directory. The best option I think you have is to parse Makefile results or compile_commands.json files, which those two options are for.


[HOLD] Bump dependencies

no issue

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
This commit resolves https://hackerone.com/reports/310439.

<EMAIL_ADDRESS>
Contains a knex version bump. We first to to final test and approve the latest release.


Instructions for running krustlet with microk8s

Fixes: #227
Hopefully useful (!) documentation summarizing running krustlet alongside microk8s.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: DazWilkin sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

thank you! Would you mind adding a link to this guide in the quickstart?

If you can wrap sentences to 100 characters as well, that would be much appreciated. If not I can go and do this in a follow-up.

@bacongobbler to this page: ./docs/intro/quickstart.md ?

Yeah, in that file and in ./docs/howto/README.md

Looks like there's a merge conflict here. Would you mind fixing that up? Once that's done we can merge. Thanks!

Done (I think)


NIFTY 50 not found in Scripmaster

Hi,
I tried to get historical OHLC data. It is working for almost all stocks and indices. But I am not able to get the same for NIFTY 50 index. I can see NIFTY 100, NIFTY 500 and many other indices in Scripmaster. But NIFTY 50 is missing.
Please help me to get the same.
Thanks,
Krishna

Dear @KrishDCoder,
The required details for NIFTY 50 are as follows:
Exch : N
ExchType : C
ScripCode : 999920000
Symbol : NIFTY
You can use the above details for NIFTY 50 index.
Thanks.


help

Hi, there isn't enough information for me to go on here, and I'm not sure this is a question for this repo.

MetaMorphers.sol has nothing to do with the code in this repo.
Please don't use screenshots when referring to code, please use copy-pasted formatted code.
I don't know what you're trying to do.

Please either create a new issue about something on this repo, or it might make sense to take your question elsewhere.


Update yamlgettingstarted.md

The npm task in VSTS only accepts three commands right now on v1.

install
publish
custom.

So using the command input test will not work, we should either use command: custom and add additional commandParameter or take the publish command as a simple example.

Thanks!


[New chain]: Shape Mainnet

Summary
I would like to add the Shape Mainnet network
Chain ID
360
Chain detail URL
https://chainlist.org/chain/360
RPC URL
https://mainnet.shape.network
Blockscout Client URL
No response
Etherscan Client URL
https://shapescan.xyz
Etherscan Client API URL
https://shapescan.xyz
Version
1.3.0
Address (Master copy)
0x69f4D1788e39c87893C980c06EdF4b7f686e2938
Deployment Tx hash (Master copy)
No response
Block explorer URL (Master copy)
https://shapescan.xyz/address/0x69f4D1788e39c87893C980c06EdF4b7f686e2938
Address (Master copy L2)
0xfb1bffC9d739B8D520DaF37dF666da4C687191EA
Deployment Tx hash (Master copy L2)
No response
Block explorer URL (Master copy L2)
https://shapescan.xyz/address/0xfb1bffC9d739B8D520DaF37dF666da4C687191EA
Address (Proxy factory)
0xC22834581EbC8527d974F8a1c97E1bEA4EF910BC
Deployment Tx hash (Proxy factory)
0x5b9e4c25405d0e99111491f098067c39a2ff125f067863cd25d598848010f57e
Block explorer URL (Proxy factory)
https://shapescan.xyz/address/0xC22834581EbC8527d974F8a1c97E1bEA4EF910BC

/execute


Failed to download repo vuejs-templates/vue-webpack-chrome-extension-template: Response code 404 (Not Found)

Hi,
Initialization of the new project that was shown on the main page does not work.
vue init vue-webpack-chrome-extension-template my-project
vue-cli · Failed to download repo vuejs-templates/vue-webpack-chrome-extension-template: Response code 404 (Not Found)
Adding ALiangLiang/ before the template name - works fine:
vue init ALiangLiang/vue-webpack-chrome-extension-template my-project

Thanks for your report. Already update README.


Allow disabling avatar

Hi, nice idea to port! I'd like to be able to disable the avatar, made it available by default.
C.

I'm going to reject and close this pull request as I don't see the need for this functionality to be supported.
I think if you want this functionality supported, you can add this within your own project by extending summary.html and adding the param to your config.toml.
If I was going to support something like this I would probably add this to summary.html:
{{ if .Site.Params.profile.avatar }}
<img class="resume-profile-image mb-3 mb-md-0 mr-md-5 ml-md-0 rounded mx-auto" src="{{ .Site.BaseURL }}assets/images/{{ .Site.Params.profile.avatar }}" alt="image">
{{ end }}

and then if there is no avatar param set in the config then the avatar will be disabled.
J.K.

Well I thought everybody doesn't want his face on his resume, it's not always customary depending on the country.
Your if implementation is way simpler, didn't think about it thanks.
C.

Make sure you pull latest. I've added the functionality as described in the above comment. You don't need to override summary.html any longer - just comment out the avatar param.
J.K.

And by the way, your comment is fair - thanks for your input.
J.K.

Updated my subrepo and it works, don't know why it didn't when I tested locally
Thanks for taking the time and adding it to the theme
C.

No problem. If you think of anything else then maybe create an issue. We can discuss, and if it makes sense I'll either make an enhancement, or suggest you submit a pull request.
Thanks again,
J.K.
p.s. I'm planning to add a blog theme from the same author soon - when I have the time.


Some doubts about the paper and code

Excuse me for a moment. I don't seem to see how the obstacle avoidance logic between robots is implemented in your paper. Can you briefly explain it

I mean the avoidance process between robots during exploration

Hi @FFuChen
I have not implemented that. But it is already taken care of to some extent by the navigation stack (the global planner).
Even though the navigation stack is meant for static obstacles, it was performing quite well. The cost map used by the global planner has a fast update rate from the laser scanner than the map used for exploration.
Additionally, the task allocator will ideally scatter robots away from one another during the whole mission.
Because of these reasons, I haven't encountered a problem during my experiments, but it might occur in certain scenarios

Thank you very much!

You are welcome


Update testThrow in StructureTests in libQuote

Similarly to https://github.com/tensorflow/swift/pull/297, I'm going to merge this PR even though Kokoro is broken (in an expected fashion) to unblock a release of a development toolchain.


Limited by RAM?

https://github.com/caiyuanhao1998/MST/blob/4e91b95e74d340f915017f8439621954ca2ed1c1/simulation/train_code/utils.py#L40
The # scenes is greater than 205 in the cave dowloaded folder. Is this number 205 determined empirically by a machine's RAM limit?

No, it is because we do not use so many images. Using fewer images can save training time.

https://github.com/caiyuanhao1998/MST/blob/4e91b95e74d340f915017f8439621954ca2ed1c1/simulation/train_code/utils.py#L40
The # scenes is greater than 205 in the cave dowloaded folder. Is this number 205 determined empirically by a machine's RAM limit?

Hello, may I ask if you can run the test.py script in the real experiment?

No, it is because we do not use so many images. Using fewer images can save training time.

@caiyuanhao1998
Using few images can save both training time and memory but will also reduce the diversity of the training samples, Right?

https://github.com/caiyuanhao1998/MST/blob/4e91b95e74d340f915017f8439621954ca2ed1c1/simulation/train_code/utils.py#L40
The # scenes is greater than 205 in the cave dowloaded folder. Is this number 205 determined empirically by a machine's RAM limit?

Hello, may I ask if you can run the test.py script in the real experiment?

No, I ran the train.py code on simulation as the reference MST/simulation/train_code/utils.py indicates. It has nothing to do with real experiments. Why asking? @dongruoyu1

https://github.com/caiyuanhao1998/MST/blob/4e91b95e74d340f915017f8439621954ca2ed1c1/simulation/train_code/utils.py#L40
The # scenes is greater than 205 in the cave dowloaded folder. Is this number 205 determined empirically by a machine's RAM limit?

Hello, may I ask if you can run the test.py script in the real experiment?

No, I ran the train.py code on simulation as the reference MST/simulation/train_code/utils.py indicates. It has nothing to do with real experiments. Why asking? @dongruoyu1

In section 5.2 of the readme file, the author provided the code for '“python test.py --template mst_s --outf ./exp/mst_s/ --method mst_s --pretrained_model_path ./model_zoo/mst/mst_s.pth”', but did not provide a pre trained model. Do you think this code is incorrect?

https://github.com/caiyuanhao1998/MST/blob/4e91b95e74d340f915017f8439621954ca2ed1c1/simulation/train_code/utils.py#L40
The # scenes is greater than 205 in the cave dowloaded folder. Is this number 205 determined empirically by a machine's RAM limit?

Hello, may I ask if you can run the test.py script in the real experiment?

No, I ran the train.py code on simulation as the reference MST/simulation/train_code/utils.py indicates. It has nothing to do with real experiments. Why asking? @dongruoyu1

In section 5.2 of the readme file, the author provided the code for '“python test.py --template mst_s --outf ./exp/mst_s/ --method mst_s --pretrained_model_path ./model_zoo/mst/mst_s.pth”', but did not provide a pre trained model. Do you think this code is incorrect?

@dongruoyu1 I think 5.2 real test code is incorrect (maybe the author is too busy :)) By pre-trained model I assume you only meant real data and I couldn't find it as well.
This is what I got when I ran it directly:
https://github.com/caiyuanhao1998/MST/issues/36


Adding new addons should work automatically with other instances

If my instance is auto-deploying from github, adding a new addon (i.e. pusher) should automatically happen. Not sure if Heroku supports this, but perhaps there is a configuration thing we can fix.

Yeah, I don't think it does - see http://stackoverflow.com/a/38753156/452684
That said, could we add this as a post deploy task? Like running heroku addons:create pusher:free, but whether this would work on the actual Heroku instance itself I don't know

Or maybe we've reached the limit of what we can do using app.json, and we should switch to using the Heroku Platform API?

@pezholio bothan-deploy does this now, right?

Not yet, but it's unlikely Bothan is going to evolve any more to need any new addons anyway

@pezholio could we close this ticket per your observation that current Bothan is not going to need any new addons - and withhold the question of whether its possible or not to some future subsequent iteration of bothan that necessitates its consideration?

It's low priority for sure.

PR https://github.com/theodi/bothan/pull/280 is wrangling with the same issues


Do not run benchmarks on Travis CI

As far as I can tell, we are not using CI benchmark results and they may be unreliable. With this change, they will still be built and return compilation errors, but they will not run on Travis.

Coverage remained the same at 81.02% when pulling 27dd0ea94e241f482cad73c595879a5431f84a1e on rzumer-patch-6 into dc15476cb8a3d552488e9138dc0585d775a13749 on master.

Compared to #1458, this cuts the total build time by over 10 minutes.


Move to one-way data binding for all input elements

Migrate away from the two-way binding semantics of the {{input}} helper.
https://github.com/DockYard/ember-one-way-controls is a great solution here
EDIT: or even native input elements
    <label>Some Thing</label>
    <input id="blah" value={{thing}} oninput={{action (mut thing) value="target.value"}} value="Random" />

@alexdiliberto Excellent, this will provide an opportunity to solve issue #32 as well.


add search functionality

On the top of all pages, next to the login buttons is a maginifying glass. This should link to a search page so people can search lessons by name

Relesed with v1.1


dockercontainer.py cleanup to pass flake8 --max-complexity=10

Cleaned dockercontainer.py, added a test, and adapted a test that was relying on some internal fields of the DockerContainer class that changed with this cleanup.

Current coverage is 89.58% (diff: 85.91%)

Merging #142 into master will decrease coverage by 0.01%

@@             master       #142   diff @@
==========================================
  Files            22         22
  Lines          2432       2438     +6
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           2179       2184     +5
- Misses          253        254     +1
  Partials          0          0

Powered by Codecov. Last update eb31c9c...fb4a230

for #142


Losing maps?

Hi there,
I've gotta ask, are you resetting the database or intentionally deleting maps after a period of inactivity? I've logged in twice (after absences) and both times the previous map I created was gone and it prompted me to create a new one.

Ups totally forget about that issue :(
Yes private maps are deleted after a period of 7 days.
check: https://www.pathfinder-w.space#pf-landing-maps


feat: upgrade neutron to v4 on mainnet fork #NTRN-284

Task: https://hadronlabs.atlassian.net/browse/NTRN-284
Related PRs:
https://github.com/hadronlabs-org/rehearsal/pull/9
List of changes:

Added PreBlocker call for Upgrade module.
Registered parameters for IBC client and IBC connection modules.
Registered migrations for IBC transfer module (from 3 to 4 and from 4 to 5).

Test run: https://github.com/neutron-org/neutron-tests/actions/runs/9111047035


Add post-* hooks

This commit adds post-* hooks where the after hooks were originally defined. After hooks are moved to happen straight in sequence after the after-*-chroot hooks.
The main motivation for such a change is having a hook that includes the partition, the running system and the deployed image all mounted and easily accessible.
Signed-off-by: David Cassany<EMAIL_ADDRESS>

The main motivation for such a change is having a hook that includes the partition, the running system and the deployed image all mounted and easily accessible.

For instance, this turns to be relevant to run an after-install hook to copy RPi firmware to EFI partition. Another example, could be having an after-upgrade hook that arranges grub depending on the grub.cfg in state partition vs the grub.cfg in the new OS.

This PR is being tested within elemental-toolkit in https://github.com/rancher/elemental-toolkit/actions/runs/3738250925

Missing docs and examples (wink) but otherwise +1

Yes, docs will be added in a follow up PR in elemental-toolkit.


How to predict the result of your stacking process

Hi,
First thanks for your work, I'm pretty existing to test it and play with it !
I search on documentation and examples but can't find it. I would like to use my stacking process and predict the result (like .predict() in Scikit)
I made a notebook to illustrate my problem.
I'm pretty sure I miss something...
A.

Hi,
Unfortunately there is no such a function.
This package designed for quick experiments.
You can join X_validation with X_train and then specify train/test indices for validate method.
Or you can simply replace X_test with X_validation.
d = Dataset(X_train+X_validate, y_train, X_test)
# Positional indices
train_ind = np.array(range(0, 70))
X_validate_ind = np.array(range(70, 100))
...
# Validate using X_validate_ind
stacker.validate(k=1,scorer=mean_absolute_error,indices=(train_ind,X_validate_ind))

# Get results for X_test
results = stacker.predict()
mean_absolute_error(y_test, results)

I will definitely fix this problem in a future.
Heamy doesn't know how to save internal state for every ml package. So it's not an easy task if you go beyond skickit-learn.

Thanks for your answer.
So I can't use it (currently) to submit my prediction to a Kaggle contest (sad) .
I'ill follow the dev of Heamy

@armgilles You can definitely do this :).
I use it only for kaggle.
Snippet from bimbo competition:
def first_dataset():
    drop_list = ['Town', 'Demanda_uni_equil', 'Ruta_SAK', 'Dev_proxima', 'short_name_processed', 'brand', 'Canal_ID',
                 'Venta_uni_hoy', 'Venta_hoy', 'State', 'Producto_ID', 'Agencia_ID', 'NombreProducto',
                 'Dev_uni_proxima',
                 'Semana', 'Cliente_ID', 'id']

    train = pd.read_hdf('data/train.csv')
    test = pd.read_hdf('data/test.csv')
    y_train = train['Demanda_uni_equil']
    ...

    return {'X_train': train, 'X_test': test, 'y_train': y_train}

def xgb_model(X_train, y_train, X_test, y_test=None, random_state=9999):
    params = {
        'objective': 'reg:linear',
        'learning_rate': 0.02,
        'max_depth': 20,
        'subsample': 0.8,
        'colsample_bytree': 0.8,
        'seed': random_state,
        'num_estimators': 100,
        'silent': 1,
        'tree_method': 'exact',

    }
    na_value = np.nan

    X_train = xgb.DMatrix(X_train, label=y_train, missing=na_value)
    model = xgb.train(params, X_train, params['num_estimators'], maximize=True, )
    return model.predict(xgb.DMatrix(X_test, missing=na_value))

def submit(predictions, name):
    print predictions.shape
    df = pd.read_csv('data/sample_submission.csv')
    df['Demanda_uni_equil'] = predictions
    df = df[['Demanda_uni_equil', 'id']]
    if not os.path.exists('submissions'):
        os.mkdir('submissions')
    df.to_csv('submissions/%s.csv' % name, index=False)

ds = Dataset(preprocessor=first_dataset, use_cache=False)
pipe = ModelsPipeline(
    Regressor(dataset=ds, estimator=xgb_model, use_cache=True),
    Regressor(dataset=ds, estimator=xgb_model2, use_cache=True),
    ..
)
stack_ds = pipe.stack(k=4, seed=333, add_diff=True)
stack_model = Regressor(dataset=stack_ds, estimator=xgb_stack, use_cache=True, parameters={'random_state': 1123567})
# Get predictions for test
predictions = stack_model.predict()
# Save to csv
submit(predictions, name='res-%s' % (time.time()))

Wow congratulation for your top 10 !
The dataset was pretty huge, your CPU burned a lot I guess :)
Yeah I think you did a pretty heavy features selection + tunning + ensemble to reach this score.
A.

@rushter
hi, could you please upload the file with description of your approach once again? The link is broken now...

@unnir There was no description, just a screenshot of my project structure.


[vid2seq] Access to the ASR data

@antoyang  @a-nagrani  Dear authors, thanks for the great work. Could you please provide the transcribed ASR data of the YouCook2 and AcitivityNet Captions datasets you used in the experiments so that more followers could reproduce your results on these downstream datasets?
I know that we can produce ASR data by utilizing open-sourced ASR models, calling commercial APIs, or processing the subtitle data from YouTube. However, I believe that access to your original ASR data used in the paper would contribute to the reproducibility of your work.

Hi, unfortunately, releasing ASR data is not possible.

Thanks anyway. I'm trying to reproduce the results in Huggingface Transformers and PyTorch, so I may propose other questions if I encounter some potential issues. Thanks again for your patient response.


Weirdness when resyncing block chain with unconfirmed transactions

Just started using this from fdroid (version 1.072).
Had around 0.1btc which I transfered a few days ago in, then today I sent out some transactions and while they were still unconfirmed I refreshed block chain then they displayed as incoming with the change amount. Or it groups them together. Finally displayed right after everything confirmed. Weirdly the balance in the top displayed correct all the time. I've attached some screenshots showing what I saw.

Third image is correct. First one shows incoming change? Second one has a missing transaction from the other day and has yet a different incoming value.

Well, this is a complicated issue. Technically, I think, what's happening is wallet receives a spent unconfirmed transaction from connected node's mempool before it receives a "spent-from" transaction  which causes such a behavior.
Unfortunately, I don't think I'm qualified enough to edit bitcoinj's internals which govern the related logic. In general, unconfirmed transactions currently don't do well with lite wallets (https://btcontract.com/#unconfirmed-transactions), lots of weird stuff can happen before transaction is finally confirmed.

Yeh. Was  just a bit confusing. If it is an issue with underlying library then potentially can close this as it is correct now. Thoughts?


Array generated from library breaks forge test

Using an array, here a bytes32 one, from a library makes forge test fails silently, not quite sure. It will simply output :
forge test
compiling...
success.

Here's a PoC to reproduce the bug.
pragma solidity 0.8.11;
import "ds-test/test.sol";

library Constants {
    function getArray() public view returns (bytes32[] memory) {
        bytes32[] memory proof = new bytes32[](3);
        proof[0] = 0x06570d1dea13d007b7788ef942a8b8b7633bcae9a45d1f37355a5105ca3fd5cb;
        proof[1] = 0x8e9049b131eac705735dc3d211d68e5b06e76664ed4fb427bacbf0f72c44fb96;
        proof[2] = 0xccdb13fad8ae8682a348b83d401c1d492d633ec2b0182cdbcbfc143ff0ca7973;
        return proof;
    }
}

contract Test {
    bool public ingested;

    function ingest(bytes32[] calldata array) public {
        ingested = true;
    }
}

contract FaultyTest is DSTest {

    Test test;

    function setUp() public {
        test = new Test();
    }

    function test_ingest() public {
        test.ingest(Constants.getArray());
        assertTrue(test.ingested());
    }

}

This is because the getArray() function is public and as a result requires library linking. If you change it to internal (which will get it inlined) it works. Duplicate of #222


feature request: PSIJ submission via ssh

This will support #74.  Probably best based on Paramiko as the (I think) most widely supported ssh lib in Python land

Question: are we talking about running a remote command through SSH or remote submission (e.g., to SLURM) via SSH?

Speaking from the RCT perspective: we ultimately need the latter (remote submission to batch), but I currently would favor the approach to use the ssh executor to bootstrap and launch a PSIJ Rest or ZMQ service on the target machine and then proxy all executor requests to that service.  So the ssh executor would need to only run commands really. As such, it would be basically a duplication of the local fork executor doing the same things over paramiko.
Any thoughts on this?
FWIW, we are happy with psij over ZMQ and REST at the moment.  The ssh bootstrapping is a nice to have and I want to sink some time into this over the next weeks, thus the issue to track this activity, but it's not a showstopper for us ATM.

Speaking from the RCT perspective: we ultimately need the latter (remote submission to batch), but I currently would favor the approach to use the ssh executor to bootstrap and launch a PSIJ Rest or ZMQ service on the target machine and then proxy all executor requests to that service. So the ssh executor would need to only run commands really. As such, it would be basically a duplication of the local fork executor doing the same things over paramiko.
Any thoughts on this?
FWIW, we are happy with psij over ZMQ and REST at the moment. The ssh bootstrapping is a nice to have and I want to sink some time into this over the next weeks, thus the issue to track this activity, but it's not a showstopper for us ATM.

That's precisely what Coasters do/did in Swift/K, and it was a nice turn-key solution that required no interaction from the user (except a one-time setting up of credentials).
Given that we both had tried this and seen it to work well, I'm in favor of it.
It was also useful for setting up poor man's clusters.
The Swift SSH provider was a bit more complex than local, since it used on-demand SSH channels over cached connections to avoid initiating fresh connections for each job. We may not want to do that in a first iteration, but it did prove more robust for high-throughput situations.

The Swift SSH provider was a bit more complex than local, since it used on-demand SSH channels over cached connections to avoid initiating fresh connections for each job. We may not want to do that in a first iteration, but it did prove more robust for high-throughput situations.

That reflects what SAGA does did with surprising precision.  Ack on both: this being potentially much faster and resource friendly, but also more complex and with low priority (for now).


Quitting a  plugin

Right now, quitting a plugin using this lib is a mess, one basically has to call process::exit(_) and tear it all down from a task. What are our options?
Some thoughts:

Quitting happens upon a message from neovim, so we need to handle that. I tend to call this "quit", and just use a notification. Maybe just hardcode this? Maybe the name could/should be some kind of configuration option?
We probably also want to quit from out own code? If a task decides something went wrong, maybe he wants to signal the application to quit. How to do that? If nothing else, nvim.eval("rpcnotify(_, 'quit')") is possible, which we could wrap in a method on the requester.
What should happen on quitting? The io task should finish, so the main function that spawned it can notice and do whatever needs to be done. Need to return something useful from the io task then.

What to do about the other tasks that might still be running? I asked here, but got no answer.

Maybe collect the join handlers of all tasks globally?

Ideas welcome. MVP would be to handle a quit notification by returning from the handler.

Implemented by https://github.com/KillTheMule/nvim-rs/commit/1df9ae0d35e83bce4bdf234f8f347159f40c4e66


vue-devtools may crashed by npm package

Version
5.3.3
Browser and OS info
Chrome v83.0.4103.116
Steps to reproduce

install vue-seamless-scroll by npm tool
using on the vue website during developing
vue-seamless-scroll may have reproduction repeatly, you can finding this situation in the vue - event panel.
(I guess) those events are increase rapidly, seems this situation make vue-devtools stunk.
once you need the vue-devtools work, you may need to disable the extension by chrome and/or restart the browser.

What is expected?
No idea!
Extension just stunk by other npm package,
it work correctly on record everything then crashed on it.
What is actually happening?
extension could work with vue-seamless-scroll in some situation.

Hi, @PoChenKuo . I can not reproduced it with version 6.0.0 beta 15. Does this issue still exists on v6?


Revert "Enable EditorPlugin added by modules and GDExtensions"

Reverts godotengine/godot#90608

The PR was incorrect, it was a misunderstanding on my part regarding the behavior of EditorPlugins :disappointed:. See https://github.com/godotengine/godot/pull/90608#discussion_r1590203153.

Thanks!


groupBy example

Hey,
I am using this lib and it is really easy to work with but I could not find anything mentioning how to groupBy results. Any idea?

Is groupBy some sort of limitation of this lib?

Hello, good question !
I will check it when i can ^^ if you have time too, i´m open for PR

After checking the documentation, the groupBy API is very different to findMany API.
To be honest, If you have time to do a PR, I will check on it, but personally I don't see an urgent need.

Many thanks for the reply. I also thought that is the case since with the current implementation of this lib it is hard to incorporate groupBy. But I do not think it is impossible. As for the PR IDK, TBH I am a bit short on time right now, developing my own proj. But will consider it surely @qlaffont.


Hydra dsg builder not found

Hi. I am really impressed by your work and I am trying to run the Quickstart section. I navigated to catkin_ws. I then sourced the path to source /home/adam/catkin_ws/devel/.private/catkin_tools_prebuild/setup.bash.
I then run:
roslaunch hydra_dsg_builder uhumans2_incremental_dsg.launch start_visualizer:=true
but get response:
RLException: [uhumans2_incremental_dsg.launch] is neither a launch file in package [hydra_dsg_builder] nor is [hydra_dsg_builder] a launch file name

Hi, thank you for your interest in our work! Looks like there's a typo in the path you're sourcing, you should likely be sourcing /home/adam/catkin_ws/devel/setup.bash instead.


gone through team leader onboarding

typo fixes, slight shortening, reorganize where I thought it was helpful

@samumantha

👍
The thought about separating tips and tricks and background section was to separate it as "reading material", ie not to go through it during the onboarding.
Would you go through all of this page during onboarding?

During on-boarding I would skip few sections. We can also put the "background" back if that helps.

Two comments/questions:

The path ahead section is gone now? I thought it was nice to mention this for interested team leaders as we don't really have an official debriefing (where it would fit better?) Having gone that way, I found it helpful to know that there is different ways to get involved and that the project is open to it.

the "please do not" section: if you want to have it as part of the onboarding I would get back the short version of this point from before my PR, not this very verbose version.

During on-boarding I would skip few sections. We can also put the "background" back if that helps.

We could put the sections that are skipped in bottom?
I was trying to find a better place for the background section, but didn't find a good one. Should maybe not be here at all?
Maybe there could be it's own background section in the manuals, where all the info on how CR workshops were done at certain point in time and background info on decisions made is presented?

OK I will:

bring back the path section
try to shorten the "what we try to avoid"
reorder with most important on top, what can be skipped on bottom

Later we can move the "background" stuff to some other pages but I am now out of time :-)

Looks good and ready to merge


fixed MIGRATE function when key is array

Description
Fix for https://github.com/redis/node-redis/issues/2163
cc: @leibale

Checklist

[ ] Does npm test pass with this change (including linting)?
[ ] Is the new or changed code fully tested?
[ ] Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

Codecov Report

Merging #2184 (e0bb2e4) into master (d2bba1d) will decrease coverage by 5.12%.
The diff coverage is 100.00%.

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

@@            Coverage Diff             @@
##           master    #2184      +/-   ##
==========================================
- Coverage   95.86%   90.74%   -5.13%
==========================================
  Files         430      430
  Lines        3964     3964
  Branches      447      447
==========================================
- Hits         3800     3597     -203
- Misses        101      304     +203
  Partials       63       63

Impacted Files
Coverage Δ

packages/client/lib/commands/MIGRATE.ts
100.00% <100.00%> (ø)

packages/client/lib/commands/FUNCTION_LOAD.ts
16.66% <0.00%> (-83.34%)
:arrow_down:

packages/client/lib/commands/ZRANGESTORE.ts
20.00% <0.00%> (-80.00%)
:arrow_down:

packages/client/lib/commands/FUNCTION_FLUSH.ts
20.00% <0.00%> (-80.00%)
:arrow_down:

packages/client/lib/commands/FUNCTION_RESTORE.ts
20.00% <0.00%> (-80.00%)
:arrow_down:

packages/client/lib/commands/GETEX.ts
21.42% <0.00%> (-78.58%)
:arrow_down:

packages/client/lib/commands/COPY.ts
33.33% <0.00%> (-66.67%)
:arrow_down:

packages/client/lib/commands/CLIENT_NO-EVICT.ts
33.33% <0.00%> (-66.67%)
:arrow_down:

packages/client/lib/commands/ZINTER.ts
36.36% <0.00%> (-63.64%)
:arrow_down:

packages/client/lib/commands/GEOSEARCHSTORE.ts
36.36% <0.00%> (-63.64%)
:arrow_down:

... and 60 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d2bba1d...20c4b87. Read the comment docs.

@StefanCenusa tnx! :)


v3

Preparation for major release v3.

[ ] Drop Node 10 & Node 12
[x] Lerna v7 update
[ ] Lerna v7 Node 14 fix (reported https://github.com/lerna/lerna/issues/3854)

Lerna inofficially dropped support for Node v14 at some point.


Update the ML repo package name

(wait to merge until the package is actually updated)
We'll probably want to cherry-pick this back into the digits-4.0 branch, too.

Cherry-picked into digits-4.0: https://github.com/NVIDIA/DIGITS/commit/9354569758e517b77be6c49887fa6d0b0a6f16eb


fix: change atomic value 'breadcrumb' correctly

Description

Task Item

Screenshots

Duplicated with changes in TJ's on-going PR #3938. Mark as closed.
Based on TJ's PR, the fix is at https://github.com/tdurnford/BotFramework-Composer/pull/1 .


Build fails without ONNX_MLIR_ACCELERATORS option after PR#1977

It seems build fails when configuring without -DONNX_MLIR_ACCELERATORS=NNPA. I didn't see this before #1977 .
CMakeFiles/OMInitAccelerators.dir/InitAccelerators.cpp.o: In function `mlir::Operation::debug_getSuccessors()':
InitAccelerators.cpp:(.text._ZN4mlir9Operation19debug_getSuccessorsEv[_ZN4mlir9Operation19debug_getSuccessorsEv]+0x12): undefined reference to `mlir::SuccessorRange::SuccessorRange(mlir::Operation*)'
collect2: error: ld returned 1 exit status
src/Accelerators/CMakeFiles/OMInitAccelerators.dir/build.make:104: recipe for target 'Release/lib/libOMInitAccelerators.so' failed
make[2]: *** [Release/lib/libOMInitAccelerators.so] Error 1
CMakeFiles/Makefile2:12920: recipe for target 'src/Accelerators/CMakeFiles/OMInitAccelerators.dir/all' failed
make[1]: *** [src/Accelerators/CMakeFiles/OMInitAccelerators.dir/all] Error 2

Can other corroborate this? I am building on x86 with this:
mkdir onnx-mlir/build && cd onnx-mlir/build
if [[ -z "$pythonLocation" ]]; then
  cmake -G "Unix Makefiles" -DCMAKE_CXX_COMPILER=/usr/bin/c++ -DMLIR_DIR=/workdir/llvm-project/build/lib/cmake/mlir -DONNX_MLIR_ACCELERATORS=NNPA ..
else
  cmake -G "Unix Makefiles" -DCMAKE_CXX_COMPILER=/usr/bin/c++ -DMLIR_DIR=/workdir/llvm-project/build/lib/cmake/mlir -DONNX_MLIR_ACCELERATORS=NNPA -DPython3_ROOT_DIR=$pythonLocation ..
fi
cmake --build .

# Run lit tests:
export LIT_OPTS=-v
cmake --build . --target check-onnx-lit

which includes NNPA and I have not seen any problems. I typically nuke the entire build dir when upgrading LLVM, as well as the onnx-mlir/third_party and rebuild onnx using pip.

He's saying it fails without NNPA specified.
Here is what is likely causing that error:
There are several places in the CMake code where the upstream target MLIRIR is either missing or specified in the DEPENDS section of an add_(onnx mlir)_library command.
These should be corrected to be placed under LINK_LIBS PUBLIC, as it is a link dependency. I only fixed the minimum needed to pass CI.
I'm not sure what changed between the old LLVM version and the new one that causes this issue to appear; it's surprising that it didn't surface before. My guess is that either upstream cmake function changes or changes in the dependency graph caused MLIRIR previously to be linked in transitively to most targets, but that is no longer the case.

I'll put the PR up

Thanks for the quick PR

@christopherbate Thanks for the fix!


InteractiveViewer + CustomMultiChildLayout: initially invisible widgets are not clickable

I'm trying to create clickable board of widgets by InteractiveViewer + CustomMultiChildLayout but have some unexpectable problem: all widgets (and their's parts) which appeared on visible part of the board are totally clickable. But all other widgets which appeared on invisible part of the board are totally unclickable.
Screen 1 - it is basicly visible part of board and you see what tap on one of the bricks showed snackbar.
Screen 2 - it is all board with all bricks after scaling (by interactiveViewer). If tapped on bricks from screen 1 (for example - brick 6) snackbar will be appeared. But if tapped on bricks which was basicly invisible (for example - brick 2) - there was no effect. Snackbar wasn't shown and nothing work.
So tell me please - what I need to do to make all bricks clickable? What's wrong with my code?
Body of main scaffold - InteractiveViewer:
    Container(
      child: InteractiveViewer(
        boundaryMargin: EdgeInsets.all(boardSize * 2),
        onInteractionEnd: (details) {
          getBricks();
        },
        child: CustomMultiChildLayout(
          delegate: BoardLayoutDelegate(
            bricks: bricks,
          ),
          children: [
            ...getBricks(),
          ],
        ),
      ),
    );

Delegate of CustomMultiChildLayout:
  void performLayout(Size size) {
    bricks.forEach((brick) {
      //Check every brick
      if (hasChild(brick.id)) {
        layoutChild(
          brick.id,
          BoxConstraints.expand(
            width: SizePro.brickWidth,
            height: SizePro.brickHeight,
          ),
        );
        positionChild(
          brick.id,
          Offset(brick.centerX - SizePro.brickWidth / 2,
              brick.centerY - SizePro.brickHeight / 2),
        );
      }
    });
  }

Full project on gitlab
Thank you for your attention

Reproducible on latest stable channel. Not really sure if the implementation is causing the issue.
Here is a visualization of the issue, you can't click on the items that were invisible when InteractiveViewer was built.
Cc @justinmc

flutter doctor -v
[✓] Flutter (Channel stable, 1.22.1, on Mac OS X 10.15.7 19H2, locale en)
    • Flutter version 1.22.1 at /Users/pedromassango/dev/SDKs/flutter_stable
    • Framework revision f30b7f4db9 (7 days ago), 2020-10-08 10:06:30 -0700
    • Engine revision 75bef9f6c8
    • Dart version 2.10.1

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.1)
    • Android SDK at /Users/pedromassango/Library/Android/sdk
    • Platform android-30, build-tools 30.0.1
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.0.1, Build version 12A7300
    • CocoaPods version 1.9.3

[!] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] IntelliJ IDEA Community Edition (version 2020.2.3)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin installed
    • Dart plugin version 202.7319.5

[✓] VS Code (version 1.48.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.14.1

[✓] Connected device (1 available)
    • iPhone 11 Pro Max (mobile) • 913ADC1E-400E-4AA0-8302-D955869FF1C9 • ios • com.apple.CoreSimulator.SimRuntime.iOS-13-5 (simulator)

! Doctor found issues in 1 category.
Process finished with exit code 0

Updating title to describe the issue better.

@pedromassangocode thank you so much for quick visualisation and updating!
Waiting for solving..

The solution here is to set constrained: false on InteractiveViewer and implement getSize on BoardLayoutDelegate.
Currently, your CustomMultiChildLayout is sizing itself to the size of the screen, but you are drawing outside of its size.  When you pan it and tap on one of the bricks that was initially offscreen, you are tapping on empty space, not on the CustomMutliChildLayout.  The problem could be visualized by wrapping CustomMultiChildLayout in a ClipRect:

By implementing getSize and returning the actual size of your widget (bigger than the screen size), Flutter know how big this widget actually wants to be.  When you also set constrained: false, then the screen size constraints are relaxed, and Flutter is actually able to make your widget as big as it wants.   Then all of your bricks are contained inside the CustomMultiChildLayout and able to receive events.
I'm going to update the docs a bit to explain this.  Thanks for bringing this to my attention!

Thank you for you answer!
It's working but only for right and bottom sides of the screen. Left and top almost unclickable.
I set constrained: false,  implemented getSize, colored CustomMultiChildLayout by amber and taken a new screenshot. It's here
So how can I changing the position of interactive part of CustomMultiChildLayout?  Maybe I can set a center of sizable area?
PS repository updated

Ah I didn't think of that, you're right that this needs something else.  From here I think you need to:

Render the bricks inside of the CustomMultiChildLayout.
Position the CustomMultiChildLayout so that the bricks appear centered.

For 1 you'll have to modify BoardLayoutDelegate so that it draws the bricks centered in the Size that performLayout receives.  All the bricks should fully fit within the amber box in your screenshot.
Once you've done that, for 2 you need to center the CustomMultiChildLayout (inside of InteractiveViewer).   I'm sure you can do that manually with a Positioned widget.  There might be a nicer solution than that, but I don't think a Center will work.

Thought about it but also thought what this problem have another solution..
First step is ok. But the second step has got some problem. Center doesn't work, Positioned moving bricks on the CustomMultiChildLayout  without CustomMultiChildLayout:
Result after first step and second step
So both of them positioned CustomMultiChildLayout's left-top-corner into left-top-corner of initial screen..
My code for this:
InteractiveViewer(
        constrained: false,
        scaleEnabled: true,
        minScale: 0.1,
        maxScale: 10.0,
        boundaryMargin: EdgeInsets.all(boardSize),
        onInteractionEnd: (details) {
          getBricks();
        },
        child: Container(
          color: Colors.amber,
          width: boardSize,
          height: boardSize,
          child: Stack(
            children: [
              Positioned(
                width: boardSize,
                height: boardSize,
                left: boardSize / 2,
                child: CustomMultiChildLayout(
                  delegate: BoardLayoutDelegate(
                    bricks: bricks,
                    boardSize: boardSize,
                    offset: (boardSize / 2) - (SizePro.screenWidth / 2),
                  ),
                  children: [
                    ...getBricks(),
                  ],
                ),
              ),
            ],
          ),
        ),
      ),

What else I can do with Positioned to achieve needed result? Or maybe I need to use another widget?

I updated the repo but I think something else has changed as I had trouble getting the bricks to be visible.
Can you not position the bricks using the left parameter of Positioned?  Maybe make it negative.

Thank you! But I don't see any updates in repo..

Sorry, I meant that I did git pull in my local checkout of your repo, but couldn't get the bricks onscreen.

Yeah, sorry, it's happened because of positioned. I removed all about positioned and updated repo. Bricks are visible now.

Ok I see, thanks for updating that.  Unfortunately I'm having trouble centering it using widgets as well due to the infinite constraints...  I think what you'll need to do is to use TransformationController to set the initial translation of your child.  So with a default transformation matrix of Matrix4.identity, the child will be aligned to the top left corner of the screen, as we see now.  If instead you set the value of transformationController to Matrix4.identity()..translate(-boardSize / 2), then it should be centered.

It's exactly what I need! Thank you so much!

Awesome!  Glad we got it. 🎉


docs: fix deprecation config for default runtime

based on https://github.com/containerd/containerd/blob/master/pkg/cri/config/config.go#L305, we still can use

[plugins."io.containerd.grpc.v1.cri".containerd.default_runtime]
[plugins."io.containerd.grpc.v1.cri".containerd.untrusted_workload_runtime]

Alo fix typo plugins."io.containerd.grpc.v1.cri".runtimes to plugins."io.containerd.grpc.v1.cri".containerd.runtimes.

You will have to sign your commit with the proper DCO based on the contributing docs

@mikebrow adding signoff to the commit. Thanks

@zufardhiyaulhaq Please use your name, not your GitHub handle, in the Signed-off-by line.  See our contribution guidelines.

Hi is there anything else that I can do?
@mikebrow

/ok-to-test

docs fix, so the CI jobs shouldn't matter (flakes)


linux-96boards: update to 16.06

Signed-off-by: Koen Kooi<EMAIL_ADDRESS>

unrelated to the change but I noticed the compatible machine list contains "vexpress-juno". I think it's misnamed. The versatile express product family contains Juno and the Versatile Express CoreTile boards, which we commonly call the latter vexpress. It also reflected in the dtb name. Probably something to fix in a separate commit.

I picked the name optee uses for juno, I have no preference for naming it, 'juno' would be fine by me as well. Let me know what you want and I can fix up the commit.

simply "juno" then. Thanks!

done


updated to new url

issue #3

Please merge this. Meanwhile, how can we make this change locally?

I've update with newest url. Thanks!


Icons at bottom of window cover up "Undo Send" button

Screenshot should be self-explanatory.  Icons covered up my ability to click "Undo send".

Thank you for your report. I have released Ver. <IP_ADDRESS> which fixes the overlapping issue.


Can you provide the code for DDIM sampler

I try to change the ‘sample_method’ hyperparamter to 'DDIM' in Latte/configs/t2v/t2v_sample.yaml, which make the bad performance of the output image. can you provide some scripts for DDIM sampler, or is that model can not work well when using DDIM sampler?
Sicnerely

I try to change the ‘sample_method’ hyperparamter to 'DDIM' in Latte/configs/t2v/t2v_sample.yaml, which make the bad performance of the output image. can you provide some scripts for DDIM sampler, or is that model can not work well when using DDIM sampler?
Sicnerely

I will provide the DDIM sampling method in the future, but I am not sure when it will be ready. If you already have a handle on DDIM's sampling method, welcome to PR.


Osmnx reading .osm file converter

Hello !
I read xml file like .osm
I use osmosis to convert file pbf to .osm  and then open with  ox.graph_from_xml(
But, then, I get an error TypeError: loop of ufunc does not support argument 0 of type float which has no callable deg2rad method xml

Thanks for using OSMnx! Please re-read the contributing guidelines and the new issue template you saw when you opened this issue. As the template noted, your issue will be automatically closed if you didn't provide all of the information requested in the template, because we need all of this information to address your issue.


merge from template-node-app

package.json

chore(deps): add ^13.0.0 remove ^12.3.1 (devDependencies.npm-pkgbuild)

:tada: This PR is included in version 6.4.5 :tada:
The release is available on:

npm package (@latest dist-tag)
v6.4.5
GitHub release

Your semantic-release bot :package::rocket:


Three syntaxes for initialising auto-typed variables

The initialisation expression can be an assignment but that means a = b = 0.
The initialisation expression can involve operator new but it is not a separate case. Compare auto a = new int; and auto a (new int);.  There is no initialisation statement inherently involving operator new (unlike in Visual Basic).
The fact that a for loop involves an initialisation statement is a side note at best.  This trivia fact is not specific to auto.
The parenthesised "explanations" explained one unknown with another unknown.  I replaced them with short examples.

@yecril71pl : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@yecril71pl
Thanks for your considered input. I'm not sure why new was called out either. Your updated explanation is correct as far as it goes, but it's missing a mention of auto and the uniform initialization syntax. We do mention it later, but it probably should be included here, too. It's safe to defer talk about how auto will create a std::initializer_list from a braced initializer at any opportunity. And there's a reason the range-based for loop syntax gets a call-out, since it's an auto syntax variation that doesn't appear elsewhere. I will think about this, but not for a while, since I'm on vacation for a week.

@yecril71pl : Thanks for your contribution! The author(s) have been notified to review your proposed change.

And there's a reason the range-based for loop syntax gets a call-out, since it's an auto syntax variation that doesn't appear elsewhere.

I formally disagree but I have restored it since it is a typical use case.  You may have to adapt the terminology though.

@corob-msft : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@corob-msft : Thanks for your contribution! The author(s) have been notified to review your proposed change.


[BEAM-9702] Update Java KinesisIO to support AWS SDK v2

Hi @aromanenko-dev, I thought it would be a good idea to separate #9899 into two PRs so that users can potentially benefit from the update to use the v2 AWS SDK while enhanced fanout support is still being worked on. lmkwyt
FYI, I found these commands helpful for comparing v1 vs. v2:
diff -u -r sdks/java/io/kinesis/src/main/java/org/apache/beam/sdk/io/kinesis/ sdks/java/io/amazon-web-services2/src/main/java/org/apache/beam/sdk/io/aws2/kinesis/ > diff-main.txt
diff -u -r sdks/java/io/kinesis/src/test/java/org/apache/beam/sdk/io/kinesis/ sdks/java/io/amazon-web-services2/src/test/java/org/apache/beam/sdk/io/aws2/kinesis/ > diff-test.txt
diff -u sdks/java/io/kinesis/build.gradle sdks/java/io/amazon-web-services2/build.gradle

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

Yes, I agree that it will make sense to split it into several PR for clearance. In the same time, I'm more concerned that with two packages we will have a lot of duplicated code there.

Hi @aromanenko-dev, I share your concern. However, that was always going to be the case, splitting it into multiple PRs doesn’t change that, and it’s already the case for other AWS IOs such as SNS and DynamoDB. What do you propose for a solution?

@jfarr Agree, but I don't have a perfect solution except to extract and to wrap all AWS depended code into own interfaces and then use them to work with AWS. All what I'm afraid is to lose all latest fixes and improvements that we done for old KinesisIO and probably will be done in the future since people actively use it.

Hi, @aromanenko-dev. That sounds like a significant rewrite of the existing KinesisIO. Should the other AWS IOs be redesigned to fit that model too, or where does that stop? I actually like the idea, just trying to clarify what you have in mind.
And don't you think that the same clearance logic applies here? A rewrite is going to take some time, probably a significant amount. Why not get this PR into the hands of the community so they can start using it now and then do the refactor in a separate PR?

@jfarr I agree with your point but I'm afraid that once we will have two versions of KinesisIO (for AWS SDK 1 & 2), that are based on the large amount of the same code but existing in two different packages , then we will need to always keep in mind to do code changes in two places. I'd definitively want to avoid it since these KinesisIO will diverge quickly and I'm not sure that we will deprecate and remove the AWS SDK V1 version soon.
Well, maybe it will be a good point to discuss this on dev@ mailing list and to hear what the community think about it.

@aromanenko-dev Good idea, I started a new thread.

@jfarr I think that the main conclusion of this thread (as @iemejia properly reminded there) is that we should start the deprecation of AWS SDK V1 based IOs. So I agree that it won't make sense to extract any common code and create the new abstractions to support both versions of AWS SDKs.
In the same time, to finish this PR, please update the code with the latest changes in KinesisIOV1 to keep it up-to-date (if any.)

@jfarr Sorry for delay with a response, I took another look and it LGTM. Could just rebase one more time against master and after we can merge it (if all checks pass)?

@jfarr Btw, do you think we could implement KinesisIO.Write with AWS SDK v2 in effective way (since KPL is still on SDL v1)?

Hi @aromanenko-dev, I ported over a few more missing commits from v1 and rebased:
9e10b54
1e182c6
ecedd3e
248b794
Please LMK when you're done reviewing the changes and I'll squash them.

@jfarr Btw, do you think we could implement KinesisIO.Write with AWS SDK v2 in effective way (since KPL is still on SDL v1)?

I'm sure it's possible but it seems like it would basically entail porting the KPL to AWS v2 ourselves, so I'm not sure if it's worth the effort. What would be the value gained, besides having the reader and writer together in the same class again? In my opinion I've always felt that the way Beam IOs combine readers and writers in the same class violates single-responsibility principle, with predictable results such as this.

@jkff The reason why I'm asking about Write is because we are going to deprecate and finally remove AWS SDK v1 IOs in the future. Though, we still need to have "write" part but seems we need to wait for KPL v2 (at least for old KinesisIO).
Generally, it's not required to have Read and Write part in the same class, it's usually done just for users convenience to have them under the same name of main class and avoid confusion.


completions/zsh: add --pull-reques to search

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?
[ ] Have you successfully run brew man locally and committed any changes?

add the option --pull-request tobrew search  in zsh completions

Thanks again @hyuraku!

Thanks again @hyuraku!


Optional / Ranged precision

Using accounting.js is there a way to allow the formatter to handle the following cases:
I enter 5 and it formats it with 0 dp precision - output 5
I enter 5.1 and it formats with 1 dp precision - output 5.1
I enter 5.25 and it formats with 2dp precision - output 5.25
I enter 5.254 and it formats to 2dp precision - output 5.25
In short I want the precision to match the number of characters after the dp but only up to 2. So a range of 0-2 dp precision if that makes sense!
I would like the precision to be optional.
Posted on SO here too: http://stackoverflow.com/questions/36594706/condition-precision-or-precision-range-in-accounting-js

function currencyUSD(number) {
  return number.toLocaleString('en-US', { style: 'currency', currency: 'USD', minimumFractionDigits: 0 });
}
currencyUSD(123456); // "$123,456"
currencyUSD(123456.234); // "$123,456.23"

https://stackoverflow.com/questions/149055/how-can-i-format-numbers-as-dollars-currency-string-in-javascript/149107#149107
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toLocaleString
https://stackoverflow.com/questions/24758817/javascript-number-tolocalestring-with-4-digits-after-separator


mdTooltip with long messages show only part of it by 2 element next to each other in IE

Bug, feature request, or proposal:
Bug
What is the expected behavior?
Tooltip show completely in IE
What is the current behavior?
tolltip only show part of it in IE
What are the steps to reproduce?
in IE:

create 2 buttons next to each other
put tooltip with long messages to each of this buttons
hover between this 2 buttons
tooltip will only show part of it

Providing a Plunker (or similar) is the best way to get the team to see your issue.
Plunker template: https://plnkr.co/edit/9FWitPZdQqxujVWXAZD5?p=preview
What is the use-case or motivation for changing an existing behavior?
to improve md-tooltip performance in IE
Which versions of Angular, Material, OS, browsers are affected?
master
Is there anything else we should know?
screenshot:

This issue goes away if you add the web-animations polyfill as described in #3605.
I found some useful tips on how to install it here:
https://stackoverflow.com/questions/38836532/how-to-add-web-animations-api-polyfill-to-an-angular-2-project-created-with-angu


Notification when starting remote desktop session?

Hello, I am using the newest version of Quasar. I installed the client on my virtual machine, but when I start a remote desktop session, my Virtual machine gets a notification. The last time I used Quasar (A week ago or so) This did not happen, so I'm wondering when this was added and if there's any way to stop it. Thanks!

Fixed it

This is the setting you are looking for: https://github.com/quasar/Quasar/wiki/Client-deployment-settings#unattended-mode


incorrect typedefinition for TranslationStrings (fix suggested)

This is an incorrect type definition for TranslationStrings
https://github.com/carbon-design-system/carbon-components-angular/blob/7967695ff011a0e42761f4fcf766820bdd2e1bef/src/i18n/i18n.service.ts#L138C1-L138C60
it should in fact support nested values like in the en.ts file
i suggest to modify it to
export type TranslationStrings = {
  [key: string]: string | { [key: string]: string | TranslationStrings };
};

Thanks
latest carbon-angular-components. version

I think you are correct, but I think your suggestion can be simplified to
export type TranslationStrings = {
  [key: string]: string | TranslationStrings;
};

I created a PR where I updated the type :)


Improve the I/O for observation files

Improve the 'get_nobs*' subroutine, getting file size instead of reading through the entire file
5306f32

Remaining work:
-- Using rank-directory for obs.dat ???
-- Parallel I/O for obs.dat ???

Using rank-directory for obs.dat is allowed by #58


Incorrect status bar's image

Currently implemented status bar image is incorrect. Please, replace it with the correct one.
Expected results
Correct asset used and correct location and dimensions are implemented:

Element
gX, gY
gW, gH
aX, aY
aW, aH
Image

With logo
81, 110
168, 50
884, 1210
1847, 551

Empty
(the same)
(the same)
(the same)
(the same)

Actual results
Incorrect image and incorrect location or dimensions are currently implemented:

@MadejaMaciej Correct values are provided and this ticket is ready for development.


Support - Robot test result file

Multiple Suites
Single Suite
Multiple Test Cases
Test Suite with Failures
Test Suite with skipped tests

https://github.com/robotframework/robotframework/blob/master/doc/schema/robot.xsd


Add an automatic manner for docs output to be pushed to gh-pages branch.

OMG That took some doing.

After all of this mess, I decided to push md api docs to this repo's wiki.


dgst command should use provider-keymgmt functions for dealing with private keys

I am currently writing my own provider implementation to wrap the access to an external signature server.
Here the private key used for signature is not accessible.
Unfortunately the openssl dgst app always uses the OSSL_OP_STORE/provider-storemgmt functions and not the OSSL_OP_KEYMGMT/provider-keymgmt functions (e.g. OSSL_FUNC_keymgmt_load()) to load and pass private keys.  As result the private key must be always loadable from file system and cannot be just an abstract reference.

Store can be anything, it does not necessarily have to be a file system store. Store handles URIs - if you invent a new URI scheme for your provider you can make it called via the store call with the URI scheme.
See for example the recently added winstore store provider that adds windows certificate store support.
You need to reference the key in one way or another anyway.

But in any case I have to provide the byte sequence of a real private key  to make the apps.c:load_key() function happy?

No, you don't. The store can create a key reference that is valid within your provider only.

And you do not need to provide a keymgmt export function.


#README

#README
##User story
As a boot camp student,
I want the prework notes to be structured on a webpage,
So that I can easily find and read the information.
##Acceptance criteria
GIVEN the prework project repository,
WHEN I view the README for the repository,
THEN I can see a professional README that provides information on the project and how to use it

Meet criteria


Use deprecate-react-native-prop-types  Update package.json

Platforms affected
All
What does this PR do?
RN 0.68 has deprecated and will eventually remove ViewPropTypes (see post). This adds the deprecated-react-native-prop-types package and uses that instead.
What testing has been done on this change?
Local testing, to ensure the deprecation warning has been removed.

Will close this PR in favor of #169


Missing jars in maven central for kotest-extensions-android

Hello,
I was about to try using kotest-extensions-android, but I had a problem setting it up.
Eventually I've found out that jar are not present in maven central. Only javadoc and sources jar.
kotest-extensions-android at repo1.maven.org
I have noticed similar problem for kotest-assertions-android
Is it possible to deploy binary jars as well, please?
Also thanks for the project :)

Thanks for the report!
A fix is on the way :)

New artifacts released, please take a look ;)


[TB] Unable to de-serialize received json data with error (DeserializationError::NoMemory)

I have made the changes as in the readme, but still get the de-serialize error, the RPC is currently not firing the function.
the debug shows:
14:50:44.234 -> Subscribed to RPC methods
14:51:00.405 -> [TB] Received data from server over topic (v1/devices/me/rpc/request/387)
14:51:00.405 -> [TB] Unable to de-serialize received json data with error (DeserializationError::NoMemory)
the TB Log shows
{
"entityId": "6c5e7550-4327-11ef-86ad-337f063d8218",
"oneWay": true,
"method": "power",
"params": "true"
}
I currently have:
// ********************* start up events **********************
#define THINGSBOARD_ENABLE_DYNAMIC 1
#define THINGSBOARD_ENABLE_PROGMEM 0
#define THINGSBOARD_JSON_BUFFER_SIZE 256
#define THINGSBOARD_ENABLE_DEBUG 1
#define THINGSBOARD_ENABLE_STREAM_UTILS 1
#include <ThingsBoard.h>                // 13.0
#include <ArduinoJson.h>                // 7.1.0
#include <Arduino_MQTT_Client.h>  // 1.7.3
#include <StreamUtils.h>                   //  1.9
#include <WiFi.h>
#include <HTTPClient.h>
WiFiClient espClient;
Arduino_MQTT_Client mqttClient(espClient);
ThingsBoard tb(mqttClient);
// Enable verbose debugging output
#define DEBUG_LEVEL_TLS_ERROR
is it related to the Lib versions?
not sure if its connected,  i updated StreamUtils to 1.9 and now I get a
16:55:04.868 -> ELF file SHA256: a9b6c20fd1abb1d5
16:55:04.868 ->
16:55:04.868 -> E (337) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
16:55:04.868 -> Rebooting...
clearly an error. I can recover the core and reprogram.
any suggestions to change / remove?
thanks in advance..

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

The aforementioned error, DeserializationError::NoMemory can occur because of 2 different faults:
Either there is not enough heap memory to use the THINGSBOARD_ENABLE_DYNAMIC mode, to check that please add this code to the onMQTTMessage method.
const size_t document_size = JSON_OBJECT_SIZE(Helper::getOccurences(reinterpret_cast<char *>(payload), ':'));
TBJsonDocument jsonBuffer(document_size);
if (jsonBuffer.capacity() != document_size) {
    Logger::printfln("Could not allocate required size (%u) for JsonDocument, allocated only (%u). Ensure there is enough heap memory left", document_size, jsonBuffer.capacity());
    return;
}
....
#if THINGSBOARD_ENABLE_DEBUG
Logger::printfln("Allocated internal JsonDocument for MQTT server response with size (%u)", document_size);
#endif // THINGSBOARD_ENABLE_DEBUG

The additional log message, prints the actual size of the JsonDocument, because the only remaining option is that the internal allocated JsonDocument size is to small to hold the actual data, could be the case if the Helper::getOccurences() method does not work correctly, becuase of the reinterpret_cast<char *>(payload).
For now if you could add the above code and retry the same behaviour and send the new log messages that would help a lot with debugging this issue thanks.

Mathew hi:
I am using the 8mB ESP32, and the compile stats are:
uses 769497 bytes (23%) of program storage space. Maximum is 3342336 bytes.
Global variables use 44456 bytes (13%) of dynamic memory, leaving 283224 bytes for local variables. Maximum is 327680 bytes.
can run over the code and see what might be now corrupting the core when this loads, I have not seen that before..
this just has the 2 RPC,
can you confirm the lib versions, as I updated the StreamUtil manually from 1.7 to 1.9
or what over Lib do I need to remove and reinstall now?
// getting serialize error 9 PM Monday
// save Tuesday with error to preserve semi working
// build RPC_Subs_test_aug27a  tuesday AM
// ********************* start up events **********************
#define THINGSBOARD_ENABLE_DYNAMIC 1
#define THINGSBOARD_ENABLE_PROGMEM 0
#define THINGSBOARD_JSON_BUFFER_SIZE 256
#define THINGSBOARD_ENABLE_DEBUG 1
#define THINGSBOARD_ENABLE_STREAM_UTILS 1
#include <ThingsBoard.h>      // 0.13.0
#include <ArduinoJson.h>      //  7.1.0
#include <Arduino_MQTT_Client.h>
#include <StreamUtils.h>      // 1.9.0
#include <WiFi.h>
#include <HTTPClient.h>
WiFiClient espClient;
Arduino_MQTT_Client mqttClient(espClient);
ThingsBoard tb(mqttClient);
// Enable verbose debugging output
#define DEBUG_LEVEL_TLS_ERROR
// WiFi credentials
const char* ssid = "telstra";
const char* password = "1234";
// ThingsBoard credentials
const char* TOKEN = "abcd";
const char* SERVER = "thingsboard.cloud";
// Forward declaration of RPC functions
void processPower(const JsonVariantConst& data, JsonDocument& response);
void processRebootRPC(const JsonVariantConst& data, JsonDocument& response);
// Define RPC callbacks as a global variable
const std::array<RPC_Callback, 2U> callbacks = {
RPC_Callback{ "power", processPower },
RPC_Callback{ "reboot_device", processRebootRPC },
};
bool TB_connected = false;
bool RPC_subscribed = false;
unsigned long lastHeartbeatTime = 0;
const unsigned long heartbeatInterval = 30000;  // 30 seconds for testing
void setup() {
tb.setBufferSize(128);
Serial.begin(115200);
WiFi.begin(ssid, password);
Serial.println("   RPC_Subs_test_aug27a");
// Connect to WiFi
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println("WiFi connected");
// Connect to ThingsBoard
if (tb.connect(SERVER, TOKEN)) {
TB_connected = true;
Serial.println("Connected to ThingsBoard");
} else {
TB_connected = false;
Serial.println("Failed to connect to ThingsBoard");
}
// Initial RPC subscription
subscribeToRPCs();
}
void reconnect() {
if (!WiFi.isConnected()) {
Serial.println("Reconnecting to WiFi...");
WiFi.begin(ssid, password);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println("WiFi reconnected");
}
// Reconnect to ThingsBoard
if (!tb.connected()) {
Serial.println("Reconnecting to ThingsBoard...");
if (tb.connect(SERVER, TOKEN)) {
TB_connected = true;
Serial.println("Reconnected to ThingsBoard");
} else {
TB_connected = false;
Serial.println("Failed to reconnect to ThingsBoard");
}
}
}
void loop() {
tb.loop();
// Heartbeat check
if (millis() - lastHeartbeatTime > heartbeatInterval) {
lastHeartbeatTime = millis();
heartbeatCheck();
}
}
void heartbeatCheck() {
// Check if connected
TB_connected = tb.connected();
if (!TB_connected) {
Serial.println("Reconnecting to ThingsBoard...");
reconnect();
}
// Subscribe to RPC if not subscribed
if (TB_connected && !RPC_subscribed) {
subscribeToRPCs();
}
}
void subscribeToRPCs() {
Serial.println("Subscribing to RPC methods...");
const RPC_Callback* begin = callbacks.data();
const RPC_Callback* end = callbacks.data() + callbacks.size();
if (!tb.RPC_Subscribe(begin, end)) {
RPC_subscribed = false;
Serial.println("Failed to subscribe for RPC");
} else {
RPC_subscribed = true;
Serial.println("Subscribed to RPC methods");
}
}
// Simplified RPC handlers
void processPower(const JsonVariantConst& data, JsonDocument& response) {
Serial.println("processPower RPC triggered");
bool power_state = data.as();  // Assuming a simple true/false JSON payload
// Implement your power control logic here
Serial.print("Power State: ");
Serial.println(power_state ? "ON" : "OFF");
response["success"] = true;
}
void processRebootRPC(const JsonVariantConst& data, JsonDocument& response) {
Serial.println("processRebootRPC RPC triggered");
// Check if the data is a JsonObject
if (!data.is()) {
Serial.println("Received data is not a JSON object");
response["success"] = false;
return;
}
// Get the size needed for the JSON object in the document
const size_t document_size = JSON_OBJECT_SIZE(data.size());
// Allocate the JsonDocument with the calculated size
StaticJsonDocument<256> jsonBuffer; // Adjust size as needed
// Log the allocated size for debugging
#if THINGSBOARD_ENABLE_DEBUG
Serial.printf("Allocated internal JsonDocument for MQTT server response with size (%u)\n", document_size);
#endif
// Deserialize the incoming data into the jsonBuffer
DeserializationError error = deserializeJson(jsonBuffer, data);
if (error) {
Serial.print("Failed to deserialize JSON: ");
Serial.println(error.c_str());
response["success"] = false;
return;
}
// Assuming that the reboot command does not need any specific data
response["success"] = true;
serializeJson(response, Serial);
Serial.println();
delay(1000);  // Delay for debugging, remove in production
ESP.restart();  // Reboot the device
}

You need to adjust the onMQTTMessage like shown above, this is required because to debug the issue I require more information on what part exactly fails in the deserialization.

Furthermore when you use RPC with Dynamic mode, the RPC_Response has a third argument that defines the size of the response JsonVariant, per default it is only big enough to hold response.set(...). If you want to set response["success"] = true; you need to increase the size over the third argument to JSON_OBJECT_SIZE(1).
Additionally I'm not sure why you are copying the JsonDocument in the processPower method, because you are not even using it. Could you not simply call ESP.restart(); when the method is called?
Because setting the response is useless anyway, because it will never be sent if you restart the device before the method finished executing. Because the response data is only sent after the method has finished executing.

Mathew, hi,
firstly, thanks for the prompt replies. As a bit of background, I had the RPC working ok, but it had not been used much recently other than I had people using the TB Scheduler and that was fine, but when I was reimplementing the extra RPC (currently 8 functions) I started to get these errors, and it snowballed from there, as these things do. I had migrated from the ESP32 4mB to the 8mB and that was at the same time the json issues were there back earlier.
I have gone back to basics and refined the set up. and reverted back to non dynamic operations:
thats solved the memory and Unable to de-serialize json etc..
and also solved the error too many subscriptions.
Arduino_MQTT_Client mqttClient(espClient);
ThingsBoardSized<32, 8> tb(mqttClient, 128);
the code example was simply a strip down from the mainstream code, to test and reasonably evaluate. So, the function to reboot was simply a place holder and like the others not final operations.   For example, the reboot function includes resolving the cause of the reboot, Put to the eeprom and the doing the reboot itself.  So when it restarts the eeprom has the reason stored. and that is sent at start up... etc.
The mainstream code is around 15K lines and have a lot of things going on. Now including ChatGPT and building Dynamic Prompts, where the sensor constructs Air Quality messages for things like Pollen detection (Indoor readings from the Sensor itself, and from Polling EPA and Government formal Pollen sensing and then used "descriptions" fear, anxiety, gen types, and others to send out social media messages to the user and carers etc.)  It becomes very interactive.
So, a strip down is necessary to isolate issues.
I will close the issue now, as the RPC is largely OK, and later experiment with options. As I am getting a more refined understanding and impacts.
Testing looks ok now; I will post on my AWS - OTA in a few days.
Thanks again..  cheers.


Bugfix: reset workflow should also reset the current execution record

Looks good after the update.  Let's modify the unit test as I suggested in the comment and land this PR.


Adds specific lumen queue config description on readme

Codecov Report

Merging #2032 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #2032   +/-   ##
=========================================
  Coverage     87.15%   87.15%
  Complexity      672      672
=========================================
  Files            31       31
  Lines          1541     1541
=========================================
  Hits           1343     1343
  Misses          198      198

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1898947...5cda0ce. Read the comment docs.


[SVG] Fx 77 tasks

Trello
https://trello.com/c/tKOmHAzq/264-svg-markup-related-bugs-fx-77
Acceptance criteria

[ ] add a presentation attribute for transform-origin

Upping the estimate, since transform-origin is not documented, and so needs a page from scratch.

Added reference article for SVG transform-origin. Added links to it from SVG Attributes index page.

Looks done to me. Also appears on the release notes: https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/77#SVG


[Feature] Add controller startup parameters to allow disbale inner workload/trait controller

By default, vela-core will start all inner controllers. We could add some prameters such as:
./vela-core --disable-route --disable-metrics

To disable these inner controller to run.

For what purpose were some builtin capabilities be disabled?

@zzxwill  we should allow users can only use oam-framework, especially for user who are migrated from oam-runtime