Leverage Tekton for training pipeline

What would you like to be added?
I would like to give a credit to @rootfs who give me an idea about using tekton to perform training pipeline in a cloud-native way.
Why is this needed?
Currently, script in model_training folder has to run manually to collect data, train, and export the model.
Instead of that, we can utilize tekton to allow anyone to simply run (ad well as modify their own training pipeline in a declarative way) with Pipeline and Task CR.
FYI:
my workspace for working on this issue: https://github.com/sunya-ch/kepler-model-server/tree/tekton
Signed-off-by: Sunyanan Choochotkaew<EMAIL_ADDRESS>

One scenario now can be tested.
Check https://github.com/sunya-ch/kepler-model-server/tree/tekton/tekton.

Implementation done.
kubectl get pipelinerun
NAME                              SUCCEEDED   REASON      STARTTIME   COMPLETIONTIME
example-abs-train-pipeline        True        Completed   68m         66m
example-complete-train-pipeline   True        Succeeded   64m         61m
example-dyn-train-pipeline        True        Completed   66m         64m

Need two PRs to merge in order.

https://github.com/sustainable-computing-io/kepler-model-server/pull/195
https://github.com/sustainable-computing-io/kepler-model-server/pull/196

Note:

Since example-abs-train-pipeline and example-dyn-train-pipeline shares the same pipeline definition for single train run, train-dynamic-power-model and train-absolute-power-model task is skipped, respectively. So, the status is Completed.

Meanwhile example-complete-train-pipeline runs only original-pipeline-task task. So, the status is Succeed.

Reference: https://tekton.dev/docs/pipelines/pipelines/#pipelinerun-status-with-finally


TestCafe - Getting 401 Authorization error on logging into application when test cases are executed one after another in same window (disableMultipleWindows:true)

What is your Scenario?
TestCafe - Getting 401 Authorization error on logging into application when test cases are executed one after another in same window (disableMultipleWindows:true)
Scenario:-
We are testing end to end using multiple applications.

User logs into Application1 using Microsoft Login credentials.
Performs some actions in APplication1.
User logs into APplication2 (outlook.com) using Microsoft login credentials and performs some action.
Test Case 1 ends
Test Case 2 begins in the same browser.
In Test Case2, when user tries to login to Application 1 using same credentials then user is getting Authorization 401 error page after entering the credentials.
Looks like caching related to login is not cleared.

I tried User Roles and disable disablePageCaching as well, but no luck.
Please note that the issue works fine when  disableMultipleWindows:false and I open each application in new window. However, I cannot use this since there are lot of test cases that will need to be changed if we use this feature.
Wanted to check if there are any alternatives or some known issue regarding this.
What is the Current behavior?
Getting 401 Authorization error on logging into application when test cases are executed one after another in same window
What is the Expected behavior?
User should not get the error
What is your public website URL? (or attach your complete example)
NA
What is your TestCafe test code?
Cannot share the code here for now.

User logs into Application1 using Microsoft Login credentials.
Performs some actions in APplication1.
User logs into APplication2 (outlook.com) using Microsoft login credentials and performs some action.
Test Case 1 ends
Test Case 2 begins in the same browser.
In Test Case2, when user tries to login to Application 1 using same credentials then user is getting Authorization 401 error page after entering the credentials.
Looks like caching related to login is not cleared.

TestCafe version
1.18.6
Node.js version
14
Command-line arguments
C:\Program Files\nodejs\node.exe --max-http-header-size=10240000 .\test-runner.js --browser=chrome --concurrency=1 --environment=QA1 --suite=""
Browser name(s) and version(s)
No response
Platform(s) and version(s)
No response
Other
No response

The applications url are internal and hence cant be shared. However, I can share my screen in zoom/teams if someone is available to debug the issue.
Also I have noticed that the issue is similar to the below. However there was no solution mentioned in it as well.
https://github.com/DevExpress/testcafe/issues/3780

We understand that you cannot share a full project for certain reasons. In this case, please prepare a simple sample that demonstrates the issue. A screen sharing session in zoom/teams is not effective, so we do not use this approach.

@AlexKamaev  is there a way I can close the browser after every test case and launch the browser for a new test case when multiple test cases are executed in parallel and disableMultipleWindows:true  ??

No. TestCafe cannot close browsers between different test runs. TestCafe opens a browser and keeps it opened until all tests are finished.


Add rumble support

Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Adds rumble support for MBC5 and MBC3.

What is the current behavior? (You can also link to an open issue here)
Currently, rumble support can only be activated using GBVM scripts and only supports a single, non-standard MBC3 cart.

What is the new behavior (if this is a feature change)?
With slight changes to GBVM and GB Studio, MBC3 and MBC5 rumble is supported and can be accessed easily with the "Rumble On" and "Rumble Off" events.

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
None that I am aware of.

Other information:
Requires pull request 153 of GBVM.
I've changed the cartridge type of MBC5 from 0x1B to 0x1E, which has all the same features as 0x1B but with rumble support. I am not sure if there was a reason for using 0x1B, so I replaced it. If 0x1B is needed, then I can revert that and simply add another MBC5 entry for 0x1E instead. However, 0x1E does output a ROM that rumbles the controller using the VisualBoyAdvance-M emulator (and partially rumbles the controller with mGBA), whereas 0x1B does not rumble in any emulator that I am aware of.

Closing as it is out of date. May consider resubmitting in the future.


doc-Translate the Foundation page to French  #904

Please describe the changes this PR makes and why it should be merged:
Documentation(i18n): Translate the Foundation page to French closes #904
Status

[ ] Code changes have been tested against prettier, or there are no code changes
[ ] I know how to update typings and have done so, or typings don't need updating

Semantic versioning classification:

[ ] This PR changes the codebase

[ ] This PR includes breaking changes (methods removed or renamed, parameters moved or removed)
[ ] This PR changes the internal workings with no modifications to the external API (bug fixes, performance improvements)

[x] This PR only includes non-code changes, like changes to documentation, README, etc.

 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.

Overview of the french version

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

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 25.706%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1257

Relevant Lines:
5082

💛  - Coveralls

Hey there, @geoffreylgv. Can you pull latest changes from main?

Hey there, @geoffreylgv. Can you pull latest changes from main?

Ok

Hey there, @geoffreylgv. Can you pull latest changes from main?

Ok

Oh ok, awesome. Thanks. Push again after pulling the changes

Hey there, @geoffreylgv. Can you pull latest changes from main?

Ok

Oh ok, awesome. Thanks. Push again after pulling the changes

All good now @tobySolutions

LGTM @geoffreylgv. Great work.

LGTM @geoffreylgv. Great work.

Thanks


Investigate LLVM WebAssembly backend

We should evaluate whether the LLVM WebAssembly backend is an improvement over Emscripten and if so, whether we can switch to it.
Discussion below migrated from #4658

@blealtan
Have you considered LLVM wasm target? Though it's in experimental state, emscripten itself is not reliable enough either. If we have the tens of unresoved symbols fixed, using LLVM for backend codegen should be possible, and will also evolve minimum extra dependencies.

@morganbr
@Blealtan, I'm open to the idea if it simplifies setup for new developers and CI and works well enough to replace Emscripten. It does seem plausible that we'll use LLVM at some point. I haven't looked too closely at the LLVM target, but as far as I know, it's missing a few things:
I don't believe there's a binary distribution of it, so people would need to build it from source with a special flag set. I guess it might be possible for MS to build a copy and make a NuGet package or something though.
Emscripten provides an html page and JavaScript to host the WASM. This would have to be replaced by something (maybe handwritten html and JS?)
Emscripten can convert DWARF debug data to source maps. This isn't actually working for us right now, but I really hope we can start taking advantage of it soon.
Emscripten provides a fairly broad set of "system" APIs that I'm not sure whether LLVM has.
If there's a proposed way to handle all of those (and LLVM actually works with our output), then it could make sense to switch over.

@blealtan
@morganbr short replies on those points:

Yes because it's still listed in experimental targets rather than "all" (released) targets. An custom built package will be required before the LLVM team think it's mature.
Yes and I think I can help.
Not sure but LLVM itself provides rich scaffolds for doing these things, so I'm optimistic on that. Though I'm working on make it work and try it out.
AFAIK, LLVM is not responsible for implementing any "system" libraries, so if only LLVM, no. IDK if Clang or any other LLVM accompanied optional components like libc++ has did anything on this. However, accompanied with hand-written html & js, we have the opportunity to separate assemblies; that is to say, implement an assembly loader in js, port (maybe part of, at the beginning) dotnet runtime library to wasm, import the required interfaces from CoreFX wasm interface into user-built assembly (a standalone wasm instance), and that's it. "System" APIs shouldn't be directly called from user code; they're expected to be called in CoreFX, and the canonical way to do this should be import corresponding interfaces from js and implement System.* with the imported js interfaces.
I'll do some experiments on these and hold on for my update.

Also, I've tried LLVM on our output: the biggest problem is many unresolved symbols are generated. Emscripten simply ignores them and leave the risk to runtime, but LLVM seems to be doing a strict check. Do you have any idea where the unresolved symbols are from? EMCC also produces tens of warnings when generating HelloWasm.

