Rewrite LAPACK so it's not in F77

From @ilayn, who can hopefully expand:

We must (full emphasis on must) port LAPACK out of F77 for fast computing as scientific community (of all languages). LAPACK codebase is treated as the scripture, and for a good reason because the folks who wrote the algorithms have immense insight and expertise. But that does not mean they coded the most optimal code and also F77 does not lend itself to anything modern hardware offers. You get only what gfortran offers for the loop optimization. While the algorithms are rock solid, they have no way other than writing for loops as if there is no tomorrow. I know this because I spent reading similar code for the good chunk of last year due to META: FORTRAN Code inventory · Issue #18566 · scipy/scipy · GitHub. LAPACK routines are often older than SciPy’s *PACK libraries.

Indeed this needs some explanation because 99% of the responses will be "yeah right, sure" which is not the audience I care about so I don't feel discouraged by any of such responses hence feel free if you feel like it.
Acknowledgements
I think current and past authors and contributors of BLAS and LAPACK should be knighted and placed in chateaus and mansions with 4 lambos and 2 yachts each. There is no way to measure their contributions to the scientific community. It is in fact make me feel a bit uneasy given how much money is poured into AI and not to this fundamental library.
So I will make some remarks below but this is purely from future-proof perspective and nothing related to past decisions. It is what it is. And in fact I know maintainers of Reference LAPACK already contemplate about similar points. But if I summarize them here, it is going to open up a different discussion which I want to skip completely.
Meat of the argument
The goal is to store LAPACK in a format that is both

Accessible to be compiled in any platform with no significant toolchain problems,
Readable to be ported to any platform with no significant preliminary knowledge in that language.