@blealtan
@morganbr Okay and I have some results. LLVM's llc does compiles our generated code in HelloWasm.bc, with all thread_local modifiers removed (since this is not implemented in LLVM, rather than ignored as is in Emscripten) and target triple changed to wasm32-unknown-unknown-wasm according to LLVM's requirement. However, Generating libPortableRuntime has failed due to the usage of atomic instructions, which is again not implemented in LLVM instead of atomicity ignored as is in Emscripten; on this point, change the behavior in IR one by one is a time-wasting job so I didn't try to replace these instructions with non-atomic ones.
In short, generating our code with LLVM is possible, once we have our codegen fully thread-unrelated; even further, correct execution can be also expected, once we have our previously required "system" APIs by Emscripten implemented in JS and imported to our wasm instance. I think maybe the later one is the problem; not sure how many of these APIs are actually used by our code.
As to the debugging problem, source maps is generated according to !dbg directives rather than DWARF data in LLVM, and llc does great job on doing that mapping. I think providing that is acceptable, if we want debugging support one day. However, the critical point is that no explorer supports debugging wasm at this moment; this is what we should consider in the future.

Most of the unresolved symbols are probably P/Invokes from the framework into native libraries that build out of the CoreFX repository. https://github.com/dotnet/corefx/issues/26107 tracks creating a WASM build flavor for that repo.
It's possible we still have some RuntimeImports or RuntimeExports that aren't hooked up right correctly as well. I don't have the output handy, but if they start with "Rh", they're probably runtime imports or exports.

There's another problem though. If switching to LLVM backend, what will we use for native code compiling? Clang is currently capable of compiling to WASM directly either, with the corresponding target enabled; however generating debug information still needs a detour, first generate .bc then to .wasm. Anyway, if we are dropping Emscripten, we need something to do the native code compiling, which is most possibly Clang. Is shipping this over NuGet acceptable?
Also, I'm trying to switch to clang for generating our native codes and try the -mthread-model=single flag, seeing if there's nothing generated dependent on thread_local and atomicrmw. Hopefully I can bring some good news.

Okay the -mthread-mode single flag works fine but without Emscripten provided CMake platform file, CMake always try to detect wasm-only clang as a normal compiler - which is not since it cannot produce single executable - and thus produce an error on checking phase. I'll later try to write an standalone platform CMake configuration for the wasm-only clang to solve this.

Making a Clang NuGet package could be plausible, though it would certainly be easier to wait for an official build so we don't have to figure out how to build and package it for 3 OSes.

@Blealtan, to help my understanding, what do you expect that LLVM will do better (or worse) than Emscripten? Some interesting aspects to compare on could include:

Size of the generated WASM
Performance of the generated WASM (not sure if there would be any differences here since they're both using the LLVM optimizer)
Build time
Ability to distribute a working toolchain
Likelihood of implementing new WASM features as they arrive (particularly threading and exceptions)
Supportability over time (in other words, if we find bugs, will they get fixed?)
Integration into the CoreRT workflow

@morganbr Not having any extra ideas on the compare, I'll only cover what you've mentioned for now.
The first thing to point out is that Emscripten is firstly a self-implemented JS backend embedded Clang & LLVM toolchain, with WASM added later. So it will be clear that for LLVM WASM target:

Size of generated code is influenced by two factors: the level of optimization and the amount of extra code introduced. For the first part, see next para. For the latter one, LLVM's WASM target generates clean and neat WASM code without any additional content or assumption on environment; I don't know how is Emscripten performing on this, but at least it is importing large amount of functions into generated "executable", as Emscripten is pretending itself to be a Unix platform.

Level of optimization should be at least higher than Emscripten. The LLVM community has been implementing their WASM target from scratch without reusing Emscripten; in my opinion, this decision by them means they can do better (and also I think a compiler-expert community is more reliable on this than a web-expert community, which is exactly what Emscripten&WASM community was).

Build time is also related to how good the backend is implemented. As we all know, with higher level of optimization, it will turn to be longer; with better optimization on optmizer implementation, it will turn to be shorter. Assume the same level of optimization, I personally repeat my confidence on LLVM and it's community.

For distributing the toolchain to user, LLVM backend can be always referenced as a library, while emcc requires call to emcc.bat or emcc.sh, then internally to emcc.py, and so on. If using LLVM backend, we can embed the LLVM IR to WASM phase into ilc, making ilc generate wasm directly, instead of distribute CoreRT ILCompiler along with a large Emscripten SDK.

It seems LLVM is going to be the canonical platform that generates WASM code. It's mentioned on Roadmap - WebAssemly that

Next Steps
...
graduate the WebAssembly LLVM backend from experimental to stable (and update Emscripten)
...

This possibly means Emscripten will migrate to LLVM WASM target later on, since the Emscripten developers are mostly the same guys as in the WASM community and thus the WASM roadmap should be able to speak for Emscripten (in case the "big boss" both seems to be kripken).
In this case, there're reasons to believe LLVM will get consequently updated after WASM specification (which not yet exists).

LLVM the whole project itself has been actively updated for years; also for the recently started WASM target, there were 12 commits on it in the past one month. It's a large, active, open and responsive community backing LLVM, it should at least be not worse than Emscripten.

For the workflow of building CoreRT:

Environment setup would definitely get simplified, since Emscripten is simply more and larger than Clang & LLVM: it's even dependent on Java Runtime and Python. We'll be able to ship all the dependencies (a wasm-enabled customized build of Clang as compiler toolchain, and a wasm-enabled customized build of libLLVM; the first one might possibly be dependent on the later) over NuGet.
Native part building will rely on Clang, possibly allowing CMake to generate working MSBuild building system.

For the workflow of CoreRT building some code:

The ilc will be able to generate WASM directly, without requiring invoking emcc after the ilc codegen.

On every aspect there are reasons that LLVM will do better. One problem seems to be the build system: CMake does not recognizes clang on wasm, since it refuses to generate an executable during compiler test. I've been looking into how Emscripten avoided this and I've got some insights. Besides this, it will be that we don't know when will LLVM WASM target graduate from experimental state.

Interesting discussion here! Some notes and thoughts:
There are really 3 options,

Use emscripten with the asm2wasm backend.
Use emscripten with the LLVM wasm backend.
Use the LLVM wasm backend by itself, without emscripten.

About 1 vs 2, Emscripten plans to change its default from the asm2wasm backend to the LLVM wasm backend eventually. We haven't done that yet because we are still improving the LLVM wasm backend, it isn't stable yet and doesn't generate good enough code, but hopefully later this year. You can try it already though, just point emscripten to a build of LLVM with the wasm backend enabled.
About 2 vs 3, you can use the LLVM wasm backend without emscripten, but if you need some of the following things that emscripten provides, you'll need to implement them yourselves since the LLVM wasm backend can't do them:

Porting and building system libraries like libc, libc++, SDL, etc.
Support for longjmp and C++ exceptions.
Integration with web APIs like printing to the console, date/time operations, rendering to WebGL, etc.
Emulating a filesystem.

About code size and optimization, overall the LLVM wasm backend does not yet generate as good code as the asm2wasm backend. For example, on Box2D, which is pretty typical:

Emscripten with asm2wasm: 116K
Emscripten with LLVM wasm backend: 124K (7% bigger)
LLVM wasm backend by itself: 133K (15% bigger)
About half the 15% difference can be removed by running the binaryen optimizer, which is the main difference between the last 2 lines.

Regarding performance, the picture is more complicated as often the two backends' outputs run at the exact same speed. But in realistic workloads often the LLVM wasm backend is still slower, we need to do more work there (for example, 9% slower on zlib, 4% slower on bullet).
About build times, currently LLVM wasm backend build times are slower, because of limitations of LLVM's codegen (in particular, it is single-threaded, while the asm2wasm path can use multiple CPU cores for most of the work). However, this will matter a lot less when the LLVM wasm backend gets incremental compilation, which is making very good progress.
Overall, I think it's worth experimenting with the LLVM wasm backend even if it isn't better yet, as it should improve. Regarding using it with or without emscripten, that depends on if you need any of the emscripten features listed above.

Level of optimization should be at least higher than Emscripten. The LLVM community has been implementing their WASM target from scratch without reusing Emscripten; in my opinion, this decision by them means they can do better

This is a complicated topic!
I wouldn't say LLVM's wasm support is from scratch: it's built on the existing LLVM backend codegen infrastructure. That is its biggest advantage, since that codegen is incredibly powerful for generating x86 and ARM code, etc., but also its biggest downside, since it's slower to run and less good a match for WebAssembly.
By less good a match I mean that WebAssembly is quite different from x86 and ARM - for example, it has structured control flow. Things like that are the main reason the LLVM wasm backend emits larger code currently. I suspect that to really generate optimal WebAssembly it's better to work in an IR designed from scratch for it (like in the binaryen optimizer) but on the other hand perhaps with more work we can achieve similar results even in the LLVM wasm backend, even though it wasn't designed for WebAssembly. Too early to tell.

many unresolved symbols are generated. Emscripten simply ignores them and leave the risk to runtime

You can change that default by running emscripten with -s ERROR_ON_UNDEFINED_SYMBOLS=1.

Surprised that @kirpken is here! Thanks for your clarification and correction. Seems that I was betting too much on LLVM XD
The most critical problem I was considering is distributing and integrating, which sucks for Emscripten. We'll require users to have an EMSDK if using Emscripten, and a two step compilation also; which is really not so user friendly. Regarding the requirement on libc/libc++, I'm still new to this project and not able to draw actual conclusion.

I believe now would be a good time to move to LLVM 8 and the wasm backend (which is not experimental in 8) as for large programs we seem to be hitting https://github.com/emscripten-core/emscripten/issues/8393.  We need to wait for LLVMSharp to be built and packaged for LLVM 8 or do it ourselves (which I tried but so far have been unsuccessful).

There's already a task to track for LLVMSharp, https://github.com/Microsoft/LLVMSharp/issues/84

@jkotas @MichalStrehovsky  I think we can close this now.


chore(ssa): rename impl method to follow Rust guideline

Related issue(s)
Related to #780
Resolves #
Description
Summary of changes

Dependency additions / changes

Test additions / changes

Checklist

[ ] I have tested the changes locally.
[ ] I have formatted the changes with Prettier and/or cargo fmt with default settings.
[ ] I have linked this PR to the issue(s) that it resolves.
[ ] I have reviewed the changes on GitHub, line by line.
[ ] I have ensured all changes are covered in the description.
[ ] This PR requires documentation updates when merged.

Additional context

It's fine, but could you also fix the few spelling issues reported by the CI?

Those have been fixed in a PR that we merged a few hours ago, I've rebased the branch to pull in those changes


[HUDI-7218][Stacked on HUDI-7170] Integrate new HFile reader with file reader factory

Change Logs
This PR integrates the new native HFile reader with file reader factory.
Impact
Uses new HFile reader.
Risk level
medium
Documentation Update
N/A
Contributor's checklist

[ ] Read through contributor's guide
[ ] Change Logs and Impact were stated clearly
[ ] Adequate tests were added if applicable
[ ] CI passed

This PR is still WIP.  Sending the PR to Azure CI to run tests.

@hudi-bot run azure

@hudi-bot run azure


Bump Gophercloud to v1.1.0

With this change, we pull in the fixes in Gophercloud as well as a newer version of golang.org/x/crypto.
Notably, Gophercloud v1.1.0 is now perfectly tolerant to OpenStack object storage endpoints that omit content-type headers in 204 responses.
Additionally, CIRO now depends on a stable branch of Gophercloud.

It will be bumped by https://github.com/openshift/cluster-image-registry-operator/pull/816.

Perfect, thanks.


WPF: Stops PlottableCountTimer on Unload

New Contributors:
please review CONTRIBUTING.md
Purpose:
#1115

Hi @bclehmann ,
if it remains in this form, then it is worth shortening to 1 line:
Unloaded += (s , e) => PlottableCountTimer.Stop();

Great catch @Orace.
If we do not allow the user to manually manipulate the Plottable list. We don't really need a timer. We can raise CountChange event manually, in all methods that can change it. But these are just thoughts of how one could do it.
And for this PR, is definitely a good fix. Who would have thought that in WPF controls can be loaded and unloaded multiple times?

I'm not sure that the proposed implementation fix all corner cases for the memory leak. If we remove the parent element (like a grid) from the it's parent (like a window) does the unload element is called?
The proposed implementation may cause an other issue in my case (where I detected the memory leak too). I use a wpf object tree to create a XPS report file, later converted to pdf. The wpf tree is never connected to a window and so I'm not sure that the loaded / unloaded events are fired.
The implementation should get rid of the DispatcherTimer. If throttling is mandatory, I can propose an implementation based on Task that doesn't stuck in memory.

Hi @bclehmann, @StendProg, and @Orace 👋 I've been busy traveling and working on some personal projects but I anticipate having more time to work on ScottPlot again.
Intended Behavior (and why I used a timer)
To get us all on the same page, the core problem this timer thing is trying to achieve is:

Automatically render once when the control is first populated with data
Automatically re-plot when the number of plottables changes

I'm not using a CountChange event to trigger a render when the list of plottables is changed because:

If the user adds many things to their plot (e.g., 10 scatter plots) when their program starts, ten independent renders will occur, slowing their start-up time significantly.
If the user scatter plots then customizes the title, the render will be triggered before the title is updated.

When should the timer be started?

I believe that the PlottableCountTimer should be started on the Loaded event, otherwise the timer will not be restarted after the first unload event

This makes sense. This PR could be modified to achieve this. Similar functionality may need to be added to the WinForms and Avalonia controls.
Alternative Solution (use the render queue?)
Maybe instead of using a timer in the control to trigger plottable count checks and renders, a change to the plottables list could fire an event that adds add a fast delayed render (10 ms) to the queue. @StendProg you may be the most experienced with this system, what do you think of this idea?

I think if we were to ever consider automatically updating when the user changes plot properties or data then the render queue would be the most extensible solution that's been brought up. However, you could also have a system where these updates invoke a render more directly, which would probably make removing unnecessary renders easier.
I'm thinking of a simple debouncer, where it executes some time after the last time it was invoked. A smart delay is probably ~16ms so it's only 1 frame. I don't think we'd need to manually flush as I'd be very impressed if someone managed to continuously lock up this function for even one frame.
In principle, you could have both, when a proactive render is pushed to the render queue it doesn't render directly but simply calls a debounced render method. This should simplify things as we don't have to manage two different queue-like things, they can be treated exactly the same save for the handler at the other end of the queue.

For what it's worth, I still maintain that the inconsistency introduced by having some updates be automatically rendered but not others serves to confuse the API. One still ought to call Render, however this will be hidden in most situations. Instead of removing the bug from the user's code we have hidden it, and thus made it much more difficult to diagnose.
And in my opinion, having it update on timer instead of using an observable collection will normally mean that adjusting properties will be reflected in the automatic render. But it also introduces a race condition where the render happens after adding the plottable but before adjusting the properties. While adjusting virtually all properties should be very fast and this bad path should be very rare, it's an unnecessary bug which is obscenely difficult to even reproduce.
And it's not unforseeable that we have more complicated properties that can be slower to update, such as if we were to have properties that caused heatmaps to be renormalized. Such a thing would make racing the two codepaths much more likely.

Implementation Using the Render Queue

simple debouncer ... where it executes some time after the last time it was invoked

I think something similar is in place, and this could be extended to provide the 16ms functionality you recommend. EventsProcessor.cs has a "delayed render timer" and when it crosses a threshold a render is performed. Requests reset the timer so two requests in a row will just reset the timer twice and result in a single render. Right now the threshold is a fixed number (RenderDelayMilliseconds) but this system could be modified to support different delays.
Should Automatic Render() be Disabled Entirely?

For what it's worth, I still maintain that the inconsistency introduced by having some updates be automatically rendered but not others serves to confuse the API. One still ought to call Render, however this will be hidden in most situations. Instead of removing the bug from the user's code we have hidden it, and thus made it much more difficult to diagnose.

And in my opinion, having it update on timer instead of using an observable collection will normally mean that adjusting properties will be reflected in the automatic render. But it also introduces a race condition where the render happens after adding the plottable but before adjusting the properties. While adjusting virtually all properties should be very fast and this bad path should be very rare, it's an unnecessary bug which is obscenely difficult to even reproduce.

And it's not unforeseeable that we have more complicated properties that can be slower to update, such as if we were to have properties that caused heatmaps to be renormalized. Such a thing would make racing the two codepaths much more likely.

This is very well stated! There are multiple excellent points here. In an effort to simplify the basic case, the advanced case has become more confusing and harder to figure out. I'm struggling to figure out the best way to proceed...
Reviewing the Original Problem
formsPlot1.Plot.AddScatter(xs, ys);
formsPlot1.Plot.Title("Example");
formsPlot1.Render(); // <-- this line is required if a start-up render is not automatic

If an automatic render does not occur after the control is loaded, and the user does not know that render must be requested manually after setting-up the plot, the plot will appear empty when the application launches. When the user clicks or drags the plot data will suddenly appear. This is confusing and astonishing.
To achieve the intended behavior the user must manually request a render after setting-up the plot. This requires user knowledge: "When using ScottPlot controls you must call Render() after modifying the plot or its data." This fact is key to using ScottPlot in graphical environments, but doesn't apply to console applications and is not evident in the cookbook. If there were a way to ensure users know this, the render timer could be eliminated.
The quickstart website documentation could show this, but that page is easy to overlook. Another option could be to raise a pop-up readme file when users install the control alerting them of this fact. I find those a bit annoying, and the primary ScottPlot library already raises one, but it might be less annoying to users than trying to figure this out on their own.
Are there any other tricks I didn't think of we could use to maximize discoverability of the extra render step if the automatic render feature is eliminated?

NPM packages often give warnings or deprecation notices in the console? We could detect if they didn't call render and then log?
It's not particularly visible, but one could go further and draw text on the plottable or even throw if Debugger.IsAttached returned true. Maybe it could even be wrapped in with diagnostic mode.

one could go further and draw text on the plottable if Debugger.IsAttached

This is an interesting idea! I think I prefer this option over console debug messages and pop-up readmes 🤔
I don't want to make this decision quickly (it would be a breaking change), but I'm liking the idea of removing the complex/confusing automatic render system, and this API change and warning message may be the lesser of two evils.

The implementation should get rid of the DispatcherTimer

This PR is an improvement so I'll merge it now. Thank you everyone for your input!
Eventually I will remove this timer completely and mandate that the user call Render() at least once (#1165) which is a better long-term solution for the core problem the timer was originally intended to solve.


preprocessing on the frames

first thanks for this perfect program,
we want to do some process on frames before send them to the wall,
i noticed that there is a callback method and frame data in ut8 from, but it seems that in project
didn't use that at all, how can i get a frame before send it to wall, do some changes like filters,
then send it to the wall?

thanks, sorry current do not have this type of filters


Create TF template for Azure Front Door

Background
We would like to provide a self-service option that allows users to leverage pre-existing templates to aid in the conversion from AWS, Google Cloud, or on-premise resources to Azure-based Terraform.
Action requested
Create a template folder that contains the necessary files for creating a Front Door object in Azure.
Acceptance Criteria

main, _var, _data, and _output files should all be present.
Files should be complete with easily-replaceable variables that follow consistent naming conventions.
Proper comments and documentation should be added throughout the files.
Any optional pieces should be surrounded with comments, so that end users can enable and disable as desired.

Additional context
This will enable the NBS team to leverage our files for guidance as they action the conversion to Azure.

This may be an example of over-planning...we won't need this if the AGIC setup goes as planned. Icing for now; we can revisit this if the App Gateway setup goes poorly.

Architecturally obsolete. Closing as "Won't Do".


Issue 6 support enum string i18n

I'm going to merge your branch against the Hobo 1.3 branch, because master has evolved too much.


Only keep Document.Views temporarily

... until https://github.com/DynamoDS/Dynamo/issues/2970 is resolved

see #31


KeepPrefixOnExternal fix and sameDomainLinksRelative API clean-up

Hi,
I made some changes and a fix to previous PR #44 in light of removal of $_SERVER usage.
Proposed Changes

KeepPrefixOnExternal does not affect link tags' href attribute. The link tag is not an external link. It's a resource that must adhere to removePrefix.
makeSameDomainLinksRelative() accepts $localDomain string as parameter
Removed method setLocalDomain() - functionality merged into makeSameDomainLinksRelative()
Removed unnecessary call to setLocalDomain() with empty parameter It is up to user to provide a valid localDomain string.

This change is

Coverage decreased (-83.5%) to 9.89% when pulling 078b14c26da2d8041b20a35f5a077cb43e8dec72 on abuyoyo:pr/relative_links into d27882ff1d5073d3641c1b74ee4bee34c0a1b8fa on voku:master.

This still needs some work. I'm closing this for now.

I've fixed error in code.
And added unit-tests

Thanks for the update, good work. Now the api from "doMakeSameDomainLinksRelative() is more simple and there are more tests. :+1:

your changes are released with version 4.2.0
PS: I change the API a little

use "localDomains" (string[]) instead of "localDomain" (string)
use the same strange "do*"-naming as for all other methods :/


AL2-Thor window visualization

Hi! Thank you for your work!
I just downloaded the sft model of ALFWorld you provided and runing the RL finetuning. I noticed that i could change the env type in the alf-config.yaml. Is it normal to see the AlfredThorEnv Unity Window be open for all time during the RL training? will that slower the training time?

And especially sometimes it just stuck here for a long while.
Best regards

I think the solution to it might be listed here https://github.com/alfworld/alfworld/issues/47. I am not sure whether Alfred ThorEnv showed up during our training since we ran it on a remote server, but I would doubt it would slower the training. Could you first try out the solution listed above in the link and see whether the reset would finish? Please update us whether you are able to get it solved.


Add to PyPI

To do this properly, we should probably add a CLI command called s3-logs which takes two commands:

sync
parse

In the end a user could install this tool using
pip install s3-logs-analyzer

And then call it on the command line like that:
s3-logs sync
s3-logs parse


open drawer on click of manu button

i'm trying to open the drawer without sliding, just by clicking on some button from my main VC. please help me solve this.
i tried setDrawerState from KYDrawerController , compiler goes through all code but nothing happens on UI.

This issue might be helpful to you. https://github.com/EvianZhow/KYDrawerController-ObjC/issues/3


[4.0.0-alpha.2] Error doesn't match any project with a .js config file

I've worked around the issue by changing my config to a json, but I spent alot of time debugging this so I will try to help others.
the eslint plugin calls graphql configs loadConfigSync method with a root directory.
graphql config uses cosmiconfig - it uses a createCosmiConfigSync which uses the sync methods of createCosmiConfig and it correctly finds the file synchronously. However in prepareCosmiconfig it uses the default loader for js rather than the js sync loader. So js files get loaded async and a promise gets set as the config passed to graphql-config constructor, meaning no valid projects are found, which then results in the eslint package giving an error.
It seems 100% a bug in graphql-config so I raised a bug there, but since no-one seems to have found it, wanted to point it out here as we didn't get it until upgrading the plugin: https://github.com/kamilkisiela/graphql-config/issues/1454

fixed in<EMAIL_ADDRESS>


DST-762: Fix hide_cookies redirect

Jira
When the user is on a page other than task-list, and clicks to hide cookies, they were redirected to "/" which is the task-list. This PR fixes this behaviour by adding the redirect_back_to var into the form submission.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 73.69%. Comparing base (effa820) to head (b6dfdd3).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #230   +/-   ##
=======================================
  Coverage   73.69%   73.69%
=======================================
  Files          76       76
  Lines        2235     2235
=======================================
  Hits         1647     1647
  Misses        588      588

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Test dragzoom

@nrlakin i pulled down the drag zoom pr #512 it looks like it was just a question of updating the test to use jsdom etc.
for an example we found prometheus was using the DragZoom code for a while https://github.com/prometheus-junkyard/promdash/blob/81a9cf2308c9daa80be9464709dd40555d774fa3/app/assets/javascripts/angular/directives/graph_chart.js

Coverage decreased (-0.8%) to 61.049% when pulling 1f3756c628e3fc97a0c21a5be0dfd5b0dfc0d6e6 on cesine:test/dragzoom into 67e5b5cc084355d3bcfc2eaf190a79801d4d38b4 on shutterstock:master.

@cesine thank you, and thank you for maintaining this project!

Coverage decreased (-0.8%) to 61.049% when pulling dca119808c3d9a3486337c8e94e5c0db02f8dec7 on cesine:test/dragzoom into 67e5b5cc084355d3bcfc2eaf190a79801d4d38b4 on shutterstock:master.

Coverage increased (+1.0%) to 62.814% when pulling a30660b57f5b2044277eac5617317049beb4a98b on cesine:test/dragzoom into 67e5b5cc084355d3bcfc2eaf190a79801d4d38b4 on shutterstock:master.

Coverage increased (+1.0%) to 62.814% when pulling 5e7c97d6ca776b23f6841006fd7526e8c2f8f984 on cesine:test/dragzoom into 67e5b5cc084355d3bcfc2eaf190a79801d4d38b4 on shutterstock:master.

Coverage increased (+1.0%) to 62.814% when pulling 5e7c97d6ca776b23f6841006fd7526e8c2f8f984 on cesine:test/dragzoom into 67e5b5cc084355d3bcfc2eaf190a79801d4d38b4 on shutterstock:master.


feat(mission_planner): use allow_while_using_route

Description
use allow_while_using_route
https://autowarefoundation.github.io/autoware-documentation/main/design/autoware-interfaces/ad-api/features/routing/#allow_while_using_route
This is because there was a request to change the route only when it is not in use, so that it does not affect the behavior of the vehicle.
Related links
Parent Issue:

Link

How was this PR tested?

2024/10/30 https://evaluation.tier4.jp/evaluation/reports/98f703d9-3601-5070-8c20-2e91c8ea0c88/?project_id=prd_jt
not tested with this option because converter is not implemented

Notes for reviewers
None.
Interface changes
None.

Effects on system behavior
None.

cc @isamu-takagi
close this PR same to
https://github.com/tier4/tier4_autoware_msgs/pull/150


Add sample Dockerfile for building Mountpoint from source

Sometimes it's useful to be able to build Mountpoint from source to test work-in-progress features. This PR adds a sample Dockerfile to achieve that. One can build the CSI Driver image by compiling Mountpoint from source by:
$ DOCKERFILE="Dockerfile.source" REGISTRY=ACCOUNT_ID.dkr.ecr.eu-north-1.amazonaws.com TAG=latest IMAGE_NAME=mountpoint-csi-driver-testing OUTPUT_TYPE=docker make image

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

This doesn't build MP from source exactly - instead from a published commit. Could we rename this to something else? Say Dockerfile.github?

For me, I'd still consider this as building from source as opposed to using prebuilt artifacts. Mountpoint has also a Dockerfile.source, and it also builds Mountpoint by cloning the repository.

I'm fine approving this, but I'm unsure what we'd call a build from local sources. Perhaps Dockerfile.local

That sounds good to me, changed to Dockerfile.local.


typo: fix missing )

Signed-off-by: Lei Jitang<EMAIL_ADDRESS>

LGTM

@wking I don't think we can get a quick consensus in #466 , and I don't the major fix in #579 is needed, so I'll merge this instead, thanks.
LGTM


Only show sidebar nav bottom gradient on larger screens

Fixes #3830
Ensure the bottom gradient in the nav bar at https://kit.svelte.dev/docs only shows on screens wider than 832px, where the nav is pinned to the left.
Before

After

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[ ] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[ ] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[ ] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

ah whoops, i opened and merged https://github.com/sveltejs/kit/pull/3842 before realising you'd already fixed this. thank you!

ah whoops, i opened and merged #3842 before realising you'd already fixed this. thank you!

No worries - I think https://github.com/sveltejs/kit/pull/3811 can also be closed. We were all at it!


You must set limit: nil to have unlimited retries

Hi! I use Sidekiq version 4.x and if I set:
constant_retry unlimited_retries: true, delay: 10.seconds

in my ActiveJob I get this error You must set `limit: nil` to have unlimited retries! If I set unlimited_retries: true limit should be set to nil automatically in the background.

This is on purpose - unlimited retries is a dangerous option, so it's intentionally hard to switch on

OK, thx.


Fix unchanged rollback stack issue

When a stack update fails & rolls back to an old state, it leaves the
stack in ROLLBACK_COMPLETE.  Unfortunately since this isn't recognized
as a 'COMPLETE' status (it's hard to know if it's complete or not) this
left the entire meta-stack in an un-updateable state.
This handles the case where we 'skip' a stack because nothing has
changed a little bit better, and seems to actually speed things up since
we deal with skipped stacks earlier.

:+1:


Scroll bug

Hello.
Video
It's my fault or theme bug? It appears only on servers with many channels.

https://github.com/Zerthox/ClearVision/issues/4
fix gonna be released with v5

Oh, thanks.


Feat: app layout

Setup initial layout

Hi @christopheralex ,
I realized I'm having the same problem that we had previously where resizing alters the app layout. Do you remember how you fixed it previously? Was it by specifying the plot sizes for each graph?

Hi @christopheralex , I realized I'm having the same problem that we had previously where resizing alters the app layout. Do you remember how you fixed it previously? Was it by specifying the plot sizes for each graph?

Hey Jenn, we might have to manually change the values of my plot sizes. Thats how we solved it last time.

I am not sure if this was for me to do or you just missed it .
Only my plot is missing 😂 .
I had given my Individual assignment here - https://github.com/UBC-MDS/spotify-explorer-R/issues/5#issuecomment-1068600762
https://github.com/christopheralex/dash-r-heroku-demo/blob/main/app.R
Either way its cool if I have to add it .

Thanks Chris, I've made the following edits

Removed dashHtmlComponents, dashBootstrapComponents
Change to read data locally
Rproj file was added

Current issues:
@xiangwxt @christopheralex I'm having some trouble getting your plots to render. Would you be able to double check to see if I've correctly added in your plots? I've temporarily commented them out for now.

You could also create a file called spotify-r-heroku.Rproj to make an R project file which helps in creating a new environment. Below is the code for the file
Version: 1.0

RestoreWorkspace: Default
SaveWorkspace: Default
AlwaysSaveHistory: Default

EnableCodeIndexing: Yes
UseSpacesForTab: Yes
NumSpacesForTab: 4
Encoding: UTF-8

RnwWeave: Sweave
LaTeX: pdfLaTeX

It's a R project now.


Is defined throws type errors on PICK / OMIT making it difficult to work with

Is defined throws type errors on PICK / OMIT making it difficult to work with
Using PICK or OMIT creates objects using a subset of available properties. Any code interacting with that missing prop with throw UNKNOWN PROPERTY errors.
It would be good if the DTO still knew that the key is valid and just returned false on isDefined checks.

Removed in develop. No longer an issue.


Don't feed empty object to Immutable.List() and Immutable.Set()

Now that ss.get() returns {} when key is missing and no other default is provided, we need to provide e.g. null or [] as the default when we do things like:
this.preferredBases = Immutable.List(ss.get("preferredBases"));

Should become:
this.preferredBases = Immutable.List(ss.get("preferredBases", null));

Otherwise the immutables throw.

This is why I used arrays as defaults whenever an Immutable.List was defined though.
this.hiddenAssets = Immutable.List(ss.get("hiddenAssets", []));
this.preferredBases = Immutable.List(ss.get("preferredBases", [CORE_ASSET, "BTC", "USD", "CNY", "OPEN.BTC"]));

Ah sorry! I am actually working with graphene-ui-testnet code and this might have been their change that dropped the default [], I'll look again.


Responsive option not working

Hi, thanks for this module. I am trying to use responsive option as per the document here https://owlcarousel2.github.io/OwlCarousel2/demos/basic.html but it is not working
my current option config
sliderOptions = [{     dots: true,     navigation: false,     autoplay: false,     loop: false,     lazyLoad: true,     nav: true,       responsive:{         0:{             items:1         },         600:{             items:3         },         1000:{             items:5         }     }       }];

same problem still trying to fix it, do you have solution now ?

Hello @attapanbank, here is my code
I have created 'sliderOptions' object in the component
sliderOptions = {     margin: 20,         dots: false,     navigation: true,     nav: true,     navText:['<', '>'],     autoplay: true,     loop: false,     lazyLoad: true,     responsive:{       0:{           items: 1       },       600:{           items: 3       },       1000:{           items: 4       }     }     };
and in html
<owl-carousel
[options]="sliderOptions"
[items]="Items"
[carouselClasses]="[ 'owl-theme', 'sliding', 'custom-class' ]">
Loop Items here

Hi Guys,
Below CSS will help you guys,
`.owl-prev:before, .owl-next:before {
content: "\f053";
font-family: FontAwesome;
position:relative;
left: 0px !important;
z-index: 999999 !important;
width: 50px !important;
height: 50px !important;
right: auto !important;
top:50% !important;
}
.owl-next:before {
content: "\f054";
font-family: FontAwesome;
right: 0px !important;
left: auto !important;
}
.owl-nav.disabled button {
position: relative;
height: 100px;
}`


"Convert selection to geolocation" parses wrong data

I've been using the "Convert Selection to Geolocation" feature quite a lot, but recently it has stopped to work correctly. For example, if I apply it on the following selection:
Halvemaanpassage 1, 3011DJ Rotterdam
The result is:
Halvemaanpassage 1, 3011DJ Rotterdam
As you can see, the address number is used for lat and the zipcode for lon (also confirmed with other addresses). Using the DevTools I do see that the correct latitude and longitude are part of the response, but perhaps the response signature has changed?

Can you elaborate on your configuration? What URL parsing rules do you have under the relevant settings section (a screenshot could be nice)?

It looks like it's the default configuration, here's the config in data.json of the plugin:
"urlParsingRules": [
{
"name": "OpenStreetMap Show Address",
"regExp": "https:\/\/www.openstreetmap.org\Squery=([0-9\.\-]+%2C[0-9\.\-]+)\S",
"preset": true,
"ruleType": "latLng"
},
{
"name": "Generic Lat,Lng",
"regExp": "([0-9\.\-]+), ([0-9\.\-]+)",
"ruleType": "latLng",
"preset": true
}
],
The OpenStreetMap part has been there since the beginning and the second one has been later according to my Git history; both look to be default looking at settings.ts

I think I found (part of) the issue: the "Generic Lat,Lng" parsing rule seems to be used first. If I change the regular expression for that one to something else, the OpenStreetmap lookup works as expected.


chore: update circuits to v2

In the opened issue #3 - updates we need to make were discussed.
This PR is an update to the first version where external_nullifier is a public input (correspondingly computed outside of snark).
The PR aimed to update the circuits for the 2 degree polynomial case.

Was the spec updated? https://rfc.vac.dev/spec/32/ Would be good if we kept these in sync

@oskarth We reverted this merge. I opened it again #6 , we'll merge it after reviews and RFC changes.


Option to get ref that built caches in cache.nixos.org instead of just a head

Because of non caching ref takes too long to build. It's not for my pleasure 🙄.

https://discourse.nixos.org/t/check-if-package-is-available-in-cache/13831
https://docs.cachix.org/faq#why-is-nix-not-picking-up-on-any-of-the-pre-built-artifacts
https://discourse.nixos.org/t/new-tool-for-exploring-nar-contents-online/21840/5
https://github.com/wh0/nix-cache-view
https://discourse.nixos.org/t/what-should-i-expect-to-find-in-cache-nixos-org/7935/5
https://github.com/cachix/install-nix-action/blob/6ed004b9ccb68dbc28e7c85bee15fa93dbd214ac/install-nix.sh#L89-L91

https://nixos.wiki/wiki/Binary_Cache
How to check if content is on a binary cache
We can use curl to check if a binary cache contains a given derivation. curl https://cache/store_hash.narinfo

https://releases.nixos.org/ => https://releases.nixos.org/?prefix=nixpkgs/ => https://releases.nixos.org/nixpkgs/nixpkgs-23.11pre509044.3acb5c4264c4 => https://releases.nixos.org/nixpkgs/nixpkgs-23.11pre509044.3acb5c4264c4/nixexprs.tar.xz is the answer? 👀

https://discourse.nixos.org/t/best-way-to-pin-a-package-to-a-certain-revision-within-nixpkgs-flakes/17928/2 😮
I tried it, get the github commit ref as rev 2 days before...

https://nixos.wiki/wiki/Nix_channels
https://discourse.nixos.org/t/differences-between-nix-channels/13998
nixos-unstable is a bit old, but nixpkgs-unstable looks the one I actually want...
And using them with flake.nix, the revision can be locked and tracked by the flake.lock
😂
https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-flake-update.html


HOCS-2136: Transfer to OGD at MPAM Creation stage

This PR modifies/creates the camunda flows necessary for the transfer case flow.

@abarker66 yes just a conflict fix issue, should be all sorted now.


PromiseKit 4.1.8: Use of undeclared type 'URLDataPromise'.

PromiseKit version: 4.1.8
Xcode version: XCode 8.3.3
CocoaPods version: 4.1.8

I have a framework which uses PromiseKit, for which I set up the following dependency in its specs
s.dependency 'PromiseKit', '~> 4.1.7'

Because of this, version up to (and not including) 4.2 are fetched. However, it was reported to me that PromiseKit 4.1.8 has a compile issue, forcing me to change my dependency to the specific version 4.1.7.

This is an easy "fix" on my end, but I was surprised to find this.
Possibly Related:
#717

Confirmed, please upgrade to 4.4.2.

4.1.8 is now deleted.
However, please upgrade. There is no reason I can see you'd want to stick with 4.1.x.


Cache response inside cloudflare worker

Cache response inside cloudflare worker

@pyropy in the future, please link to the relevant milestone issues in your pull request descriptions, to make it easier for other to navigate.
In this case:

https://github.com/space-meridian/roadmap/issues/206

It would be great to have at least some basic tests to validate this worker works as intended. What are the best practices for writing automated tests for Cloudflare Workers?

I have added unit tests. They do have documentation here on testing but I wonder if we need integration tests?

It would be great to have at least some basic tests to validate this worker works as intended. What are the best practices for writing automated tests for Cloudflare Workers?

Thanks, I'll take a look tomorrow.

The code looks very good now. Besides addressing the existing comments (and a few new ones below), the most important step now is to verify that the proposed architecture (worker - cache - origin integration) works as expected.

So I've re-read the docs again and here's my takeway

Conceptually, there are two ways to interact with Cloudflare’s Cache using a Worker:

Call to [fetch()](https://developers.cloudflare.com/workers/runtime-apis/fetch/) in a Workers script. Requests proxied through Cloudflare are cached even without Workers according to a zone’s default or configured behavior (for example, static assets like files ending in .jpg are cached by default). Workers can further customize this behavior by:
    Setting Cloudflare cache rules (that is, operating on the cf object of a [request](https://developers.cloudflare.com/workers/runtime-apis/request/)).

My understanding of above Given that our resource (app server running on fly.dev) will still be proxied by cloudflare/

Store responses using the Cache API from a Workers script. This allows caching responses that did not come from an origin and also provides finer control by:

    Customizing cache behavior of any asset by setting headers such as Cache-Control on the response passed to cache.put().

    Caching responses generated by the Worker itself through cache.put().

For the above my understanding is that if request is not proxied by cloudflare you have to manually put it to the cache, but the fetch itself will be able to get it from cache if it has been cached previously.


Implement search functionality

I think this one provides a nicer separation of responsibilities, so I would go for that one
it is easier to understands and keeps logic in the logical place
but here is a fun alternative: you can also define your visible contact as a pure derivation from all contact data + the search filter. so you get something like:
@computed get visibleContacts() {
    return !this.searchFilter ? this.allTodos : this.allTodos.filter(yourFilter) }
}

it keeps your real state realy small (just contacts and filter), but you can also still access the unfiltered list from anywhere in your code (by using allContacts instead of visibleContacts)

Thanks for the review @mweststrate
I've updated my PR per your suggestions


[question] NVM size is 0 - How is the size determined?

I wanted to move to a new controller and tried to back up NVM. Unfortunately, it doesn't work:
2022-01-31 21:52:50.646 INFO ZWAVE: Calling api backupNVMRaw with args: [ [length]: 0 ]
2022-01-31 21:52:50.691 INFO ZWAVE: Unknown NVM size - cannot backup! (ZW0207) backupNVMRaw undefined

How is the NVM size determined?
Additional information: My controller is connected over TCP using ser2net. The controller itself is an embedded module in a SERCOMM NA502.

0 is not the NVM size, that's the length of the method argument array.

Unknown NVM size

is because the response by the stick doesn't match any of the defined NVM sizes.
Please make a driver log, loglevel debug or silly, try the backup again and attach the log here as a file.

I redacted the home ID; looks like the manufacturer is reported as 0xff
zwavejs_2022-01-31.log

2022-01-31T20:52:50.678Z DRIVER « [RES] [GetNVMId]
                                    manufacturer: 0xff
                                    memory type:  EEPROM
                                    memory size:  Unknown

That's the intersting bit. Z-Wave JS can't know how large the memory is, so it doesn't know how much it can read.
I'm not sure what the correct behavior in this case is and how the device would react to an out-of-bounds read (return nothing? wrap around?).

Hm...does Z-Wave JS identify the memory size based on the ID returned by the chip? Is the memory external or on the SoC?
The Z-Wave module is a separate PCB, it looks like this: https://www.digikey.be/en/products/detail/silicon-labs/ZM5304AE-CME3R/4135431
I'm not sure what the smaller IC is. The markings are S8U S78 77, I couldn't find any information on that.

does Z-Wave JS identify the memory size based on the ID returned by the chip

No, the size information is part of the response (the third 0xff).
https://github.com/zwave-js/node-zwave-js/blob/3b116f8c95535ef6e561fa862bec9d0ddaf1a3f9/packages/zwave-js/src/lib/serialapi/nvm/GetNVMIdMessages.ts#L23-L37
AFAIK, the get_NVM_id command is the only way to get any information about the (external) NVM on 500 series controllers:

Yeah, looks so.
If I understood the concept correctly, the manufacturer should have programmed this information into the NVR flash page of the Z-Wave chip. I suppose that this information is then returned by the serial API and in my case the manufacturer didn't do that. Since there is then no reliable way of detecting the missing information, I'm screwed.

I just found a tool "TestNVM.py" on github that should be able to dump the NVM. They seem to just dump 2Mbit: https://github.com/drzwave/TestNVM/blob/a57c42406c54b24609b3aa5e74d5ebf494f0506f/TestNVM.py#L411
I'll modify it for TCP and see what happens.


Git Reports Issue

Submitter: John Darrow Echeverria
For cards that are not scripted, we are not able to manually add or remove production for deeds.  Is there a commend for that?

Duplicate of #706


Use of Average and Score on Results page and in dashboard (from the Forum)

As far as I understand it, in the xAPI dashboard view, Score is the average score of ALL content completed by a user in a LO, and Average accounts for the Tracking Weight. Therefore, these numbers can be very different. Users see the Average on the results page.
On the xAPI dashboard, the Score is shown by default, but not the Average. It is possible to see a user's Average by clicking on the row to get the detailed information, but that is not practical to see an overview of the Averages.
In my opinion, this seems the wrong way around - Average seems to be more important than Score, since it is what users see. Would it be possible to show Average instead of (or as well as) Score in the xAPI dashboard? Both would still be available in the detailed per-user view.

I beleive the observation is not completely correct. I think Average is the avergae score so far (taking into consideration the Tracking Weight)
Score is the Average weighted to completion.
So if Average is 100% and completion is 50% than Score will be 50%
It would be good to verify this statement and include tooltips to explain this. If this is the case, I still think that the Score should be shown to the user. We might want to swap Average and Score in the Results page.


feat: add Bitbucket support

Description
Adds Bitbucket support with externalized host url
Which issue(s) does this PR fix

Fixes #177

PR acceptance criteria
Please make sure that the following steps are complete:

GitHub Actions are completed and successful
Unit Tests are updated and passing
E2E Tests are updated and passing
Documentation is updated if necessary
Add a screenshot if the change is UX/UI related

How to test changes / Special notes to the reviewer

Don't forget to rebase @Zaperex

I don't see any changes in the package.json to add the dependency.

Can I ask if the Bitbucket Server Discovery also needs to be included here? If so, I will need to add it since I initially was told I only needed to configure the location.


Helm install failed. Forbidden: User system:serviceaccount:ndn-base:default

Created operator as mentioned in documentation. But i am getting this error while deploying the custom resource.

"release helm-app-operator-ndn.xyz.com failed: namespaces \"ndn-base\" is forbidden: User \"system:serviceaccount:ndn-base:default\" cannot get namespaces in the namespace \"ndn-base\""
time="2018-09-04T10:07:10Z" level=error msg="error syncing key (ndn-base/ndn.xyz.com): release helm-app-operator-ndn.xyz.com failed: namespaces \"ndn-base\" is forbidden: User \"system:serviceaccount:ndn-base:default\" cannot get namespaces in the namespace \"ndn-base\""

And after this error on next event the operator itself exits with following error
time="2018-09-04T10:07:10Z" level=info msg="processing ndn-base/ndn.xyz.com"
time="2018-09-04T10:07:10Z" level=info msg="using values: size: 1\n"
ERROR: logging before flag.Parse: E0904 10:07:10.778333       1 runtime.go:66] Observed a panic: "index out of range" (runtime error: index out of range)
/go/src/github.com/operator-framework/helm-app-operator-kit/helm-app-operator/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:72
/go/src/github.com/operator-framework/helm-app-operator-kit/helm-app-operator/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:65
/go/src/github.com/operator-framework/helm-app-operator-kit/helm-app-operator/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:51
/usr/local/go/src/runtime/asm_amd64.s:573
/usr/local/go/src/runtime/panic.go:502
/usr/local/go/src/runtime/panic.go:28
/go/src/github.com/operator-framework/helm-app-operator-kit/helm-app-operator/vendor/k8s.io/helm/pkg/storage/storage.go:132
/go/src/github.com/operator-framework/helm-app-operator-kit/helm-app-operator/vendor/k8s.io/helm/pkg/tiller/release_update.go:73
/go/src/github.com/operator-framework/helm-app-operator-kit/helm-app-operator/vendor/k8s.io/helm/pkg/tiller/release_update.go:38
/go/src/github.com/operator-framework/helm-app-operator-kit/helm-app-operator/pkg/helm/helm.go:86
/go/src/github.com/operator-framework/helm-app-operator-kit/helm-app-operator/pkg/stub/handler.go:39

Any idea what could be wrong ?

Hey @shettyh, thanks for the issue! Can you provide a link to the Helm Chart you are using? Are you trying to create a Namespace in the Helm Chart? You may need to modify the RBAC permissions for the Operator's Role (which was generated by the operator-sdk).

@alecmerdler Thanks for the reply. Fixed by adding ClusterRole and ClusterRoleBinding in rbac


Update lifx services.yaml

Description:
#27289
No services to document in LIFX platform, they are all documented in the light platform

Superseded by #29136


Parsing arguments fails

I'm trying to use it as per docs, but getting error at the stage of parsing arguments:
> cargo swagg ./AlpacaDeviceAPI_v1.yaml --out-file src/api.rs
error: Found argument './AlpacaDeviceAPI_v1.yaml' which wasn't expected, or isn't valid in this context

USAGE:
    cargo-swagg.exe [OPTIONS] <source>

For more information try --help

Am I missing something?

I get this as well. How is the command supposed to be run?

For reference I get this no matter what I do:
cargo swagg openapi.yaml
error: Found argument 'openapi.yaml' which wasn't expected, or isn't valid in this context

USAGE:
    cargo-swagg [OPTIONS] <source>

For more information try --help

I've run into the same thing (on Windows).
It looks like running as cargo swag ./api.yaml --out-file ./src/api.rs is interpreted as swag being the source path. If I run it as cargo-swag.exe ./api.yaml --out-file ./src/api.rs then the program runs correctly. Hopefully this workaround helps!

@FlipWarthog Ohhh thanks. I've moved on and wrote my own generator for the specific usecase I had, but this would've been helpful before 😅


Cannot configure GLog using pod install under linux

This line fails to complete (cannot configure GLog) under linux when running on CI servers. This may or may not be a bug depending on whether different host OSs are supported for running pod install on react-native applications:
https://github.com/facebook/react-native/blob/2f2c3ea2547c9a76a0452c1a75d7514032ff2dee/scripts/ios-configure-glog.sh#L15

This is related to https://github.com/facebook/react-native/issues/14326 in the sense that it addresses  that issue, but in doing so, it breaks platform independence.


WIP: Fix ODS column widths

@mawi12345 I'll wait till you remove "WIP" before merging, in case you wanted to expand on it. Thanks! 👍

@mawi12345 was there more to do on this one?

Went ahead with the merge after all..


[SPARK-12616] [SQL] Making Logical Operator Union Support Arbitrary Number of Children

The existing Union logical operator only supports two children. Thus, adding a new logical operator Unions which can have arbitrary number of children to replace the existing one.
Union logical plan is a binary node. However, a typical use case for union is to union a very large number of input sources (DataFrames, RDDs, or files). It is not uncommon to union hundreds of thousands of files. In this case, our optimizer can become very slow due to the large number of logical unions. We should change the Union logical plan to support an arbitrary number of children, and add a single rule in the optimizer to collapse all adjacent Unions into a single Unions. Note that this problem doesn't exist in physical plan, because the physical Unions already supports arbitrary number of children.

@rxin Could you check if this implementation is what you expects? Thanks!

Maybe we should just remove the old Union and call the new one Union?

Yeah, it will be better. Will do the change tonight. Thanks!

+1, I'd prefer if there is only one operator that performs unions

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/48685/
Test FAILed.

Merged build finished. Test FAILed.

Todo:

Will add the new Dataframe and Dataset APIs for unionAll, if my understanding is correct.
Will add another rule for pushing Filter and Project through Unions.

Thanks!

Test build #48756 has started for PR 10577 at commit c1f66f7.

Test build #48756 has finished for PR 10577 at commit c1f66f7.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/48756/
Test PASSed.

Will add the new Dataframe and Dataset APIs for unionAll, if my understanding is correct.

You don't need to add any new APIs, just call the optimizer rule directly on any existing API that adds a Union.

Understood it. Thank you! Will not introduce new APIs.

Major changes in this commit:

Combine the Union during the construction (i.e., in the DataFrame and Dataset APIs)
Use tail recursive with extractor object to reimplement the rule CombineUnions
Rename the operator Unions to Union
Fix bugs

Todo:

Change the optimizer rule for pushing Filter and Project through Unions.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/48825/
Test FAILed.

Build finished. Test FAILed.

Test build #48826 has started for PR 10577 at commit 5681ca8.

Test build #48826 has finished for PR 10577 at commit 5681ca8.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class Union(children: Seq[LogicalPlan]) extends LogicalPlan

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/48826/
Test PASSed.

Major changes in the most recent commits:

Combine the Unions during the construction (i.e., in the DataFrame and Dataset APIs)
Use tail recursion with extractor object to reimplement the rule CombineUnions
Rename the operator Unions to Union
Fix a bug in HiveTypeCoercion
Change the optimizer rule for pushing Filter and Project through Unions.

Test build #48838 has started for PR 10577 at commit 7a54c8f.

The other thing you gotta be careful with is the performance of fold/foldRight/foldLeft/tail/head on these collections. Please make sure we are not doing some linear complexity operation in an inner loop and then making everything quadratic.

Thank you for your suggestions! Will pay more attentions on this part.

Test build #48838 has finished for PR 10577 at commit 7a54c8f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/48838/
Test PASSed.

Merged build finished. Test PASSed.

Major changes in this commit:

refactored WidenSetOperationTypes and added and updated test cases
replace List by ArrayBuffer in extract object Unions
minor changes based on the comments.

Test build #48872 has started for PR 10577 at commit b3327b1.

Test build #48872 has finished for PR 10577 at commit b3327b1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/48872/
Test PASSed.

cc @cloud-fan for review on this one too.

Test build #48950 has started for PR 10577 at commit 723c0da.

Test build #48950 has finished for PR 10577 at commit 723c0da.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/48950/
Test PASSed.

Merged build finished. Test PASSed.

Test build #49002 has started for PR 10577 at commit 42b81a8.

Test build #49002 has finished for PR 10577 at commit 42b81a8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49002/
Test PASSed.

Test build #49021 has started for PR 10577 at commit ab732c1.

Test build #49021 has finished for PR 10577 at commit ab732c1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49021/
Test PASSed.

The latest change contains the fix of Union in SQL Generation.

Test build #49045 has started for PR 10577 at commit 031a5d8.

Test build #49045 has finished for PR 10577 at commit 031a5d8.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49045/
Test FAILed.

The latest change contains the fix for multi-child Union ALL in conversion from logical plan to SQL after introducing SQL Generation: https://github.com/apache/spark/pull/10541

Test build #49048 has started for PR 10577 at commit f3d23dc.

Test build #49048 has finished for PR 10577 at commit f3d23dc.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49048/
Test PASSed.

retest this please

Test build #49284 has started for PR 10577 at commit f3d23dc.

Test build #49284 has finished for PR 10577 at commit f3d23dc.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49284/
Test FAILed.

Build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49389/
Test FAILed.

In this update, the major changes include

Added a new analyzer rule EliminateUnions for remove the union with a single child.
Rewrote the function widenOutputTypes. Now, it stops if finding the first column that is not type-coerce-able among children.
Modified the function collectUnionChildren by replacing ArrayBuffer by Stack.
Addressed the other comments and fixed the style issues.

Test build #49391 has started for PR 10577 at commit e8e19a1.

Test build #49391 has finished for PR 10577 at commit e8e19a1.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class Union(children: Seq[LogicalPlan]) extends LogicalPlan

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49391/
Test PASSed.

Merged build finished. Test PASSed.

LGTM except some minor comments, thanks for working on it!

@cloud-fan Really THANK YOU for your review! Will do the changes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49490/
Test FAILed.

Test build #49492 has started for PR 10577 at commit b88bdeb.

a kind of hidden comment: https://github.com/apache/spark/pull/10577/files#r49784836

Test build #49492 has finished for PR 10577 at commit b88bdeb.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49492/
Test PASSed.

Sorry, just replied the kind of hidden comment. See the answer just after the comment. : )
Will first update the codes to address your latest two comments. Thanks!

Test build #49525 has started for PR 10577 at commit 3041864.

Test build #49525 has finished for PR 10577 at commit 3041864.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49525/
Test FAILed.

retest this please.

Test build #49528 has started for PR 10577 at commit 3041864.

Test build #49528 has finished for PR 10577 at commit 3041864.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49528/
Test PASSed.

LGTM

Thank you! @cloud-fan Have a good long weekend!

@rxin @marmbrus Could you check if this fix is OK? Thank you!

@rxin Thank you for your trust! I am not sure if my new changes follow the same way you did. It is a little bit different if we have more than two children. Please let me know if I can simplify it further. Thanks!
@cloud-fan Maybe you need to review it again. Thank you!

Test build #49634 has started for PR 10577 at commit f112026.

Test build #49644 has started for PR 10577 at commit 4f71741.

Test build #49634 has finished for PR 10577 at commit f112026.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class Union(children: Seq[LogicalPlan]) extends LogicalPlan

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49634/
Test PASSed.

Test build #49644 has finished for PR 10577 at commit 4f71741.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49644/
Test PASSed.

Merged build finished. Test PASSed.

LGTM except one minor comment

Test build #49722 has started for PR 10577 at commit c63f237.

Test build #49722 has finished for PR 10577 at commit c63f237.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49722/
Test FAILed.

The test failure was caused by a PR, which has been reverted.
retest this please.

retest this please.

Test build #49760 has started for PR 10577 at commit c63f237.

Test build #49760 has finished for PR 10577 at commit c63f237.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49760/
Test PASSed.

The latest merge is for resolving the conflicts.

Test build #49792 has started for PR 10577 at commit c18381e.

Test build #49792 has finished for PR 10577 at commit c18381e.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
case class Union(children: Seq[LogicalPlan]) extends LogicalPlan

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49792/
Test PASSed.

@rxin @marmbrus , could you please review the latest changes? Thank you!

LGTM

Thanks - I'm going to merge this.

Really appreciate your reviews!!! : )