and currently it is neither with fortran77.
Very brief and opinionated personal summary;
Currently, LAPACK is the fundamental reason why we need fortran compilers or even we need to care about fortran in general if we are not using fortran.
BLAS has been ported to C/Assembly multiple times in various forms and except the reference implementation, nobody uses it in its native form. If BLAS is to NumPy, LAPACK is to SciPy in our case; LAPACK heavily uses BLAS operations but essentially it is just a never-ending stream of for loops and index olympics to do clever stuff with arrays. Thus it has no special property that blocks such porting to whichever language we would be using.
Therefore fundamentally, F77 is the gatekeeper of taking that code and implementing anywhere that has a suitable compiler of any other language. In other words, if the reference implementation was in C, it would have been substantially easier to port it to almost all platforms under the blue sky. And I would speculate that it would have been translated to many languages.
In fact the totality of the numerical community is forced to either find a fortran compiler or use a compiled library but still forced to have a Fortran layer on top to prevent ABI compatibility issues. As every SciPy maintainer by now knows, it is just an endless pain point. Plus, initiatives such as Pyodide are always getting stuck at wrapping fortran code and anytime SciPy rewrites anything from F77 to C they remove a good chunk of unnecessary code that was meant for handling f77.
Besides, Fortran community is dwarfed by C community and also when it comes to low-level optimizations, lot of folks who can perform SSE optimizations cannot do anything about the LAPACK code since it is in Fortran. So it is a loss of capacity and skill. Anything to be done is already being done to BLAS such as BLIS or GotoBLAS/OpenBLAS, since it is a smaller codebase and also simple to follow the functionality goals, but for LAPACK very little has been done, say, OpenBLAS having a custom parallelized ?getrf written in C and so on. Therefore to be able to increase the attention that LAPACK gets from the international community it has to be archived in a proper common and accessible language. And I argue here that F77 is not that. Therefore a port is sorely missed. And similarly that's why modern fortran is not relevant here. Since if a port will take place, we don't need to modernize fortran we need to get it out to a more common language.
So far there have been only two, battle tested, and proven, software languages that has true archival properties. First one is obvious, Fortran77 and the other one is C (I'm talking about multi-decades). Hence we are left with C. Now, it would be unfair to call C as a better fortran alternative when it comes to numerical array computing. Because it absolutely is not. It has less unergonomic parts however it is just tedious to have straightforward code. But a C array is just a pacifier to hide pointer arithmetic. And we are talking about a huge array library. Some might say well what is wrong with A[z + m*y + m*n*x] or A[x][y][z] instead of A[x, y, z] and we don't need to have a debate. I take these syntax as self-evident. You would too if you spent your days in writing array code. And this is the reason C++ is not even considered. It is very difficult to write unabstracted and sound numerical code in C++ without using some strange new features that have questionable future such as C++2017 std::vector all the way to C++ 2023 std::mdspan. It seems like every year another fancy container is discovered in the standard. In C++ 2026 even LAPACK is supposed to be coming in the std::linalg https://www.youtube.com/watch?v=-UXHMlAMXNk. No offense to C++ devs but even the examples look worse than F77 versions. Hence I have a strong opinion that this is not something we should port to.
The most problematic issue for C is Microsoft and its relentless insistence on not conforming to C99 standards.  However, it has been done countless times and can stay as a necessary evil. Or can be left for the folks who want to use MSVC. If open source C compilers become widely adopted in Windows ecosystem then probably the best strategy might be is to drop MSVC completely and be done with it. But until then, it would hurt majority of the users. This might sound bad but it is much worse for Windows if Fortran is used already which is why we are here.
An ode to fortran though
Fortran, old or new, regardless of its age, has superior array ergonomics, hands down, no competition. It is fantastic in that regard, so much so that, NumPy borrowed almost all identically. But that's where good things about F77 end for us. Because it is typically 1-indexed and column major memory layout, it does not play well with anything else (except julia and matlab). It is possible to change the indexing in fortran however LAPACK code did not. Hence one of the biggest annoyances of such rewrite will be 2D array index bonanza if C to be selected but the advantages so far outweigh this very important annoyance.
Language designers completely miss the number crunching community and we are always piggybacking on regular langs such as Python's @ operator and ndarray silliness of all C inspired languages and VLAs and countless other ergonomics killing details and so on.
In summary, fortran is a very good language to stick with, if you don't interface with other languages (ctypes are not a thing in this context) or you are not packaging anything to be run on all platforms. Unfortunately, the majority of the contemporary community does and are. Also its future is bound to a very particular audience and to a very small committee skewed towards HPC use cases.
Obligatory Rust and Zig section
Why not Zig or Rust? Rust already has a couple of attempts, a very nice one is https://github.com/sarah-ek/faer-rs and a there are few others via ndalgebra crate. But its impossible looking syntax is killing the starting rationale of this rewrite.
Zig has multidimensional arrays but it is no different than C and also does not come with complex numbers which is in my opinion two very important trains missed. It is now available in std::math but I can't make heads or tails from this issue https://github.com/ziglang/zig/issues/16278. Typically, folks who don't use complex numbers dismiss this as "It's just a struct what about it?!?" and an endless debate ensues.
Why not others langs?
I don't know them. Put it below if you want to make a case. But we might as well use C to get all the middle man out despite all the problems given above.
#IFNDEF HORROR, it's here
So what kind of a beast are we talking about? Well, as of 20240813 using cloc tool
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Fortran 77                    3548           3236         922596         622695
C                             2870          15422          90590         166352
C/C++ Header                    12           3144            393          51340
Fortran 90                      30            364           8594           6040
CMake                           40            520            537           5594
make                            19            445            492           4837
TeX                              1            242            178           1264
YAML                             5             66             44            413
Python                           1             33             23            271
Markdown                         7             53              0            266
XML                              2             17              8            251
-------------------------------------------------------------------------------
SUM:                          6535          23542        1023455         859323
-------------------------------------------------------------------------------

This is a utterly spectacularly annoying problem. However before you close the tab, notice that this is the totality of BLAS/LAPACK tests and other stuff multiple versions etc. If we just look at the SRC directory of LAPACK (no BLAS no nothing else)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Fortran 77                    2111           2641         573661         314089
Fortran 90                      18             38           6919           3302
C/C++ Header                     1              2              0           2275
make                             2             55             72            584
CMake                            1             27             39            526
-------------------------------------------------------------------------------
SUM:                          2133           2763         580691         320776
-------------------------------------------------------------------------------

Now it is still at least spectacularly annoying but halved. However note that most LAPACK code is in 4 flavors. That is the same routine for <s, d, c, z> (single, double, single complex, double complex) hence this is actually around 90k SLOC of code or original code. It does not reduce the pain but it definitely reduce the suffering.
Now that is just very annoying but it is precisely how much fortran77 code we had in SciPy too and we are currently passed the halfway point nearing 70%. It took me 16 months to get to here mostly 1/8 FTE or 5 hours/week on average. To be honest that's pretty much doable in my book given my track record in SciPy rewrites.
Also note that not all LAPACK code is essential. Many parts of it has deprecated things or historical warts.
Last points
There is no more important code in the scientific ecosystem than LAPACK. Your blackhole research or cure for cancer can resume in a much much better state if we collectively do this and be done with it because then we can in fact handle this unspoken embarrassing situation.
As I have written in my acknowledgements, we must support and lift the original reference library to the next level.

In case it will avoid pointless debates for the future, I don't like working with C especially after using C3, Zig and bunch of other langs which fix "a different part of C and not the parts I need". I am just forced into it because of the lack of another specialized array language. My unicorn wish is to have a truly "arrays are at the center" language. Think of the ever so wonderful Lua and tables, but instead <insert lang> and arrays.

A few small point to summarize the pages of thoughts I could have written about this topic (not enough time, sorry):
(1) For SciPy, once we get rid of all our own Fortran code, we have no fundamental problem with Reference LAPACK being written in F77. The problem we have with BLAS and LAPACK is an ABI problem - multiple problems actually, from LAPACKE not being well-enough supported to the routines like cdotc with two incompatible ABIs, to ILP64 symbol names. That the reference implementation is in Fortran doesn't matter so much, since we never want to use it at runtime (except maybe for debugging).
(2) I'm honestly not sure if it would help for LAPACK to be rewritten. Whether some vendor or open source effort writes an accelerated implementation is also based on need. The payoff for an individual routine to be written with SIMD/assembly/etc. is much smaller for LAPACK than it is for BLAS, so the chances of that effort being done are also much lower.

A few small point to summarize the pages of thoughts I could have written about this topic (not enough time, sorry):

We should get to a retreat in a cabin somewhere so we can compare pages.
(1) I can also go the other way, the reason why you have ABI problems is actually f77. The very reason for LAPACKE existing is also f77. I can give you another word that hides a saga; LSAME. Or you can think of NaN/INF handling, if you think of all the ABI issues and which language they are originating from, there is a pattern there. The main issue is the absence of a formal fortran ABI. I understand your view since this is a SciPy pain and in your view if the ABI was OK, why bother. However, this is not a SciPy problem and much larger. And f77 has blocked all the possible progress with the exact argument so far spelled out who knows how many times.
(2) This one I don't follow yet. Whatever makes BLIS fast can be applied to intermediate steps in LAPACK too which I think what https://github.com/flame/libflame was supposed to be in the first place. It is just not as tidy as BLAS routines. If you can unroll things in BLAS, you can still unroll in LAPACK too. Also this assumes that there is no room for improvement in LAPACK which is quite not true. Even LU can do much better. That's what Julia/Rust folks are trying to generalize in many different codebases. But the code cannot be modified as is and has to be rewritten. The main problem is that it is just not feasible to decode all that old crust and reorganize the new code and squeeze it back into F77 without causing mayhem. After quite some thousands of line of code translation, I can guarantee you, there are low-hanging fruits left and right everywhere. You can do the same exercise, just look at our translation of minpack or quadpack C code. There are many places I know that it can be 10 lines long and 10 times faster instead of bare looping with insane-level index tracking across nested functions.
The point I wanted to make is that it is possible to do optimizations without knowing the actual algorithm if you are using C if you encounter a for loop. In f77 you need a surgery. Much easier in modern fortran but not in f77. Also it is not "practically" possible to do it in F77 unless you know everything about the algorithm because the algorithm is baked into indices such as if if (mod(j, m).eq.1) GOTO 888. Why 1? Why mod? Because f77 does not have proper data structures so every flow is guided by counting with single letter indices hiding massive opportunities of performance.
We were holding the same idea about our fortran codebase being not feasible to translate, needs unreasonable human hours, they are battle-tested, crazily optimized yada yada. And I am not that blind or that stupid, I saw them everywhere too. We had all the reasons not to do it but now we are where we are. If we do not do this step, regardless of the bugs that will seep through, we are not going to go anywhere and still be discussing ABI issues in the decades to come which is a big waste of time to treat the symptom. To be honest, I am starting to think that everybody is making too much of a deal about these old algorithms. They are not magical code written in Ocaml or Assembly but just flat out, for loops. There are just too many of them.

@ilayn What do you think should be the next step?
A couple more questions:

How good is the test coverage in LAPACK?
What is the coverage of "functions" that we actually need from LAPACK which is already implemented in the rust libraries (just as an example) - it might be simpler to translate from rust to C

I don't have a concrete plan yet to start the work but the following are something that would help understanding the situation;

Opinion of actual maintainers of these libs would be really nice. If they say this is stupid, that's also a data point. I just want to know what the current feeling is. Because this is always thought as impossible task and I tend to agree. I'm just trying to understand how much impossible it is.
If C is the right solution or not.
Should the lwork query be eliminated or not.
Most algorithm is written with column-major in mind. So there will be some changes needed (loop orders to start with).

and many more questions. However, before all this a few examples should be done I think such as ?gesv, ?getrf, ?potrf then by swapping the underlying BLAS vendor such OpenBLAS, BLIS and so on would give some idea of what we are dealing with.

How good is the test coverage in LAPACK?

Not sure, but there is some. They are quite strict (up to a few ULP) hence when there is a test I'd expect it to have good coverage. But this is never guaranteed.

What is the coverage of "functions" that we actually need from LAPACK which is already implemented in the rust libraries

I don't know any direct Rust versions. But many rewrites are providing the same functionality by re-coding (not translating). But I am not sure, I did not really sit down for a comprehensive research.

Keeping in mind that I am not a linear algebra person: I tend to think of C as legacy language at this point, and more broadly any language that lacks memory safety by default. So personally I'd go with Rust for any new infrastructure projects; syntax can be learnt, a C ABI can be exposed... My impression is that https://docs.rs/num/latest/num/complex/struct.Complex.html is the standardized Rust-specific API/ABI for complex numbers, it's used by ndarray, nalgebra, faer, and sprs crates. The matrixmultiply crate (inspired by BLIS) appears to use an experimental respresentation that is ABI-compatible with the previous one. (C ABI compat for complexs seems like more of a a pain though, because it sounds like there's no cross-architecture ABI: https://github.com/rust-lang/rfcs/issues/793).
A random thought: https://github.com/immunant/c2rust transpiler is apparently successful enough to be used in some real world projects, e.g. as the starting point for a video codec (https://www.memorysafety.org/blog/porting-c-to-rust-for-av1/). One can imagine the equivalent for Fortran 77.

As I tried to argue above, C is indeed the legacy language however memory safety is not an issue on these decades old languages. Hence it is a matter of whether all the necessary details are included in the language. The complex number issue is one, like you point out, but also the 2D array libraries are still competing so it seems to me that there is a very high cost of choosing the wrong one.

One can imagine the equivalent for Fortran 77.

This only exists for F77->Modern Fortran with partial success so far and I don't think there is any help coming anytime soon.

Have you guys seen that there is a Modern Fortran implementation? https://github.com/perazz/fortran-lapack
It is already included on the Fortran stdlib with preprocessing for different types: https://github.com/fortran-lang/stdlib/blob/master/src/stdlib_linalg_lapack.fypp

I do and have discussed this on fortran-lang discourse. It is a reformulation of the modern function declaration not the code rewrite hence it is not solving the problems I have mentioned above.


Remove weird branch names, no reason for them after moving to folder, not brach based, exercises

@RandomSort I think this needs a tad more elaboration to enable others to work on...

This issue can be closed, since the layout of the repo has changed since, making it obsolete.
Please verify @RandomSort


Stripe packages: missing export_for_test error and correction

If a constant fails to resolve in a packaged test file, we first check inside the associated normal code for the package and if the symbol is found there, instruct the user to export_for_test.  In this case we stop looking for other possible matches because this is almost certainly the right fix.
I also fixed an mistake in this this codepath that was adding the hint twice.
Motivation
This is an easy to make error, but we were not showing good messaging around it.

Test plan

See included automated tests.

cc @aisamanra

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build results here:
→ https://go/builds/bui_L253dS7d7TS3Oa
→ https://go/builds/bui_L253YdbDgqWGiu


Review decision to not support HTTP for NDT7

We lately discovered that Fing has been relying on boticelli (multi-stream ndt5) in the neubot experiment. We were not generally aware of this, and as we continued to migrate nodes to the k8s platform, that left fewer and fewer nodes running the legacy neubot experiment on the PLC platform. At some point (that point being yesterday) the number of nodes got so low and geographically distant from Europe that Fing started noticing errors.
Fing's workaround for now is for clients to a do single-stream NDT5 test instead, which was the fallback previously anyway. They have a limitation in their hardware that prevents them from currently considering NDT7 over HTTPS. They could support NDT7 over HTTP, but we don't currently support this mode of operation.
We should reconsider whether we ought to allow both HTTPS and HTTP NDT7 tests. Encryption is quickly becoming the standard for the Internet, but HTTP is still important. Additionally, there are probably very few privacy-related reasons why NDT7 must be HTTPS, since it's all synthetic data anyway.

Pro

HTTP is one of the most important internet protocols, and many people rely on it.
Allows you to run an NDT7 server without knowing how to get a cert
Allows devices with crappy CPUs to test fast networks

Con

It can be sniffed in transit, allowing providers to use DPI to distinguish speed test traffic from non-speed-test traffic.
It splits our dataset into encrypted and unencrypted tests
It adds complication to the ndt7 codebase

Still don't know what the guaranteed right answer is here.

Adding to your first con (about DPI): there is no need to do deep packet inspection for an ISP to distinguish M-Lab speedtest traffic. They only need to do very shallow packet inspection to see that the traffic is destined for an M-Lab host. If an ISP really cared enough to try to distinguish M-Lab traffic on their network, and even further to manipulate it in some way, I would argue that HTTPS wouldn't hinder them.

The more I think about this, the more I think we should support unencrypted NDT7.  In particular, the reason "Allows you to run an NDT7 server without knowing how to get a cert" turns out to be super-important for people who want to use NDT7 as a pedagogical tool (and, btw, they SHOULD want to use it as a pedagogical tool).  The fact that supporting educational objectives also aligns with supporting low-powered devices seems to imply that the right thing is to support unencrypted NDT7 tests.

We have already implemented this for the official Go client in https://github.com/m-lab/ndt7-client-go/pull/31. There is a pending PR to do this in the server (#222). We may want to follow-up for libndt as well, but that is a slightly longer process perhaps.

Decision: we will support unencrypted NDT7


To do app

We are desperately trying to shut down this errors but we haven't been able to find a solution. Can you please help us?


Output image data, both embedded and as files.

Hi!
Sorry for the wall of text. If you have any feedback on this PR, don't hesitate. I have a lot of time for this tomorrow as well.
Summary

Added stb_image_write.h as dependency.
User can output tinygltf::Image.image as file.
User can output tinygltf::Image.image as embedded file.
User can skip image output with define TINYGLTF_NO_STB_IMAGE_WRITE. (Tinygltf has same behavior as before this PR).
User have option to set custom image writer with function SetImageWriter.
Uninitialized sampler value in tinygltf::Texture is not outputted.
Updated saver example.
Updated main readme to reflect the changes.

Image writing
WriteImageData is a new function which is called for each tinygltf::Image during Serialization. This function can either handle image writing or image embedding, the input tinygltf::Image.uri will be updated with the new data. The updated tinygltf::Image is then serialized (Same as before this PR).  The output image format is the same as the input image format.
If  TINYGLTF_NO_STB_IMAGE_WRITE is defined, WriteImageData function will be initialized to nullptr, the user can either set a custom WriteImageData function or skip it entirely. If WriteImageData is nullptr, the tinygltf::Image object is not updated and tinglyf will behave as before the PR. If a custom WriteImageData is set, the user have to update the tinygltf::Image.uri with the new data (either relative path or embedded data). A user may want to have a custom WriteImageData to use a more optimized image writing framework other then stb_image_write.h .
Discussion
Error handling
As of now, error handling is skipped during serialization. Do we want to have an error string which can return errors to the user, similar to tinyGLTF::LoadASCIIFromFile? As of now I have left comments in the code where an error could happen.
DecodeDataURI change
I wanted to keep the image format from the original file. Therefore the DecodeDataURI function was changed to also set the mime_type. For buffers this is not needed, and the mime_type is discarded (see line 2037). Should this get mime_type be refactored to an own function or is should we keep it as in this PR?
Gif format
stb_image_write.h don't support the .gif format. Do we want to support gifs as output? If so, is there a better header only lib other than stb_image_write or should multiple image writing libraries be used?

Super awesome!
I'll review code soon, but firstly Travis failed to the following error.
./tiny_gltf.h:2037:12: error: no matching function for call to 'DecodeDataURI'
      if (!DecodeDataURI(&buffer->data, std::string(), buffer->uri, bytes,
           ^~~~~~~~~~~~~
./tiny_gltf.h:1479:13: note: candidate function not viable: expects an l-value for 2nd argument
static bool DecodeDataURI(std::vector<unsigned char> *out,

I have no strong motivation to support GIF output, but you can find some GIF writer libraries here: https://github.com/nothings/single_file_libs

If I can give my opinion too, I don't think GIF is an useful format for texture support...
For the Travis failing, I think you meant to type buffer->data() in that function call. :wink;
(You are currently giving it a function pointer, not the result of the call to vector<>::data())

We can skip error handling for a while. At some point, I'd also want to consider more expressive error report both for loader and writer(In this phase, it would be better to move to schema based approach for generating loader and writer code: https://github.com/syoyo/tinygltf/issues/10)

If I can give my opinion, I don't think there's a good reason to support Gif as a texture format either.

I agree with you guys, the only reason I mention .gif is due to it being supported by the image loader.  If there is a demand for it, I will be happy to add support for it.

I mention .gif is due to it being supported by the image loader.

I see. If it is not so hard to add GIF writing feature(e.g. just few additional lines of coding is enough), yes please add  support for GIF writer.

If it is not so hard to add GIF writing feature(e.g. just few additional lines of coding is enough)

stb_image.h supports .gif (used as image loader)
stb_image_write.h do not. (used as image writer)
I could add support by adding another dependency. Such as gif.h, but if it is not needed I think it is better to limit the number of dependencies.

Merged with some modification(suppress clang warnings).

I could add support by adding another dependency. Such as gif.h, but if it is not needed I think it is better to limit the number of dependencies.

Okay, we can leave GIF support for a while.


Errors in sudo gem update --systems

Updating json
ERROR:  Error installing json:
        Unable to resolve dependency: user requested 'json (= 2.2.0)'

Empty VPS server, Ubuntu 19.10, root user.
Such errors always appear in sudo gem update --systems.

It is OK to ignore this.


I ran into a fail decoder: No such type as thunk

Unhandled exception while running the tests: Error: Ran into a `Debug.crash` in module `Html.Inert`

This was caused by the `case` expression between lines 18 and 23.
One of the branches ended with a crash and the following value got through:

    Err "I ran into a `fail` decoder at _.children[1].children[4].children[4].children[1]: No such type as thunk"

The message provided by the code author is:

    Error internally processing HTML for testing - please report this error message as a bug: I ran into a `fail` decoder at _.children[1].children[4].children[4].children[1]: No such type as thunk
    at eval (eval at <anonymous> (/ui/node_modules/elm-test/bin/elm-test:119:32), <anonymous>:573:9)
    at _eeue56$elm_html_test$Html_Inert$fromHtml (eval at <anonymous> (/ui/node_modules/elm-test/bin/elm-test:119:32), <anonymous>:81253:8)
    at _eeue56$elm_html_test$Test_Html_Query$fromHtml (eval at <anonymous> (/ui/node_modules/elm-test/bin/elm-test:119:32), <anonymous>:82187:4)
    at _NoRedInk$noredink$Page_Teach_AssignmentForm_ViewSpec$findAnnouncements (eval at <anonymous> (/ui/node_modules/elm-test/bin/elm-test:119:32), <anonymous>:82285:3)
    at eval (eval at <anonymous> (/ui/node_modules/elm-test/bin/elm-test:119:32), <anonymous>:82306:7)
    at Function.eval [as func] (eval at <anonymous> (/ui/node_modules/elm-test/bin/elm-test:119:32), <anonymous>:26780:12)
    at A2 (eval at <anonymous> (/ui/node_modules/elm-test/bin/elm-test:119:32), <anonymous>:92:11)
    at Object.eval [as _0] (eval at <anonymous> (/ui/node_modules/elm-test/bin/elm-test:119:32), <anonymous>:39546:18)
    at _elm_community$elm_test$Test_Runner$run (eval at <anonymous> (/ui/node_modules/elm-test/bin/elm-test:119:32), <anonymous>:39507:13)
    at Object._0 (eval at <anonymous> (/ui/node_modules/elm-test/bin/elm-test:119:32), <anonymous>:96158:13)

Here's the toJsonString of the HTML being tested:  https://gist.github.com/avh4/f4c68ca856386bc63683414279f69258

Ah, apparently ElmHtml.InternalTypes.decodeElmHtml is not implemented for thunk yet

Since elm-html-test currently strips out all functions with JSON.stringify, I think the simplest way to get this to work would be to call virtual-dom's render on the Html before stringifying, which would force all the thunks (the result of the thunks is stored in the vdom as node after it's been forced, so then that would appear in the resulting JSON.

... unfortunately, it looks like Native.VirtualDom.render is not accessible from outside, even in other native code :(

Okay, I've got a possible implementation for this--requires a change to both elm-html-test and elm-html-in-elm; I'll make the PRs shortly.

Should be fixed by https://github.com/eeue56/elm-html-test/pull/7


Improve Performance

I haven't really worked on the performance of this but currently, it hits a mean of ~48ms. This should definitely be improved.
One way would be to see if we can break the main for loop.
For anyone who has not worked with Cloudflare Workers before, the official Discord server is a great resource - https://discord.gg/cloudflaredev

I'm working on removing the main for loop.

v2 took this down from ~25-30ms CPU time to ~10ms.


when I train ga-faster-rcnn-resnext101-32x4_fpn.py，I encounter out of memory

I already fix batch_size =1,and I call 2 1080ti gpus,but still out of memory.However,when I use single gpu,it just cost about 5GB memory.
my distrbute train command is:
CUDA_VISIBLE_DIVICES=0,2 ./tools/dist_train.sh ./configs/guided_anchoring/ga_faster_x101_32x4d_fpn_1x.py 2
how to fix this out of memory problem?

You mean memory or GPU memory? GPU memory should not increase with the number of GPUs.


about render

Description
about pressable-polyfill, when I use Pressable.render, it doesn't work。
but，when i use TouchableOpacity.render, i can work
I want to know why?
Does Presable not have a render method, but how should I write Presable？
The Pressable-polyfill code is：
import React from 'react'
import { TouchableOpacity, Pressable } from 'react-native'
import debounce from 'lodash.debounce'
// @ts-ignore
const __Pressable: any = Pressable.render
// @ts-ignore
Pressable.render = function (props: PressableRender, ref: React.RefObject) {
const { onPress, style, ..._props } = props
const __onPress = debounce(onPress, 800)
const __style = { backgroundColor: 'blue' }
console.log('............')
return __Pressable.call(this, { ..._props, onPress: __onPress, style: __style }, ref)
}
// @ts-ignore
const __TouchableOpacity: any = TouchableOpacity.render
// @ts-ignore
TouchableOpacity.render = function (props: TouchableOpacityRender, ref: React.RefObject) {
const { onPress, style, ..._props } = props
const __onPress = debounce(onPress, 800)
return __TouchableOpacity.call(this, { ..._props, onPress: __onPress }, ref)
}
Steps to reproduce
add Pressable-polyfill file
React Native Version
0.72.14
Output of npx react-native info
System:
  OS: macOS 14.4.1
  CPU: (10) arm64 Apple M1 Pro
  Memory: 742.84 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.12.2
    path: /usr/local/bin/node
  Yarn:
    version: 1.22.22
    path: /usr/local/bin/yarn
  npm:
    version: 10.5.0
    path: /usr/local/bin/npm
  Watchman:
    version: 2<IP_ADDRESS>
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.4
      - iOS 17.4
      - macOS 14.4
      - tvOS 17.4
      - visionOS 1.1
      - watchOS 10.4
  Android SDK: Not Found
IDEs:
  Android Studio: 2023.3 AI-233.14808.21.2331.11709847
  Xcode:
    version: 15.3/15E204a
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 11.0.23
    path: /usr/bin/javac
  Ruby:
    version: 3.3.1
    path: /opt/homebrew/opt/ruby/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.72.14
    wanted: ^0.72.14
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: Not found
  newArchEnabled: Not found
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

Screenshots and Videos
No response

I think this is a technical issue. I want to know why Presable.render doesn't work


fix heap overflow with in-predicate on nullable columns (#14319)

Losing segmentid info will mess up the _segment_id_to_value_in_dict_flags map
in InListPredicate, causing two distinct segments to collide and crash the BE at last.
There are two facts that can lead to lose segmentid info:

mistakenly invoke IColumn dummy virtual function instead of the one in derived class
ColumnNullable::get_nested_column() does not pass on the segmentid info.

Signed-off-by: freemandealer<EMAIL_ADDRESS>Proposed changes
Issue Number: close #14319
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[] Yes
[X] No
[] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[X] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[X] No Need

Does it need to update dependencies:

[ ] Yes
[X] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[X] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

https://github.com/apache/doris/pull/14641 is a more decent and recent fix of the problem.


🐛 getCameraCharacteristics:1041: Unable to retrieve camera characteristics for unknown device

What's happening?
crash on specific android device S22+
I dont have this device, I am seeing this in our firebase crashlytics

Reproduceable Code
<Camera
                    ref={camera}
                    style={{flex:1}}
                    device={device}
                    isActive={isFocused && isForeground}
                    photo={true}
                    enableZoomGesture
                    orientation='portrait'
                    resizeMode={'contain'}
                />

Relevant log output
see image above
I dont have this device, I am seeing this in our firebase crashlytics
but I have captured the stack trace
for you

Camera Device
unknown

Device
Galaxy S22+
VisionCamera Version
4.1.5
Can you reproduce this issue in the VisionCamera Example app?
I didn't try (⚠ your issue might get ignored & closed if you don't try this)
Additional information

[ ] I am using Expo
[ ] I have enabled Frame Processors (react-native-worklets-core)
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

Sorry, without logs I cannot help you. You need to reproduce this bug on an actual device and send me the adb logcat logs.

Hi @mrousavy perhaps just keep this ticket open in case it is not just how Im using the library, but an issue for everybody who uses the library with this device.    Its been around for 2 years though.

Yes but as I just said, there's nothing I can do without logs.

Ill try to track down an online real device of this type and see what
happens.
On Thu, Aug 29, 2024 at 6:10 PM Marc Rousavy @.***>
wrote:

Yes but as I just said, there's nothing I can do without logs.
—
Reply to this email directly, view it on GitHub
https://github.com/mrousavy/react-native-vision-camera/issues/3148#issuecomment-2316977323,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKQ2O6LEYBBD7ZTMKCVKUWLZT3JPHAVCNFSM6AAAAABM7EZ3I6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJWHE3TOMZSGM
.
You are receiving this because you authored the thread.Message ID:
@.***>


test/blobs: add explicit test for de-duplication

De-duplication breaks if subsequent blobs have different content-types from the original :thinking:

Closing in favour of issue https://github.com/getodk/central-backend/issues/1219


Bug of GS-SCF convergence in the current/recent version (ARTED side)

I found a bug of ground-state scf calculation in ARTED side in the current/recent version (not in the older version: at least around two weeks ago).
(double check was done by Uemoto-san)
In the current version, the scf does not converge like (XX_GS.out):
...............
148   -0.4379181722E+03    0.7835661139E-02    0.8154006743E-02    0.2362924103E-01
149   -0.4380639074E+03    0.4877358546E-02    0.6855756716E-02    0.1908358073E-01
150   -0.4379719259E+03    0.5001770535E-02    0.7146741877E-02    0.2145845483E-01
but on the other hand scf converges with the older version (of around the end of August):
.............
148   -0.4384640347E+03    0.1445445105E-09    0.2410829159E-08    0.1922763162E-07
149   -0.4384640347E+03    0.2467451177E-09    0.3026866230E-08    0.1054536409E-05
150   -0.4384640347E+03    0.2446715902E-09    0.2720838887E-08    0.9017800164E-06
I'm going to fix this issue with Uemoto-san.
If you know something about that please let us know.
best,
A-Yamada

Thank you @ayamada224 for bug report.
I also confirmed the above problem in recent version of SALMON.
Now I have submitted a job to search the first version causes this problem with rolling back the git histories. For now, I narrowed down the beginning of bug is one of pull request between PR#164-177.  It is necessary to wait a moment to identify the single pull requests.

I have obtained the result of calculations and identified the related pull request (PR #175). After merging this PR,  the decreasing of the convergency appears in the numerical results. I suggest checking the implementation of PR and (if it is necessary) reverting the merge.

Commit
Pull Request
Total energy (iter=100)
Delta E (iter=100)

3760346
Merge pull request #177
-31.1644588347157
-8.162118815171482E-004

077efe5
Merge pull request #176
-31.1704499164816
-3.352016921326140E-003

503b107
Merge pull request #175
-31.1695048636110
-1.105028257521923E-002

e0f77a3
Merge pull request #173
-31.2658878785857
-1.240643143773923E-009

409ffcb
Merge pull request #172
-31.2658878785857
-1.240643143773923E-009

4a98673
Merge pull request #170
-31.2658878785857
-1.240643143773923E-009

d5fcd81
Merge pull request #169
-31.2658878785857
-1.240643143773923E-009

d0f967a
Merge pull request #166
-31.2658878785857
-1.240643143773923E-009

72cad62
Merge pull request #165
-31.2658878785857
-1.240643143773923E-009

f3d1a62
Merge pull request #164
-31.2658878785857
-1.240643143773923E-009

1d03a53
Merge pull request #163
-31.2658878785857
-1.240643143773923E-009

be84eeb
Merge pull request #162
-31.2658878844389
1.034230479035614E-009

176863c
Merge pull request #160
-31.2658878844389
1.034230479035614E-009

The used input file is uploaded as below:
https://gist.github.com/uemoto1/0e6f40338802a45d7c6ab55c84e9af6e

@uemoto1 san and @ayamada224 san, I read src/ARTED/GS/diag.f90 which modified by PR #175.
Probably, line 89-92 happens OpenMP thread conflict.
For quick fix, I suggest !$omp end parallel clause at line 94 moves to line 88.

Thank you @yhirokawa san. I grasped the point of this problem. I will send the bug fix immediately.

Sorry for having embedded the bug. I wait the bug fix @uemoto san will give.


HAWQ-212. Fix unittest failure due to introduced enum RESOURCEPROBLEM

looks good.

The fix looks good. +1


HomeMatic climate, cover and light devices not working in 0.104.0b3

Home Assistant release with the issue:
0.104.0b3
Last working Home Assistant release (if known):
0.103.6
Operating environment (Hass.io/Docker/Windows/etc.):
Docker
Integration:
HomeMatic (https://rc.home-assistant.io/integrations/homematic/)
Description of problem:
I'm using a RasperryMatic on latest firmware (<IP_ADDRESS>91225) with HmIP-RFUSB (HomeMatic IP devices only). With the update to 0.104.0b3 all homematic climate devices show up as unavailable.
I tried all three possible port configuration options in the hosts section:

no port configuration at all (default 2001 should have been applied)
port: 2001
port: 2010

None of those three worked.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
homematic:
  local_ip: <IP_ADDRESS>
  interfaces:
    ip:
      host: homematic.devices
      port: 2010
      callback_ip: <IP_ADDRESS>
      username: !secret hm_username
      password: !secret hm_password
    groups:
      host: homematic.devices
      port: 9292
      callback_ip: <IP_ADDRESS>
      username: !secret hm_username
      password: !secret hm_password
      path: /groups
  hosts:
    ccu3:
      host: homematic.devices
      port: 2010
      username: !secret hm_username
      password: !secret hm_password

Traceback (if applicable):
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 344, in _async_add_entity
    capabilities=entity.capability_attributes,
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 179, in capability_attributes
    ATTR_HVAC_MODES: self.hvac_modes,
  File "/usr/src/homeassistant/homeassistant/components/homematic/climate.py", line 87, in hvac_modes
    if "AUTO_MODE" in self._hmdevice.ACTIONNODE:
AttributeError: 'NoneType' object has no attribute 'ACTIONNODE'

Additional information:
All my other devices (sensors, binary_sensors) are functioning properly.

Which types of Climate devices are you using? With pyhomematic version 0.1.62 there have only been changes to HmIP-BWTH and HmIP-BWTH24. With 0.1.63 all the eTRV-Variants had a small change. But there actually only a new a new attribute in the writenode has been added, so this shouldn't have any effect.

I'm having multiple HmIP-eTRV-2, HmIP-WTH-2 and heating control groups containing the former. The error message from above is thrown for each of those devices/groups.
It's working fine with Home Assistant release 0.103.6, so pyhomematic 0.1.62 doesn't seem to be the problem. I've also tried HA 0.104.0b4 with earlier pyhomematic versions, which all threw the same error 'NoneType' object has no attribute 'ACTIONNODE'. So my guess is, it's somewhere in HA and not in pyhomematic.

It's also 0.1.62 in 0.104.0b4. The strange thing is, that none of the recent changes have to do anything with what's happening here.
The next best thing that comes to my mind are the changes in the climate component itself.

I quickly have set up a new dev environment and can confirm the issue. And it's not just HmIP. I only have regular HM-thermostats, and here I have the same problem.

The entities where loaded after implementing a check for self._hmdevice HomeMatics climate.py:
    @property
    def hvac_modes(self):
        """Return the list of available hvac operation modes.

        Need to be a subset of HVAC_MODES.
        """
        if self._hmdevice is None:
            return [HVAC_MODE_HEAT, HVAC_MODE_OFF]
        if "AUTO_MODE" in self._hmdevice.ACTIONNODE:
            return [HVAC_MODE_AUTO, HVAC_MODE_HEAT, HVAC_MODE_OFF]
        return [HVAC_MODE_HEAT, HVAC_MODE_OFF]
...
...
    @property
    def preset_modes(self):
        """Return a list of available preset modes."""
        preset_modes = []
        if self._hmdevice is None:
            return preset_modes
        for mode in self._hmdevice.ACTIONNODE:
            if mode in HM_PRESET_MAP:
                preset_modes.append(HM_PRESET_MAP[mode])
        return preset_modes

But this obviously is not a fix, it just hides the error and let's the startup process continue.
While doing this I also noticed that the cover platform doesn't work anymore. I get the following error:
2020-01-13 22:24:23 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/home/daniel/home-assistant/homeassistant/helpers/entity_platform.py", line 345, in _async_add_entity
    supported_features=entity.supported_features,
  File "/home/daniel/home-assistant/homeassistant/components/cover/__init__.py", line 207, in supported_features
    if self.current_cover_position is not None:
  File "/home/daniel/home-assistant/homeassistant/components/homematic/cover.py", line 39, in current_cover_position
    return int(self._hm_get_state() * 100)
TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'

And by testing with pydevccu I also found the light platform to be broken:
2020-01-13 22:41:24 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/home/daniel/home-assistant/homeassistant/helpers/entity_platform.py", line 344, in _async_add_entity
    capabilities=entity.capability_attributes,
  File "/home/daniel/home-assistant/homeassistant/components/light/__init__.py", line 391, in capability_attributes
    supported_features = self.supported_features
  File "/home/daniel/home-assistant/homeassistant/components/homematic/light.py", line 58, in supported_features
    if "COLOR" in self._hmdevice.WRITENODE:
AttributeError: 'NoneType' object has no attribute 'WRITENODE'

@pvizeli Are you aware of any core changes that might have had such a great impact?

Instructions on how to reproduce (without owning HomeMatic devices):
Home Assistant configuration
homematic:
  interfaces:
    hmrfdev:
      host: <IP_ADDRESS>

Install virtual CCU
pip3 install pydevccu

Start (and stop) virtual CCU
import pydevccu
# Emulate Thermostat, Cover and Light
s = pydevccu.Server(devices=["HM-CC-RT-DN", "HM-LC-Bl1-SM", "HM-LC-RGBW-WM"])
s.start()
# Start Home Assistant with HM interface at <IP_ADDRESS>:2001
s.stop() # When done testing

There is an core issue and flow change. Will fix that tomorrow. Thanks for debug it

The problem what happened is that we've started storing capability_attributes in the entity registry.
The capability_attributes are fetched from an entity after the initial update is done (if requested) but before we execute async_added_to_hass.


Different backend for different launch configurations

Thank you for creating such a helpful extension.
Our project is developed across multiple platforms and certain platforms require specifying a particular LLDB backend. Using lldb.library works well, but switching platforms necessitates manual edits to settings.json.
Would it be possible to support this option within the configurations in launch.json, enabling me to pre-configure it for different platforms right within launch.json?

No, but you can achieve this with VSCode profiles or extensions like this one.


Error updating Onyx in App

Problem
Coming from this thread, updating Onyx to the latest hash f11e7c1949916a81c36c17dd87919dd532d4620f results in the following console error on Web (native platforms seem to work).

Why is this important
We need to release new Onyx functionality that is blocking our roadmap.
Solution
Seems to have been introduced here - https://github.com/Expensify/react-native-onyx/pull/132
We think that webpack is resolving to the browser entry point when using Onyx on web. We need to find a way to point it to react-native
Note: It's also possible that the cause of the issue is something else

@kidroca I can't assign you, but would you mind working on this?

@luacmartins yes (You should be able to assign me after this comment)

Both PRs are merged and this issue is fixed! I'll move the discussion about the other solutions back to Slack. Thanks @kidroca!


MMM Example hangs in PyTensor >2.18.1

Hey folks, I just got a new macbook and found the pymc-marketing example wont run for me on it. It hangs up when calling mmm.fit(...) and doesnt get past the following message: Initializing NUTS using jitter+adapt_diag...
I'm using the install instructions from the pymc-marketing quickstart guide (installing with mamba).
I've done some troubleshooting and can safely say

Other PyMC models can fit in this environment (and even in the same notebook)
Defining the model manually and removing the geometric_adstock function allows it to atleast fit (but the model no longer makes sense) as shown below

with pm.Model(coords=self.model_coords) as self.model:

        ...

        # channel_adstock = pm.Deterministic(
        #     name="channel_adstock",
        #     var=geometric_adstock(
        #         x=channel_data_,
        #         alpha=alpha,
        #         l_max=mmm.adstock_max_lag,
        #         normalize=True,
        #         axis=0,
        #     ),
        #     dims=("date", "channel"),
        # )
        fake_param = pm.Normal("fake_param", 0, 5)
        channel_adstock = fake_param.dot(channel_data_)
        channel_adstock_saturated = pm.Deterministic(
            name="channel_adstock_saturated",
            var=logistic_saturation(x=channel_adstock, lam=lam),
            dims=("date", "channel"),
        )
       ...

Maybe this is related to pytensor and/or the batched_convolution function? Any ideas on system level things I need to install? I tried reinstalling xcode for instance but that didnt help
versions:

pymc-marketing: 0.3.2
pytensor: 2.18.4
pymc: 5.10.2

Same problem for me on a M1 Pro. Everything was working until i got PyMC Marketing 0.3.2 (had 0.3.1) Left the machine over the weekend and it is still at "Initializing NUTS using jitter+adapt_diag..." when I got here on Monday.

@geirrlod try downgrading to pytensor==2.18.1 that fixed it for me!
It seems like this is a pytensor issue, I tried downgrading to 2.18.1 and it worked, but as soon as I upgraded to 2.18.2 or higher I started running into this issue again.
Pytensor  2.18.2 looks like it was a pretty big release so I'm not quite positive what it was, but I'm seeing subtensors were changed and it seems to be like batched_convolution in pymc-marketing is where this fails, which use subtensors. Maybe thats related?
cc @ricardoV94

Can you instead try upgrading PyTensor to 2.18.4?

pytensor: 2.18.4

I tried pytensor 2.18.1 through 2.18.4 - pytensor 2.18.2, 2.18.3, and 2.18.4 all had this issue for me, while 2.18.1 did not have the issue

pytensor: 2.18.4

I tried pytensor 2.18.1 through 2.18.4 - pytensor 2.18.2, 2.18.3, and 2.18.4 all had this issue for me, while 2.18.1 did not have the issue

Thank you so much for that, would not even have thought about checking Pytensor, probably saved me days in debugging :-) 2.18.1 worked here as well

Thanks for trying it out, will have a look what the issue is.

Bug should be fixed by https://github.com/pymc-devs/pytensor/pull/566

This should be fixed in https://github.com/pymc-devs/pytensor/releases/tag/rel-2.18.5

This should be fixed in https://github.com/pymc-devs/pytensor/releases/tag/rel-2.18.5

Thank you @ricardoV94! Can confirm it works for me with 2.18.5

Shouldn't we cut a new release that pins that pytensor version?

Shouldn't we cut a new release that pins that pytensor version?

Yeah, we could do that

This seems stale. Current pymc might restrict this now: https://github.com/pymc-labs/pymc-marketing/blob/main/pyproject.toml#L20


Change cortex directory structure

The directory structure of cortex needs to be changed to accommodate for environments where cortex is installed to a machine while a user is developing from a local directory.
Key issue to address is that while a user is developing, they shouldn't be required to do this with elevated privileges. Since the package repository is located in /usr/local/lib, packages can't be installed here without sudo-ing each build command, which is annoying.
Therefore, packages (and other artifacts) will be stored in a local package repository that will be stored in the users home folder ($HOME/.cortex). The cortex loader will search this location as well when looking for packages.
The cortex install command shall move the package from the home directory to the global repository. Ultimately, this global repository shall be synced with the online repository whenever possible. Therefore, when installing a package, this should be considered equivalent to a git commit.
The directories under .cortex shall look like this:
/0.2.0/bin/
/0.2.0/lib/
/0.2.0/generators/
/0.2.0/libraries/
/0.2.0/components/
/0.2.0/packages/

The structure described above is not still standing.
Instead, now bin/lib/include are the first level of division and components/generators/packages/etc are subdivisions of the former.
Isn't that right?

The current implemented structure is correct. The structure that is described above was a first attempt. As we have discussed, the structure in .cortex will resemble how things are stored under /usr


[DOC] Improve Doc Strings for Temporal Cross validators

Describe the issue linked to the documentation

Currently, the docstrings do not have examples or see also sections.

Suggest a potential alternative/fix

Add simple examples and see also section linking to other cross-validation functionality.

Hi @knsantosh27 and sorry for the late reply. There is some documentation here: https://github.com/alan-turing-institute/sktime/blob/main/examples/window_splitters.ipynb but I agree that updating the docstrings would be helpful.

I think @khrapovs was working on this - I feel that has notably improved and we can consider this closed.


[Doc Issue] [update "validDomains" after adding authentication to message extension]

Acrolinx Scorecards
We currently enforce a minimum score of 80.
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
Score
Issues
Scorecard
Processed

msteams-platform/messaging-extensions/how-to/add-authentication.md
89
9
link
:white_check_mark:

More info about Acrolinx
Use the Acrolinx extension, or sidebar, in Visual Studio Code to check spelling, grammar, style, tone, clarity, and key terminology when you're creating or updating content. For more information, see Use the Visual Studio Code extension to run Acrolinx locally.

Docs Build status updates of commit c46fb9e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/messaging-extensions/how-to/add-authentication.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Acrolinx Scorecards
We currently enforce a minimum score of 80.
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
Score
Issues
Scorecard
Processed

msteams-platform/messaging-extensions/how-to/add-authentication.md
89
9
link
:white_check_mark:

More info about Acrolinx
Use the Acrolinx extension, or sidebar, in Visual Studio Code to check spelling, grammar, style, tone, clarity, and key terminology when you're creating or updating content. For more information, see Use the Visual Studio Code extension to run Acrolinx locally.

Docs Build status updates of commit 486821a:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/messaging-extensions/how-to/add-authentication.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Decouple pow from ethash

Signed-off-by: Antoine Toulme<EMAIL_ADDRESS>

PR description
This PR introduces a bit more flexibility around PoW operations, by renaming some classes that use the Ethash term to PoW. It also calls out explicitly the PoW algorithm used, if any. It introduces the ability to select the PoW algorithm in the hard fork schedule.
There is no functional change associated with this PR. Given that it refactors and renames a number of classes, I kept it engaged on this only.
Changelog

[X] I thought about the changelog and included a changelog update if required.

All good points and I can follow this pathway. I wanted to create a “dev-keccak256” network that would use keccak mining with a fixed difficulty. How would you go about that here? Set all fork blocks to 0 and add a new fork name for keccak? Would there still be a keccak config block next to the ethash one?

That is exactly what was done in the EIP-1559 test networks.  There can be a keccak config block configuring the parameters of keccak.  However I would expect this would only cover dev related options like fixeddifficulty as most of the parameters would be implicit in the keccak fork.  I would recommend ecip1049 for the fork name.

I think the goquorum compatibility boolean confused me, apologies. This should be a bit nicer now. I am about to push this, with a TODO for the actual keccak hasher algorithm.

I'm going to be a bit of a hard nose about this, but until the referenced ECIP (https://ecips.ethereumclassic.org/ECIPs/ecip-1049) specifies what has been discussed in this PR I'm not going to give it a serious review.  If we are implementing what should be specified in an ECIP then the ECIP should actually specify something.

ACK @shemnon - Proposal will be sealed shortly, and only thing left after sealing is to determine what block number it's activated on. See changes:

Added in an implementation standard here which outlines what exactly is changing.
Added in a verified miner test vector in the Appendix of the ECIP, which shows a single solved block with all of the inputs and outputs of the PoW specified.


4.0.37

A new inspection was created.

A new inspection was created.

The inspection completed: 330 new issues

The inspection completed: 330 new issues


python/task/power_of_digit.py

Complete the given task and attach a screenshot of the code and output

Please assign this isssue!

can you assign me this issue?


Range between date# does not working with different date format

Hi
Range between date# does not working with different date format
I am trying to use  format:'m/d/Y', but seem minDate/maxDate is working only wiht "Y/m/d" formate.
Thanks

If you change the format directly in jquery.datetimepicker.full.js file, it's works. Verified.


Fix a bug the pre-commit introduced and update the .git-blame-ignore-revs

Since https://github.com/XENONnT/fuse/pull/155 is squashed, the previous .git-blame-ignore-revs can not work. So I update the .git-blame-ignore-revs.
Also, fix a bug caused by pre-commit bot in https://github.com/XENONnT/fuse/pull/155. Thank @mhliu0001 for spotting this.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 66.667%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1782

Relevant Lines:
2673

💛  - Coveralls


home-assistant: 2021.4.0 -> 2021.4.1

Motivation for this change
https://github.com/home-assistant/core/releases/tag/2021.4.1
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 118865 run on x86_64-linux 1

3 packages built:

home-assistant
speedtest-cli (python38Packages.speedtest-cli)
python39Packages.speedtest-cli

Result of nixpkgs-review pr 118865 run on x86_64-linux 1

3 packages built:

home-assistant
speedtest-cli (python38Packages.speedtest-cli)
python39Packages.speedtest-cli

Result of nixpkgs-review pr 118865 run on aarch64-linux 1

1 package failed to build:

home-assistant

2 packages built:

speedtest-cli (python38Packages.speedtest-cli)
python39Packages.speedtest-cli

Any particular log you can share about the build failure?

Ported the speedtest-cli bump to 20.09 as it fixes a runtime error: 35d5d0d0676bac12b587580fa1d15c88efc879dc (commit message includes further details).


feat: Option to create Edge Functions with JavaScript syntax

What kind of change does this PR introduce?
This PR adds the option to create, serve, and deploy pure JS functions instead of using TypeScript.
Users can set EdgeRuntime.default_language to either JavaScript or TypeScript to set the language template they want to use. This can be overridden with lang flag when using functions new.
functions serve and functions deploy will now treat for both index.js and index.ts as valid entrypoints.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>9
Details

42 of 59 (71.19%)  changed or added relevant lines in 5 files are covered.
21 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.1%) to 60.125%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

cmd/functions.go
1
2
50.0%

internal/functions/deploy/deploy.go
7
11
63.64%

internal/functions/new/new.go
29
41
70.73%

Files with Coverage Reduction
New Missed Lines
%

internal/functions/new/new.go
2
78.13%

internal/storage/rm/rm.go
2
89.53%

internal/debug/postgres.go
3
64.86%

internal/gen/keys/keys.go
5
12.9%

internal/utils/config.go
9
86.0%

Totals

Change from base Build<PHONE_NUMBER>8:
-0.1%

Covered Lines:
6535

Relevant Lines:
10869

💛  - Coveralls

Will revisit this after we have support to update config.toml


Prepare videos to demonstrate vDVS features that can be uploaded on VMware youtube channel

Prepare videos to demonstrate vDVS features that can be uploaded on VMware youtube channel
cc @pdhamdhere

This is nice to have but not mustfix for kubecon release

Project Hatchway introductory video is out ---> https://www.youtube.com/watch?v=mZxQyHwAefY&t


Minor Improvement (but with minor effort) - AspectRatio Widget default ratio

Use case
The AspectRatio Widget does not come with a default value. That means everytime you have to enter a aspectRatio. That is totally fine, but it turns out that (at least for me) the aspect ratio 1.0 is the most used one (square dimensions). I suggest assigning the default value of 1.0 to the property so that you not always have to write the property in the coding workflow.
Proposal
So my proposal would be to change the following:
/// Creates a widget with a specific aspect ratio.
///
/// The [aspectRatio] argument must be a finite number greater than zero.
const AspectRatio({
  super.key,
  required this.aspectRatio,
  super.child,
}) : assert(aspectRatio > 0.0);

to:
/// Creates a widget with a specific aspect ratio.
///
/// The [aspectRatio] argument must be a finite number greater than zero.
const AspectRatio({
  super.key,
  this.aspectRatio = 1.0
  super.child,
}) : assert(aspectRatio > 0.0);

@darshankawar
what happen if I set aspectRatio  to -1, I suspect that assert is there for a reason

I am not convinced that 1 is the ideal default value here.

Why is that @goderbauer ? Even if there would be a default value that fits even better (which we don't know), having any default value is still better than having no default value.
That is because in a tiny percentage (let's say 5%) the chosen default value fits just perfect, and developers who code a lot will certainly remember the default value and know when not to use the aspectRatio.
And furthermore I think even if 4/3 or 16/9 would be a more often chosen default value, 1.0 is still the best option as it pushes no opinion on aspect ratio in general. It's just a square


Feature: APPLICS-465 - Welsh translation - have your say journey 2/6

Describe your changes
https://pins-ds.atlassian.net/browse/APPLICS-465?atlOrigin=eyJpIjoiZjdmMjkyYmI5NWIxNDgxOGFiNWJkYjhmODQ1NDJkY2MiLCJwIjoiaiJ9
Type of change 🧩

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update
[ ] Other (please explain in the description section above)

Checklist before requesting a review

[x] I have performed a self-review of my own code
[ ] I have double checked this work does not include any hardcoded secrets or passwords
[ ] I have made corresponding changes to the documentation
[ ] I have provided details on how I have tested my code
[ ] I have referenced the ticket number above
[ ] I have provided a description of the ticket
[ ] I have included unit tests to cover any testable code changes

:tada: This PR is included in version 1.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.27.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.33.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.14.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[1.9.1 multicluster] when remote kube-api server is down, istiod fails to start

Bug description
I have a multi-cluster istio deployment (Multi-Primary on different networks). There is one cluster that we call the "central" cluster and all the others are "edge" clusters. Central cluster needs to reach all the edge clusters and every edge cluster only needs to reach the central cluster.
In my central cluster I have created the secrets for the edge cluster kubeconfigs, configured the istiooperator etc. and everything works fine.
One day one of my edge clusters kube api server went down and so the server configured in the istio-remote-secret-<clustername> of the central cluster was no longer reachable.
After that there was a restart of the istiod pod on the central cluster. Since then the istiod pod is not able to start.
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Expected behavior
If the remote cluster is down, it should not affect the other clusters.
Steps to reproduce the bug
To reproduce this bug you can edit the remote secret of any working multicluster setup to point to some invalid URL and restart the istiod pod.
Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)
istio 1.9.1
kubernetes 1.20
How was Istio installed?
Istio Operator

This is already fixed in a later 1.9.x version, please upgrade: https://github.com/istio/istio/pull/31876. Thanks!

verified working in 1.10.1.


Update 'Organized by FOSSASIA' section

This fixes issue #2136 . Updated the section removing excess html code and added space after the content following site design. Preview at https://pranavkarthik10.github.io/open-event-wsgen/FOSSASIASummit/index.html.

Gh-pages is generated automatically. Fixes need to be made in the generator itself. We need the generator itself to work. Therefore closing this.

Gh-pages is generated automatically. Fixes need to be made in the generator itself. We need the generator itself to work. Therefore closing this.

I didn't realize this was linked to the generator. I'll work on the generator code to fix the issue. Thank you for pointing me in the right direction.


Deleting a wallet leads me to blank screen (Next)

I deleted one of my non-used testnet wallets and was sent to a blank screen.
See screencast here: https://streamable.com/d27ew
Expected Behavior
I think Zap should go to some other wallet, even if it is random, I think that would be fine.

Fixed via #1015


Showing ' HTML code of single quote character

What& #39; s の新しい → 新着情報
https://docs.microsoft.com/ja-jp/yammer/yammer-landing-page

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 701c4134-00e1-34c7-e7d0-75f521733c9a
Version Independent ID: 8233cbcd-59ee-a3e1-f3c1-07ae522bef21
Content: Yammer admin key concepts
Content Source: yammer/get-started-with-yammer/admin-key-concepts.md
Service: yammer
GitHub Login: @IrenePasternack
Microsoft Alias: v-irpast

@samanthaw @MollyMalone

@hyoshioka0128 Great bug, thanks for reporting.  I see the same issue for all languages, not just Japanese.   I shared with the localization vendors and they will fix it soon.

The article was previously MachineTranslated, we changed it to HumanTranslation to fix the issue. Topic was updated and published live.
Best Regards,
Michal


Fix/insert site name

Ask site name.
Ask if is multisite.
Add domain on host.

Hey @lzcalderaro thanks for the PR - this branch seems quite out of date with our master branch, and is unsafe to merge. There's changes to the main docker-compose, as well as other items.
If you can make another pr, that has just the changes you're trying to make, that may be better.

Prompting for site name and whether or not this is a multisite is now part of the setup scripts.


add h2::Error as a source for tonic::Status when converting from h2::Error

Motivation
A gRPC server may send a HTTP/2 GOAWAY frame with NO_ERROR status to gracefully shutdown a connection. This appears to Tonic users as a tonic::Status with Code::Internal and the message set to h2 protocol error: protocol error: not a result of an error.
The only way to currently detect this case and differentiate it from other internal errors (e.g., an application-level internal error) is to match on the message. A client may want to differentiate these cases because it may only want to alert on the application-level internal error and not on the transient transport-level issue. (Indeed, this is the use case for which I'm envisioning using this change.)
Matching on a message is not as robust, however, as matching on an h2::Error and its reason code. (The message could change for example if a future version of Tonic decided to vary the message. This would break any users that matched on the previous version of the message.)
Solution
Store the h2::Error used when creating a tonic::Status from a h2::Error and provide it as the source for purposes of std::error::Error. This will allow users to downcast it and match on the original h2::Reason.
Note: tonic::Status must now manually implement Clone becauseh2::Error cannot implement Clone since one of the Kind variants stores a std::io::Error (which does not implement Clone). Since we know that h2_error will always have a reason since we only store it in that case, this manual implementation of Clone just extracts the reason and creates a new h2::Error from it to "clone" it.

This could also be simplified to just have Status carry a h2_reason field and not support any of the std::error::Error::source functionality. (There would be a h2_reason method returning an Option<h2::Reason>).

@tdyas do you wanna drive this home? We would like to include the change to Status in the upcoming 0.5 release.

I modified the PR to add a generic source field, although my Rust knowledge is not as advanced so not sure what the right invocation to use to fix this error:
error[E0277]: the trait bound `Box<dyn std::error::Error + Sync + std::marker::Send>: Borrow<dyn std::error::Error>` is not satisfied
   --> tonic/src/status.rs:633:35
    |
633 |         self.source.map(|err| err.borrow())
    |                                   ^^^^^^ the trait `Borrow<dyn std::error::Error>` is not implemented for `Box<dyn std::error::Error + Sync + std::marker::Send>`
    |
    = help: the following implementations were found:
              <Box<T, A> as Borrow<T>>

This seems to do the trick
impl Error for Status {
    fn source(&self) -> Option<&(dyn Error + 'static)> {
        self.source.as_ref().map(|err| (&**err) as _)
    }
}

Removing Clone on Status causes a test in prost.rs to fail but that can be fixed with
let messages = std::iter::repeat_with(move || Ok::<_, Status>(msg.clone())).take(10000);

Edit: Which apparently github doesn't let you do... How do you go from "approved" to "not approved yet" without "request changes" 🤷

Not sure but I can hit the re-request review button to reset that state (which I just did).

@tdyas @davidpdrsn any updates on this?

I haven't had a chance to work on an integration test for this due to my work schedule. I see there is now a merge conflict, in trying to fix that, I am having a compile error in tonic/src/transport/server/recover_error.rs due to err's ownership passing into Status::try_from_error and not being available in the else branch:
                if let Some(status) = Status::try_from_error(&*err) {
                    let mut res = Response::new(MaybeEmptyBody::empty());
                    status.add_header(res.headers_mut()).unwrap();
                    Poll::Ready(Ok(res))
                } else {
                    Poll::Ready(Err(err))
                }

I will need to adjust the Status::try_from_error signature to pass the err back out so the caller can recover it if the conversion fails.

I rebased the PR and now it fails with:
---- picks_client_timeout_if_thats_sorter stdout ----
thread 'picks_client_timeout_if_thats_sorter' panicked at 'assertion failed: err.message().contains(\"Timeout expired\")', tests/integration_tests/tests/timeout.rs:60:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- cancelation_on_timeout stdout ----
thread 'cancelation_on_timeout' panicked at 'assertion failed: err.message().contains(\"Timeout expired\")', tests/integration_tests/tests/timeout.rs:22:5

Are those tests relying on TimeoutExpired being preferred?

@davidpdrsn ^

Also, I had to add Send + Sync bounds to the Error passed into Status::try_from_error to get it compiling. Not sure how to have Rust "pass through" Send+Sync if present onto the result type of a method.

Are those tests relying on TimeoutExpired being preferred?

Yes we should still downcast that error correctly. I did some digging and this fixes it:
diff --git a/tonic/src/status.rs b/tonic/src/status.rs
index ef9731a..927d95b 100644
--- a/tonic/src/status.rs
+++ b/tonic/src/status.rs
@@ -320,12 +320,6 @@ impl Status {
             Err(err) => err,
         };

-        #[cfg(feature = "transport")]
-        let err = match err.downcast::<crate::transport::TimeoutExpired>() {
-            Ok(timeout) => return Ok(Status::cancelled(timeout.to_string())),
-            Err(err) => err,
-        };
-
         #[cfg(feature = "transport")]
         let err = match err.downcast::<h2::Error>() {
             Ok(h2) => {
@@ -555,6 +549,11 @@ fn find_status_in_source_chain(err: &(dyn Error + 'static)) -> Option<Status> {
             });
         }

+        #[cfg(feature = "transport")]
+        if let Some(timeout) = err.downcast_ref::<crate::transport::TimeoutExpired>() {
+            return Some(Status::cancelled(timeout.to_string()));
+        }
+
         source = err.source();
     }

Also, I had to add Send + Sync bounds to the Error passed into Status::try_from_error to get it compiling. Not sure how to have Rust "pass through" Send+Sync if present onto the result type of a method.

Nah I don't think there is another way. Its fine 👌

Pushed @davidpdrsn's fix for the timeout error decoding.

GOAWAY frame with NO_ERROR status to gracefully shutdown a connection. This appears to Tonic users as a tonic::Status with Code::Internal and the message set to h2 protocol error: protocol error: not a result of an error.

I believe the official GRPC-on-h2 spec says that this should be mapped by the library to a UNAVAILABLE code; the user of the library shouldn't have to deal with recognizing it. https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#goaway-frame


[Suggestion] Add option to hide "Discover More" section

Recently, Twitter has been showing this useless "Discover More" section below replies, and I can't find a way to hide it with CSS, so it'd be really appreciated if you could implement an option to hide this section from the replies.

Also, this seems to only happen in the media viewer, on the right. When I open the Tweet normally, this section doesn't show up.

There's already a feature for this but they keep moving it around and changing it - will try to fix it in its new location

Thanks!

It looks like if you open a Media tweet with not enough engagement to fill the screen, Twitter is inserting this as filler :confounded:

I'm seeing this on replies with images or quote-tweets; plain replies don't have it.

Just installed the latest userscript and I also see them.

@ketsuban @biggestsonicfan could you provide some screenshots and links to tweets you're still seeing them on? It would be useful when trying to figure out why they're still appearing.

Sure.
https://twitter.com/XC_Enel/status/1671229689497518101
https://twitter.com/ManishEarth/status/1671212496273969152
https://twitter.com/notrevenant/status/1671184957308383232

Those are all getting hidden for me using the latest version of the extension (v3.8.1) or user script (v112)

Hm. I thought I had the most recent version but I just now saw I'm apparently still on 3.6. I'll try and make it update and see if that fixes it. Sorry to waste your time like this.

The update may have resolved it for ketsuban, but the issue persists for me on 112 userscript :(

The 113 script appears to be working with a caveat: It's still showing "Discover More" tweets of the same user.
Example

No dice yet with 114. I don't know why I specifically am having the issue, hmm... maybe a conflict I will investigate...

Did a reinstall of 117, seems to have done the trick. I only see "Discover More" of the same user now, which is acceptable!

Could you link to some tweets you're still seeing it on?
Setting debug = true at the top of the script should let you see what it's seeing in the console
It should look something like this when you navigate to a tweet and it has Discover More tweets to hide:

Using our old friend https://twitter.com/notrevenant/status/1671184957308383232

Joining in to confirm this is still happening with the Firefox addon 3.13.1.
Example tweet: https://twitter.com/yn_szk/status/1684851187261247488/photo/1

I don't see a way to enable debug mode in the addon.

We've had quite a few releases in the last two weeks and I know this is a backburner issue compared to what's come up recently but can you at least confirm the issue is reproducable on your end?
Remember, it's not just opening a media tweet, you must also enlarge an image.

Are any of you hiding the Messages drawer? And if you unhide it, is it open?

I do not hide the Messages drawer, no.

It is hidden by default
https://github.com/insin/control-panel-for-twitter/blob/eed8873d7b68ad6397a25872e4555dde6bf7698a/script.js#L105C28-L105C28
So yes. This is with the message drawer unhidden:

You can faintly see "Messages" in the lower right corner.
This is with the Messages drawer open....

So as your state in your new issue "Media modal timeline detection fails if the Messages drawer is open" is 100% correct.

Ah, I see. I misunderstood what "messages drawer" is.
Can confirm that unhiding it, it was open. Closed it, rehid the drawer, and the issue is resolved. Thank you!

Hi,
It seems as though Twitter has changed something in the last few hours and the "Discover more" section is back again:

from this tweet: https://twitter.com/itvnews/status/1697016618793017636, but it's happening on all tweets I go into.

I've made sure I've updated the extension to the latest version, and the option to disable the "Discover more" section is checked:

See #408


fixed log statements with incorrect args

Issue #, if available:
Description of changes:

Some log statements have incorrect number of args. Replaced fmt.Errorf with package-defined utils.ErrNotFound to be consistent.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hi @haouc, could you please take a look at these changes? Thanks a lot!


Deprecation notice for upload-artifact when enabling debug

When enabling debug in the codeql init@v3 action, I get a deprecation notice for actions/upload-artifact that I do not get otherwise

We're aware of this deprecation notice. However, we're not yet able to update to upload-artifacts v4 since this version is not yet supported on GHES. When GHES starts supporting v4, we will be able to change the action as well.


Template tags support

In addition to our talk:
Its quite hard to accomplish tag parsing the way you proposed, as long as there is no easy way to pass additional template tags to Template.__define__ without rewriting entire html_scanner.
What about creating template helpers, like:

{{inheritsHelpersFromTemplate 'template_name'}}
{{inheritsEventsFromTemplate 'template_name'}}
{{replacesTemplate 'template_name'}}

For copyAs it's not needed as 'pure' idea of having it is to avoid creating HTML file for a view that inherits from abstract one its properties.
I've created sample UI helper for that:
UI.registerHelper('inheritsHelpersFromTemplate', function (tmpName) {
    UI._templateInstance().__view__.template.inheritsHelpersFromTemplate(tmpName);
});

<template name="foo">
    {{inheritsHelpersFromTemplate 'bar'}}
    {{#each photos}}
          <img src="{{images.[0].source}}" />
    {{/each}}
</template>

and it works! :+1:
PR?

I still think it would be best to use additional template attributes for this (e.g., <template name="foo" inherits-helpers-from="bar">), but as you said the core packages don't currently make this possible. It would be good to get a final verdict from MDG on whether they're willing to fold this package into blaze/templating packages, or whether we can do a PR to support tracking additional attributes that are added to template tags. Since they now take feature requests on GitHub, I'll submit an issue.

Some time ago I also create a spaceless which removes all the whitespace. One idea I had then was that this could be simply an attribute on the template as well. So you could do <template spaceless="true">...</template>. In general having custom annotations on the template could be helpful. So PR for any attributions become maybe simple values in template instance. So <template name="test" foo="bar"> would be the same as:
Template.test.created = function () {
  this._foo = "bar";
};

Or maybe:
Template.test.created = function () {
  this.attrs = {foo: "bar"};
};

Yep, this.attrs is how I was picturing it working, too.


PowerMockIgnorePackagesExtractorImpl should get ignored values in whole hierarchy

From<EMAIL_ADDRESS>on September 07, 2009 10:06:38
..and not just the actual test class.
Original issue: http://code.google.com/p/powermock/issues/detail?id=150

From<EMAIL_ADDRESS>on September 08, 2009 23:43:17
Status: Fixed


add blog for e2e debug

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

请 @CH3CHO  一并看看，给些建议

@johnlanni 已修改

It is ok.

这里可以加一篇，内容里面链接到这篇blog不

是这样吗，貌似不生效，想着让文档里的md能够完全展示出来blog里的内容。

直接加个链接地址就行

已修改

@sjcsjc123 CI失败了

简单一些，用http链接也可以


Renew TLS certificates at Let's Encrypt

Expire on Nov 2.
https://gratipay.freshdesk.com/a/tickets/10089

On it. 👍

Ping.

http://inside.gratipay.com/howto/install-a-tls-certificate


fix: undefined failures & JSON error

Closes https://github.com/nodejs/node-core-utils/issues/496.
Fixes two things:

FAILURE_TYPES_NAME should be imported from CIFailureParser
this.json should be set regardless of whether the user has chosen to pass --json

cc @mmarchini

@nodejs/node-core-utils if someone wouldn't mind taking a quick peek before the next release that'd be great 🙇🏻♀


Are you going to continue?

https://github.com/OskarRayFrayssinet/Lights/blob/0cbca62751c2feceedbbd8937ff1196b60ea0297/LightsJavaProject/src/Lamp.java#L4
Are you going to continue with this project?


Allow character ranges in allowed-confusables for RUF001, RUF002, & RUF003

Rules RUF001, RUF002, and RUF003 help flag potentially ambiguous Unicode characters. While the configuration variable allowed-confusables can be used to specify allowed Unicode characters, it can become cumbersome to define allowed-confusables for projects whose docstrings use a lot of mathematical notation, or projects that are written in languages that use (for example) the Cyrillic alphabet.
It would be quite convenient if allowed-confusables could contain character ranges. Some possible use cases are:
allowed-confusables = ["α-ω"]  # lower case Greek letters for use in equations
allowed-confusables = ["∀-⋿"]  # Mathematical operators Unicode block
allowed-confusables = ["Ѐ-ӿ"]  # Cyrillic alphabet

Allowing character ranges would make it easier to configure exceptions to these rules.  It'd also be less likely that we'd forget to include certain Unicode characters.
A related possibility would be to allow regular expressions, since there may be some use cases where a certain character should be allowed but only in a specific context.
Many thanks!

That does sound annoying. I just looked through VS code's confusable code and it seems to have some concept for locale confusables. That's why I'm not sure if allowing character ranges is the right solution. Maybe a better approach is to allow configuring the locale(s) and if mathematical operators should be allowed.

That does sound annoying. I just looked through VS code's confusable code and it seems to have some concept for locale confusables. That's why I'm not sure if allowing character ranges is the right solution. Maybe a better approach is to allow configuring the locale(s) and if mathematical operators should be allowed.

Very interesting! I hadn't thought of that!  I updated the title to include that possibility.


Missing scope

Maybe I am missing something, I have just cloned the repository to debug and after sending this PR for the doc https://github.com/IdentityServer/IdentityServer4/pull/4382
I cannot make working my IdentityServer setup.
In https://github.com/IdentityServer/IdentityServer4/blob/master/src/EntityFramework.Storage/src/Stores/ResourceStore.cs#L146
no scope is found.
I have ApiScopes table empty. Only ApiResourcesScopes has one row.
In samples / demo projects I don't remember to see manually init ApiScopes.
My config before adding scopes inside ApiResource https://github.com/enkodellc/blazorboilerplate/blob/development/src/Server/BlazorBoilerplate.Storage/IdentityServerConfig.cs

Thanks. see my other reply.


Fix having to defined custom proxies multiple times (FRONTIER-366]

If you defined a proxy in setupProxy, it did not apply to storybook
or heroku local. This change activates proxies in setupProxy
in all dev environments.
Fix for https://almtools.ldschurch.org/fhjira/browse/FRONTIER-366
There are other solutions for this, but this one seemed to do the least refactoring, at the expense of overloading the module.exports on setupProxy.
I'm open to other solutions.

Awesome!


How to use moltemplate to construct crystals, such as SiC

Hello, Andrew.
I'm a student who just started using moltemplate. I found that the examples in official website of moltemplate do not include crystal construction, such as hexagonal crystal of SiC. This confuses me, and I can't build it after looking for many methods. Can you give me a simple example for me to learn? Please reply me, thank you very much.

Hi S1mplecool
Here are a couple of examples showing how to build simple crystals with moltemplate:
The first example (FCC aluminum) is probably the most simple and useful:

Aluminum (FCC)
a) File that defines the unit cell: al_cell.lt
b) File that defines a small crystal (10x10x10): system.lt
c) Pictures and description: README.md
d) Command to run moltemplate.sh:

moltemplate.sh system.lt    # (add "-vmd" if VMD is installed)

In this example, the forces between atoms are determined by a many-body force field ("pair_style eam/alloy").  No explicit bonds between atoms are used.
Here is a more fun version of this example

Water Ice (hexagonal):
a) File that defines a water molecule: spce.lt
b) File that defines the unit cell of 8 water molecules: spce_ice_rect8.lt
c) File that defines a small crystal (3x2x2): system.lt
d) Pictures and description: README.md
In this example, the forces between atoms in the same molecule are determined by bonds (and RATTLE constraints), and the forces between atoms in different molecules are determined by Lennard-Jones and electrostatic forces.

Graphene (2-D hexagonal crystal):
a) File that defines the 2-D unit cell: graphene.lt
b) Instructions how to build a 2-D graphene crystal are here
c) Pictures of graphene and carbon nanotubes built this way: README.md