Hi @gatorsmile could you please kindly explain the comment for union method?
def union(other: Dataset[T]): Dataset[T] = withSetOperator {
// This breaks caching, but it's usually ok because it addresses a very specific use case:
// using union to union many files or partitions.
CombineUnions(Union(logicalPlan, other.logicalPlan)).mapChildren(AnalysisBarrier)
}
What does it mean?

This breaks caching

it would be really helpful to give me an example.
thanks very much in advance.

The cache key is the logical plan. If a is cached, ideally a.union(b) should leverage the cache of a, but we can't as a tradeoff to make the logical plan simple.

@cloud-fan thanks for your quick response. I have a simple test, in which a is cached and b is not and here is the output of explain method:

== Parsed Logical Plan ==
Union
:- AnalysisBarrier
:     +- LogicalRDD [number#2, word#3], false
+- AnalysisBarrier
+- LogicalRDD [number#8, word#9], false

== Analyzed Logical Plan ==
number: int, word: string
Union
:- LogicalRDD [number#2, word#3], false
+- LogicalRDD [number#8, word#9], false
== Optimized Logical Plan ==
Union
:- InMemoryRelation [number#2, word#3], true, 10000, StorageLevel(disk, memory, deserialized, 1 replicas)
:     +- Scan ExistingRDD[number#2,word#3]
+- LogicalRDD [number#8, word#9], false
== Physical Plan ==
Union
:- InMemoryTableScan [number#2, word#3]
:     +- InMemoryRelation [number#2, word#3], true, 10000, StorageLevel(disk, memory, deserialized, 1 replicas)
:           +- Scan ExistingRDD[number#2,word#3]
+- Scan ExistingRDD[number#8,word#9]
It seems the cached a is used. Please bear my ignorance and correct me what's wrong here.
Thanks.

it works because a is not a union so this change is a noop to it. you can cache a.union(b) and then run a.union(b).union(c).

Thanks @cloud-fan !!


Report clusterID again

We haven't been reporting this to mixpanel for quite a while now. Segment sees:
client.Track(&analytics.Track{
  UserId: "f8edc66767a24385834fb48eba62ec08",
  Event: "user.usage",
  Properties: map[string]interface{}{
    "ClusterID": "",
    "VersionFinished": 0.0007354340000000001,
  },
})

Not sure when/why we stopped reporting this, but we should fix it

Hmmm ... another segment data point looks like it reports it ...
client.Track(&analytics.Track{
  UserId: "c4dbbe76fe0844ac8b88c3e1205a9ebb",
  Event: "user.usage",
  Properties: map[string]interface{}{
    "ClusterID": "8cab5ebdc47a402bba58a5b491829c05",
    "ListCommitStarted": 1,
  },
})

but in mixpanel i dont see it ... still investigating

Actually it seems like we are reporting it ... I can generate reports on it. However, many times we are not reporting it. And we can see 90% of the user metrics don't have it set:

And this has been happening for a while ...

So it doesn't correspond directly to the 1.4 release (though testing / usage may account for some of this data)

I think at this point we're consistently reporting cluster IDs, feel free to reopen if that's not the case.


Bring in PromiseKit for composing Async tasks with swift

Ideally we'd like to just bring this in using Cocoapods which we use for our other dependencies, but it doesn't support combining swift with iOS 7. Once we drop iOS 7 support we'll switch the dependency to a pod.

@hanningni please review. This just adds a library so I don't think there's much to look at it.

(Note, this won't pass travis because it uses the latest version of swift. Will add circleci support so we can track that it's working)

:+1:    i need to study swift:)

@hanningni this is the main interesting file https://github.com/mxcl/PromiseKit/blob/master/Swift Sources/Promise.swift

@aleffert  thanks


Trait-based cryptographic routines API to delegate implementation to downstream crates

Description

The goal is to be able to introduce an abstraction that encapsulates a set of everyday cryptographic operations needed
which do not necessarily share the exact underlying implementation details. This is precisely the case when we want to extend the functionality of the Light Client Verifier to support different light clients. Ideally, this could be used within any chain to verify the state of any other chain.
Based on this pr/discussions we've identified a few elements that we want to resolve:

an agreed-upon interface (see below for a proposed one by @tony-iqlusion)
reduce or eliminate the number of dependencies that are introduced
be generic enough on the definition of methods/types so that we're not constraint to a specific implementation (see the discussion about returning a boolean in the signature verification)

Proposed interface;
// https://github.com/informalsystems/tendermint-rs/pull/1138#issuecomment-1161835971

use digest::FixedOutput;
use digest::{consts::U32, Digest};
use tendermint::signature::Signer;
use tendermint::signature::Verifier;

pub trait CryptoProvider {
    type Sha256: Digest + FixedOutput<OutputSize = U32>;

    type EcdsaSecp256k1Signer: Signer<k256::ecdsa::Signature>;
    type EcdsaSecp256k1Verifier: Verifier<k256::ecdsa::Signature>;

    type Ed25519Signer: Signer<ed25519::Signature>;
    type Ed25519Verifier: Verifier<ed25519::Signature>;
}

Definition of "done"

The trait is merged into the main branch, all tests are passed, and there is an external implementation of the trait
for another light client that is successfully implemented using this interface.

Copying @thanethomson and @mzabaluev as potentially having feedback on this API. Thanks Blas for shepherding this!

I drafted an implementation of the trait for something similar to what Seun initially proposed. At least this proves that the design of the CryptoProvider is generic enough for us.

The design looks good to me. It enshrines digest (rust-crypto) as the framework that the host must implement the crypto routines through, but tendermint already depends on signature and most implementations in practice are from rust-crypto as well.

An update: I have discarded the CryptoProvider super-trait in #1238.
All crypto functions are available for an alternative implementation in terms of digest and signature traits. We only provide some type aliases and utility traits where the rust-crypto API is being more difficult to use than it should be.

🎊🎊❤


[1626] accomodate empty attributes when updating from jsonapi

Context
JSONAPI requests can come in with an empty set of attributes, if there are no attributes to update. When this happens, the deserializer doesn't even bother to create the root parameter (e.g. course in this case).
Changes proposed in this pull request
Default the course update attributes to an empty hash instead of requiring it to be present. i.e. we usually expect the params to come in as:
{
  course: {
    about_course: "This is a great course.",
    ...
  }
}

so we can do params.require(:course). But now, when course: isn't present, we default it to {}.
Checklist

[ ] Make sure all information from the Trello card is in here
[ ] Attach to Trello card
[ ] Rebased master
[ ] Cleaned commit history
[ ] Tested by running locally

 Cannot update a course enrichment is nothing changes

Why hacky? It's not what we're used to with HTML forms that submit the entire thing on POST/PUT, but this is an API so that's not a surprise. fetch serves this purpose perfectly by converting the {} into an ActionController::Parameters object for us.