In this example (and the next example: graphite), there are no bonds between atoms.  It is possible to use many-body force fields to simulate the motion of these atoms.  However at low temperatures (eg. 300K), I would not expect the atoms to move enough to deform or break the graphene.  For this reason, I decided to make the graphene rigid.  (To do that, I used "fix rigid".)  The method used to do this is different depending on whether you are running your simulations at constant volume or constant pressure.  (See the run.in.nvt and run.in.npt files for this example.)

Graphite (3-D hexagonal crystal):
a) File that defines the 3-D unit cell: graphite.lt
b) Instructions how to build a 3-D graphite crystal are here

Note 1: If you want to put impurity substitutions at random places in the crystal, this is possible, but it is more difficult.  Probably the easiest way to do that in this case would be to write a short for-loop (in python or even BASH, for example) that generates a list of LAMMPS "set" commands to change the type of random atoms in the crystal. This might look something like this:
:
set atom 1486 type 1
set atom 1487 type 2
set atom 1488 type 2
set atom 1489 type 1
set atom 1490 type 1
set atom 1491 type 1
set atom 1492 type 1
set atom 1493 type 2
set atom 1494 type 1
set atom 1495 type 1
set atom 1496 type 1
set atom 1497 type 1
:

Save this text in a file (eg "random_types.in"), and read them into your main LAMMPS input script (eg "run.in") using the "include" command in LAMMPS (eg. "include random_types.in").  I'm not sure if the positions of the impurities should be truly random, however.  (They might cluster together.)
Note 2: If you want to have explicit bonds between atoms in different unit cells, this is difficult to do using moltemplate (or VMD/topotools, or just about any other software).  You would have to add these bonds manually.  (There is a way to do this automatically, but I did not want to spend the time to implement it.  It gets a little bit tricky when you have periodic boundary conditions.  I can share this with you if you want.)
I hope at least one of these examples is useful to you.


Mouse modifiers should be propagated

Currently alacritty does not propagate modifiers for mouse reports. Some applications might make use of the ctrl or alt modifier, this should be propagated to the application following the xterm implementation.
Propagating shift should not be necessary because shift stops alacritty from propagating the mouse to the application.
An application that makes use of this is kakoune.

This will require changing alacritty's terminfo, because xterm is not able to propagate ctrl to programs (it's used for a GUI popup).


Integration Test - Release - 2022/04/11 06:56:23

Auto create for integration test. IssueCommandFlow

#pri1

Just type '#pri3'

#pri2

#pri3

#assign PRMergerTest1

#assign NonAllowedUser

#reassign PRMergerTest2

The following users don't have valid GitHub IDs, or are not collaborators on this repo: nonalloweduser

#reassign NonAllowedUser

#please-close

The following users don't have valid GitHub IDs, or are not collaborators on this repo: nonalloweduser

GitHub user PRMergerTest2 has been removed from the MicrosoftDocs organization, so they were automatically removed as an assignee.

#unassign PRMergerTest1

#unassign NonAllowedUser


streamalert - rules.rst - outputs

to: @airbnb/streamalert-maintainers
Denote that one element must exist in outputs

@jacknagz done


Add tags to AWS Recipes

This PR adds tags to AWS resources created by Recipes

@rynowak @willdavsmith any other suggestions for additional tags or improvements?


Use short syntax for named slots

Can the prettier plugin be configured to use the short slot syntax (with the colon)?
<x-slot:title>
    {{ __('My Title') }}
</x-slot>

{{-- gets formatted into: --}}

<x-slot name="title">
    {{ __('My Title') }}
</x-slot>

This behavior has been improved in 1.6.5. Instead of having a new configuration option, the internal parsers will detect which style the slot was originally and restore that after formatting (internally it normalizes it to a normal tag pair so prettier doesn't freak out).

Thanks! Works perfectly!


Add swap disk as vdisk support

@dongyanyang It would be much helpful if you can join to review this PR.

As we discussed, can we add a config option to enable vdisk swap?