Removing unused or outdated pages

I'd like to propose removing the following sections, which don't appear to be needed for the 2022 event:

venue.html
accommodation.html
programme.html

The first two don't seem to be needed for an in-person event (and they also have incorrect information about the 2020 event). The third appears to be an unused page for the program, but we are using schedule.html for this, as far as I can tell.
I can submit a PR for these, but want to check first - is there any reason for keeping these pages?

venue - agree this can be removed (this is where it currently goes
accommodation - agree this can be removed (this is where it currently goes
programme - I'm interested to see what others think. (this is how it was used for 2020; seems like it still referred to an in-person event)

Thanks @maneesha and @morskyjezek. It does seem that the programme was meant for the event when it was planned for in-person in Madison. I'm fine to remove it as well as long as we have the schedule somewhere else. There might be a need for a detailed schedule and a high-level program overview but not sure they need to be on separate pages?


Added container class and aligned it to center

It should have bean like this from the start! Thanks 😃

It should have bean like this from the start! Thanks

The social links are not visible after this merge.

@pvn6396 Oops i must have missed that in my review 😢 Would you mind creating an issue about this?

Oops!!! that is a toggle social link button.

Haha, maybe we should make it clearer?  cursor: pointer; maybe?


Update Slack.jl repo URL

since it was moved to a different GitHub organization. This way we don't need to rely on GitHub redirects. cc @logankilpatrick
ref https://github.com/JuliaRegistries/General/pull/40171#issuecomment-873480346

I'm loving all of this clean-up!

Thanks for this!


Fallback for calc()

Hi,
I'm using s-grid and it is very handy to set-up flexbox grid. It works greats for the most. However it does seems to fail for IE10 and Safari on ios8.
I can't check why on ios8 but on IE10, none of the attributes using calc() are used (they are greyed out), for example:

Will it be possible to add a fallback for calc() for browser that does not handle well it?
Please let me know if you need more input from me.
Thanks.

Hi,
Yes I'm using autoprefixer.
That's true that I'm using vh units.
I'm trying to understand why it does work and the only real thing I can see is that IE 10 crossed out all the lines where calc() is used.

Hard to tell :/ It probably needs some more investigation. Do you have this website online?

the website is not finished and need some clean-up, but you can find a temporary version here:
julienhericher.com

Hi, sorry for the delay. I think that IE11 and Edge could have some problems with flexbox. It is described here: https://github.com/philipwalton/flexbugs it could be related with this bug: https://github.com/philipwalton/flexbugs#7-flex-basis-doesnt-account-for-box-sizingborder-box

I'll try to provide a fix for this, because teoretically it could be done and I think I've fixed it on the stylusgrid.com website, but I am not sure if I'll be able to provide universal solution in the sGrid. I'll keep you posted.

Ok, so I can't provide universal solution in sGrid because this depends on your custom styling. You can provide another wrapper which will have all your paddings and borders etc. Take a look at: https://github.com/philipwalton/flexbugs#workaround-6 point 2.

Hi,
Thanks a lot for your support and very sorry for this more-than-late reply, I had to be away from my pc for other reason... I move a pure css flex box implementation to cope with IE10.
Thanks again.


Error building NodeJS wrapper on macOS : no such file or directory: librealsense2.dylib

Required Info

Operating System & Version
MacOS Catalina 10.15.4

SDK Version
GitHub

Issue Description
Hi!
I am new to realsense and was trying to build the realsense library from sourse following the installation guidelines here.
I succeeded the first time when I did exactly what installation_osx.md said, ( just wanted to have the examples in librealsense/examples working (such as pointcloud)), but failed later when I tried to build along with the nodejs wrapper.
When I did:
cd wrappers/nodejs
npm install

or:
cmake -DBUILD_NODEJS_BINDINGS=1 -DBUILD_EXAMPLES=true -DBUILD_WITH_OPENMP=false -DHWM_OVER_XU=false
make -j2

the following message comes up:

Linking CXX executable rs-capture
clang: error: no such file or directory: '/Users/user/Documents/librealsense/wrappers/nodejs/../../build/Release/librealsense2.dylib'
make[3]: *** [Release/node_librealsense.node] Error 1
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:198:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)
gyp ERR! System Darwin 19.4.0
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/user/Documents/librealsense/wrappers/nodejs
gyp ERR! node -v v10.16.3
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>install: node-gyp rebuild
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR!      /Users/user/.npm/_logs/2020-04-19T18_57_35_423Z-debug.log
make[2]: *** [../wrappers/nodejs/build/Release/node_librealsense.node] Error 1
make[1]: *** [wrappers/nodejs/CMakeFiles/BUILD_NODE_ADDON.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

I also tried installing the node-librealsense module directly from a nodejs project following its instructions, but also failed:

.
.
.
 System Darwin 19.4.0
gyp ERR! command "/Users/user/.nvm/versions/node/v12.16.1/bin/node" "/Users/user/.nvm/versions/node/v12.16.1/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/user/Desktop/...path-to-my-project..._/webrtc-work/node_modules/node-librealsense
gyp ERR! node -v v12.16.1
gyp ERR! node-gyp -v v5.0.5
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>install: node-gyp rebuild
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR!      /Users/user/.npm/_logs/2020-04-19T19_21_36_877Z-debug.log

Sorry if there's anything very obvious that I'm doing wrong here, still teaching myself :) Please let me know if there's any other info I need to look at / provide.
I appreciate it greatly if someone could point me to the right direction!

 -DBUILD_NODEJS_BINDINGS=1 -DBUILD_EXAMPLES=true -DBUILD_WITH_OPENMP=false -DHWM_OVER_XU=false
make -j2
Also, the CMake instruction is usually run after changing to the build folder of Librealsense after making that folder.  To quote point 4 of the MacOS installation instructions:
mkdir build && cd build
sudo xcode-select --reset

Usually, a CMake build instruction has two full-stops in front of it, like this:
cmake .. -DBUILD_NODEJS_BINDINGS=1 -DBUILD_EXAMPLES=true -DBUILD_WITH_OPENMP=false -DHWM_OVER_XU=false
make -j2
Also, the CMake instruction is usually run after changing to the build folder of Librealsense after making that folder. To quote point 4 of the MacOS installation instructions:
mkdir build && cd build
sudo xcode-select --reset

Thanks for the reply!
I did:
mkdir build && cd build
sudo xcode-select --reset

in my previous attempts.
I tried (in the build directory):
cmake .. -DBUILD_NODEJS_BINDINGS=1 -DBUILD_EXAMPLES=true -DBUILD_WITH_OPENMP=false -DHWM_OVER_XU=false
make -j2

And the same error came up:

clang: error: no such file or directory: '/Users/user/Documents/librealsense/wrappers/nodejs/../../build/Release/librealsense2.dylib'
make[3]: *** [Release/node_librealsense.node] Error 1

Then I looked again in the directorys and realized the library "librealsense2.dylib" is located in librealsense/build/ and there was no "Release" directory
My file structure looked like this:

Usually, a CMake build instruction has two full-stops in front of it, like this:
cmake .. -DBUILD_NODEJS_BINDINGS=1 -DBUILD_EXAMPLES=true -DBUILD_WITH_OPENMP=false -DHWM_OVER_XU=false
make -j2
Also, the CMake instruction is usually run after changing to the build folder of Librealsense after making that folder. To quote point 4 of the MacOS installation instructions:
mkdir build && cd build
sudo xcode-select --reset

Thanks for the reply!
I did:
mkdir build && cd build
sudo xcode-select --reset
in my previous attempts.
I tried (in the build directory):
cmake .. -DBUILD_NODEJS_BINDINGS=1 -DBUILD_EXAMPLES=true -DBUILD_WITH_OPENMP=false -DHWM_OVER_XU=false
make -j2
And the same error came up:
clang: error: no such file or directory: '/Users/user/Documents/librealsense/wrappers/nodejs/../../build/Release/librealsense2.dylib'
make[3]: *** [Release/node_librealsense.node] Error 1
Then I looked again in the directorys and realized the library "librealsense2.dylib" is located in librealsense/build/ and there was no "Release" directory
My file structure looked like this:

Usually, a CMake build instruction has two full-stops in front of it, like this:
cmake .. -DBUILD_NODEJS_BINDINGS=1 -DBUILD_EXAMPLES=true -DBUILD_WITH_OPENMP=false -DHWM_OVER_XU=false
make -j2
Also, the CMake instruction is usually run after changing to the build folder of Librealsense after making that folder. To quote point 4 of the MacOS installation instructions:
mkdir build && cd build
sudo xcode-select --reset

Thanks for the reply!
I did:
mkdir build && cd build
sudo xcode-select --reset
in my previous attempts.
I tried (in the build directory):
cmake .. -DBUILD_NODEJS_BINDINGS=1 -DBUILD_EXAMPLES=true -DBUILD_WITH_OPENMP=false -DHWM_OVER_XU=false
make -j2
And the same error came up:
clang: error: no such file or directory: '/Users/user/Documents/librealsense/wrappers/nodejs/../../build/Release/librealsense2.dylib'
make[3]: *** [Release/node_librealsense.node] Error 1
Then I looked again in the directorys and realized the library "librealsense2.dylib" is located in librealsense/build/ and there was no "Release" directory
My file structure looked like this:
https://drive.google.com/file/d/1dr-Ztwpd_jd6O9DbZ0c1S4FWIjfn28jp/view?usp=sharing

Usually, a CMake build instruction has two full-stops in front of it, like this:
cmake .. -DBUILD_NODEJS_BINDINGS=1 -DBUILD_EXAMPLES=true -DBUILD_WITH_OPENMP=false -DHWM_OVER_XU=false
make -j2
Also, the CMake instruction is usually run after changing to the build folder of Librealsense after making that folder. To quote point 4 of the MacOS installation instructions:
mkdir build && cd build
sudo xcode-select --reset

I'm wondering why that would happen (what I did wrong)?
Just out of curiosity I created a Release directory & copied a librealsense2.dylib into it, then did:
cmake .. -DBUILD_NODEJS_BINDINGS=1 -DBUILD_EXAMPLES=true -DBUILD_WITH_OPENMP=false -DHWM_OVER_XU=false
make -j2

as you suggested. The build finished without errors showing.
However when I tried to run the wrappers/nodejs/examples, this error showed up:

/Users/user/Documents/librealsense/wrappers/nodejs/node_modules/bindings/bindings.js:83
throw e
^
Error: dlopen(/Users/user/Documents/librealsense/wrappers/nodejs/build/Release/node_librealsense.node, 1): Library not loaded: @rpath/librealsense2.2.34.dylib
Referenced from: /Users/user/Documents/librealsense/wrappers/nodejs/build/Release/node_librealsense.node
Reason: image not found
at Object.Module._extensions..node (internal/modules/cjs/loader.js:807:18)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at bindings (/Users/user/Documents/librealsense/wrappers/nodejs/node_modules/bindings/bindings.js:76:44)
at Object. (/Users/user/Documents/librealsense/wrappers/nodejs/index.js:7:32)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)

Out of curiosity (never tried to compile the node bindings): But did you make sudo make install finally?

@CaseyPYZ  when you say that you "tried to run the wrappers/nodejs/examples", do you mean that you followed the instructions for running the NodeJS examples by:

Changing directory to the 'wrappers/nodejs/examples' directory with this instruction:

cd wrappers/nodejs/examples

And then used the installation commands below:

npm install
node nodejs-capture.js
https://github.com/IntelRealSense/librealsense/tree/master/wrappers/nodejs#2-run-examples

@MartyG-RealSense Yes.

Somebody else experienced this "Library not loaded: @rpath" error on MacOS in Ocrtober 2018.
https://github.com/IntelRealSense/librealsense/issues/2471#issuecomment-426637368
Within the same discussion, a member of the RealSense GitHub team called @RealSense-Customer-Engineering  offered some advice on linking.
https://github.com/IntelRealSense/librealsense/issues/2471#issuecomment-432160378

@neilyoung
No, where would this step fit into?
What I did was:
mkdir build && cd build
sudo xcode-select --reset
cmake .. -DBUILD_NODEJS_BINDINGS=1 -DBUILD_EXAMPLES=true -DBUILD_WITH_OPENMP=false -DHWM_OVER_XU=false
make -j2

I'm having the same issue, has it been resolved?

@Alex-OPTIM   I did find another previous case of NodeJS having problems on MacOS in the past.  It is not exactly the same problem, but I will provide the link below in case it gives you some ideas.
https://github.com/IntelRealSense/librealsense/issues/1592
In that particular case, the RealSense user eventually found that upgrading their camera firmware made the problem disappear.

Thanks for directions @MartyG-RealSense but it didn't help.
Basically, from npm i node-librealsense  I have Unrecoverable! error native function rs2_pipeline_start: No device connected. And when I build it from source it fails on librealsense2.dylib not found. I fix it by creating a Release  folder in ../build and copy the file there. Now it builds as per Build with Cmake but when I run
cd wrappers/nodejs/examples
npm install
node nodejs-capture.js

I get segmentation fault  node nodejs-capture.js.
No luck at all.
PS. I downgraded node to v8 and I'm strictly following macOS Installation instruction.

@Alex-OPTIM  Apologies for the delay in responding further.
When carefully researching your case further, I found another NodeJS case from February 2020 where that NodeJS user also experienced the  "Unrecoverable!  error native function rs2_pipeline_start: No device connected" error.
https://github.com/IntelRealSense/librealsense/issues/5856
Which RealSense camera model are you using please?  If it is the D435i, it does not yet have support for MacOS.  This is taken from the version details for the currently most recent SDK version (2.34.0) on the SDK 'Releases' page

It's ok @MartyG-RealSense, thanks for your help. Yes, it is D435i and I feel so dumb, how did I miss it?
Just tried to build from source on my Windows machine and it works!
However npm package isn't working and fails with "Unrecoverable! error native function rs2_pipeline_start: No device connected". So I had to copy and replace nodejs\build\Release folder from the build to the npm package node-librealseanse\build\Release. Now I can use it in my code. Yay! :) [but another challenge is awaiting to create typings.d.ts]
If anyone interested I'm on Windows 10 (v1903), NodeJS v10.20.1, npm i -g windows-build-tools, Visual Studio Community 2019, Python v2.7.15 and CMake v3.16.0.
And my steps in Command Prompt below:

git clone https://github.com/IntelRealSense/librealsense.git
cd librealsense && mkdir build && cd build
cmake .. -DBUILD_SHARED_LIBS=ON
msbuild librealsense2.sln
cd ../wrappers/nodejs
npm install
cd examples
npm install
node nodejs-capture.js

Thanks RealSense team for your help.

@Alex-OPTIM   Don't worry about missing the information about D435i.  An old saying goes "Pobody's nerfect".   :)
Great to hear that you had success with the build process on Windows.  Thanks so much for posting your procedure so that others can benefit from the knowledge.  Good luck!

Hi @Alex-OPTIM    Do you require further assistance on this case, or can it be closed?   Thanks!

Hi @MartyG-RealSense, it's all good for me, you were a great help.
Also I didn't open the issue, @CaseyPYZ are ok to close it?

@Alex-OPTIM    Thanks very much!
@CaseyPYZ  Do you require further assistance on this case, or can it be closed? Thanks!

Case closed due to no further comments received.


Compiler error with generic impls and traits

Aim
This is a minimal reproduction of an issue I encountered while trying to write tests for aztec-nr libraries. The libraries have generic types, and in my tests I needed to use concrete types with them. This broke the build as unrelated callsites started complaining about mismatching types. Not being an expert in the language, this seems like a bug.
Expected Behavior
I expected to be able to have generic functions and to be able to call them using concrete types.
Bug
The following does not compile:
// This is some trait
trait Trait {
    fn new() -> Self;
}

// This is a library function over a type that impls the trait
pub fn library_fn<TypeThatImpls>() -> TypeThatImpls where TypeThatImpls: Trait {
    TypeThatImpls::new()
}

// This is a concrete struct
struct ConcreteTraitImpl;

// That impls the trait expected by library_fn
impl Trait for ConcreteTraitImpl {
    fn new() -> Self {
        ConcreteTraitImpl {}
    }
}

// This is a generic struct
struct LibraryUser<SomeType>;

// This is a generic impl for the generic struct
impl<SomeType> LibraryUser<SomeType> {

    // The following function causes a compiler error. Comment it out to compile.
   // This calls the original library function with a generic type. I imagine library_fn's generic
   // type TypeThatImpls is made the same as SomeType because of the return type.
    fn call_library_fn() -> SomeType {
        library_fn()
    }
}

fn main() { }

The error is the following:
25 │     fn call_library_fn() -> SomeType {
   │                             -------- expected SomeType because of return type
26 │         library_fn()
   │         ------------ ConcreteTraitImpl returned here

I'm confused as to why ConcreteTraitImpl suddenly shows up as the return type. Maybe because it is the only type that impls the trait? Even then this seems very odd to me (though again, far from  an expert).
I expected the error to go away if I deleted ConcreteTraitImpl, but get a different one instead:
17 │         library_fn()
   │         ---------- No impl for `SomeType: Trait`

This seems to hint at me missing something, though I don't really know how to interpret this. Sure, there's no impl for that trait, but I'm not trying to instantiate the struct, call the function, etc., so why does this matter at this stage?
Project Impact
Blocker
Installation Method
Compiled from source
Nargo Version
nargo version = 0.24.0 noirc version = 0.24.0+6522738a781fcff2353d1edca4402c0978a62653 (git version hash: 6522738a781fcff2353d1edca4402c0978a62653, is dirty: false)

For what it's worth, the above code compiles in Rust (with minor modifications: Rust requires that we use the type parameter somewhere for SomeType, and also that we further constrain SomeType to implement Trait, as expected).

Ive noticed that you don't have a trait bound on the impl of Library user. library_fn can't know that SomeType will satisfy the bound on its return type

Something worth mentioning is that in the original aztec-nr scenario, this was triggered when I added a concrete implementation (in the same crate). I am not sure why this example does not work even when there is no concrete implementation - perhaps there's some other detail missing.

25 │     fn call_library_fn() -> SomeType {
   │                             -------- expected SomeType because of return type
26 │         library_fn()
   │         ------------ ConcreteTraitImpl returned here

This is odd, I wonder if this is related to https://github.com/noir-lang/noir/pull/4450.
17 │         library_fn()
   │         ---------- No impl for `SomeType: Trait`

This is the expected error, your call_library_fn is generic over any type SomeType, so we don't know if this type implements Trait or not. You need to restrict this method to be generic over not all types, but only types that implement Trait:
impl<SomeType> LibraryUser<SomeType> {
    // The following function causes a compiler error. Comment it out to compile.
   // This calls the original library function with a generic type. I imagine library_fn's generic
   // type TypeThatImpls is made the same as SomeType because of the return type.
    fn call_library_fn() -> SomeType where SomeType: Trait {
        library_fn()
    }
}

@nventuro do you mind creating an issue for the where clause on an impl? It is mentioned in the Epic: https://github.com/noir-lang/noir/issues/2568 under "Implement trait constraints" .. "free impl blocks" but we don't have an issue yet for it. Since it is just syntactic sugar it's helpful to know how much it is wanted.
An issue for an error message that can be improved would be helpful as well.

Sure, created #4508 and #4509. I didn't want to spam you with random requests, but I'm happy to do things that way in the future!


TypeError when trying to download pdf using the npx app

exact same error for me, different score, only happens when selecting PDF

Duplicate of #10


Neptune logger with a validation epoch end conflict due to the 'epoch' key added on the fly.

Hi everybody! First thanks for this lib, it is very handy!
🐛 Bug
When using pytorch lightning in conjunction with the neptune logger, one can see this kind of error popping every time an epoch ends:
neptune.api_exceptions.ChannelsValuesSendBatchError: Received batch errors sending channels' values to experiment SOC-114. Cause: Error(code=400, message='X-coordinates must be strictly increasing for channel: e4e2635d-b707-46fa-9a1b-996dd009790f. Invalid point: InputChannelValue(timestamp=2020-08-13T11:55:38.422Z, x=5.0, numericValue=2.0, textValue=null, image', type=None) (metricId: 'e4e2635d-b707-46fa-9a1b-996dd009790f', x: 5.0) Skipping 1 values.
the import part in this error is the following line: X-coordinates must be strictly increasing
This is because, in trainer/logging.py, the epoch key is added on the fly on line 69:
scalar_metrics['epoch'] = self.current_epoch

But why does Neptune complains?
If you log all the timesteps (using row_log_interval = 1), at the end of an epoch, 2 calls are emitted to the logger: One to log the training logs and one for the validation logs.
Both of those have the same step value which is the current training step value. Since the key epoch is duplicated in both those calls, Neptune receives the key epoch twice with the same step value leading to the exception.
To Reproduce
launch training with:

Neptune logger
training logs
validation logs
row_log_interval=1

Expected behaviour
Don't add the epoch key on the fly which force the logger to log it.

thanks!
yeah, unfortunately, this might be a problem on their end since we have to track the epoch.
In the meantime, can you post a colab that replicates this issue?
thanks!

Hi,
Thanks for answering.
I've been looking at the code and I'm not sure why you need that epoch at that moment.
When I look at the following code, I see that the epoch key is not always added so the following can't rely on it, no?
if "step" in scalar_metrics and step is None:
    step = scalar_metrics.pop("step")
else:
    breakpoint()
    # added metrics by Lightning for convenience
    scalar_metrics['epoch'] = self.current_epoch
    step = step if step is not None else self.global_step

Thanks for the quick fix 👍


Auto merge backports

Mergify automation

Create a v1.5 backport PR if there is a backport-to/v1.5 label.
Remove v1.2 backport automation.
Approve a backport PR if CI passes.
Merge a backport PR if approvals meet the repo's configuration.

This doesn't work well because Mergify can't approve its own PR.
For example: https://github.com/harvester/harvester/pull/7276
-> Rule: Automatically approve Renovate/Backport PRs (review) — Review failed


Edge is Dead, Long Live Edge

The obit for Edge (EdgeHTML) should mention that it's a different product from Edge (Chromium).

Yes it was incorrect! I replaced Edge (since edge is actually alive) with EdgeHTML https://github.com/fabianoriccardi/killed-by-microsoft/commit/c7921c18b12058283a6fd2bb6f3ae824a7bffb1d
Thanks for the hint!


Toolbar Icon in Firefox

From @Rhei: http://forum.youneedabudget.com/discussion/50229/icon-on-toolbar-firefox
"I've been customizing my toolbar on Firefox, and because I didn't really need the Toolkit icon there all of the time I decided to put it away in the menu.  However, it looks like it comes back everytime I open my laptop back up.  Using a Macbook Pro with OSX 10.11.4 and Firefox 45.0.1.  I haven't noticed this on my desktop, but I also don't put it to sleep regularly."

So I attempted a few different scenarios  Each was done with the Toolkit and another extension icon placed in the menu of Firefox:

The problem is not recreated when I close and re-open Firefox, nor when I manually put the laptop in sleep mode (Apple -> Sleep).

Close the lid (which I assumed was sleep mode as well) and I watched as the Toolkit forced its way back onto my toolbar from the options menu.

Fully shutdown the laptop.  Power back on.  Same result as #2.  The other extension I have is not affected in any case.

Thanks for the response. This is somewhat of a weird issue, and maybe a side effect of the specific code we're using to generate an extension that can export to Firefox, Chrome and Safari from the same code base. Maybe there's some specific Firefox setting that we don't know about, or it's a known issue that we have no control over.
One way or another, we'll try to look into it.

Sure thing.  Sorry my first post wasn't all that clear.  I was very tired, and more than a little drunk.

I also have this problem: On Linux and Windows. Removing the icon, or customizing it out of the toolbar, then closing Firefox and starting again causes it to appear in the toolbar again. It seems to me that the extension is not causing any entry to be put into about:config//browser.uiCustomization.state variable. Perhaps that has something to do with it?
Based on my small amount of looking, it at least doesn't appear to be a common problem firefox users have (ie. I didn't find very much). My Firefox version is  45.0.2.

I'm pretty sure this is related to Kango, which is the framework we use to build our extension. Next step to debug would be to generate a blank Kango extension and see if it exhibits the same behaviour. If so, we'll file a bug over there.


Make PCovR P matrices depend on Y instead of Yhat

The self.pty_ matrices should depend on Y instead of Yhat. While in theory these should be similar, we currently give the user the ability to provide their own regression results -- if the user passes results from a poor regression, Y and Yhat could be rather different and thus give a "wrong" PCovR projection.
To be merged after #69

A few comments:
* all changes pertaining to #69 should be taken out of this PR

* I see an uncaught error of mine: to be consistent we should have `W @ Yhat.T` instead of using `np.dot` in line 410

* I think we discussed passing a fitted estimator to the PCovR, and this would be remedied in lines 250 - 255 by saying:

if W is None or Yhat is None:

    if not hasattr(self.estimator, "coef_"): # I like this better than check_is_fitted so we don't have to catch an error
        self.estimator.fit(X, Y)

    # checks that the estimator corresponds to the feature space of X
    if self.estimator.coef_.shape[1] != X.shape[1]:
        raise ValueError("The target estimator is not consistent with the supplied feature space.")

    if Yhat is None:
        Yhat = self.estimator.predict(X).reshape(X.shape[0], -1)

    if W is None:
        W = self.estimator.coef_.T.reshape(X.shape[1], -1)

I was under the impression that after #69 is merged, this PR would get a rebase, removing the overlapping commits. Am I mistaken about how these "stacked" PRs generally work?
I changed the np.dot to @ on line 410.
You're thinking ahead =) . I currently have another PR in the works that removes the Yhat and W from the fit call. Instead the idea would be to pass a fitted estimator to the __init__, and fit would check whether the estimator is fitted or not, just like you have here. The estimator is also checked to ensure that is is an instance of both LinearModel and RegressorMixin. PR to come shortly.

I've converted this to a draft, because it's contingent upon the merging of #69, so that no one mistakes this PR as ready to fully review. Cool?

Rebased after the merge of #69, ready for review


blockmotd: Allow overriding via command

Fixes #783

@Mikaela: Can you verify if this patch is to your satisfaction?

Based on what you said at IRC (just outputs motd in server buffer) I think it sounds like what I wanted.

@darthgandalf: Sorry, I missed your initial comment about renaming the variable, is this better?


Simplify MiqExpression.operands2rubyvalue a bit

Purpose or Intent

Replaces ret = []; ret.push(stuff); ret with array literals
Removes some assigned but unused temps
Refactors around the regkey case where ret was assigned and then conditionally reassigned

@miq-bot add-label core, refactoring
@miq-bot assign @gtanzillo

👍 LGTM


[chip,aes_idle] Fix comments in aes_idle test

Signed-off-by: Guillermo Maturana<EMAIL_ADDRESS>

LGTM, these comments where copied from the testplan, could you also edit it?
https://github.com/lowRISC/opentitan/blob/0124ced9192e6aa2e7f5049164626fb56555ad18/hw/top_earlgrey/data/chip_testplan.hjson#L1642

@engdoreis I updated the test plan. Thanks.


HTML entities are not being decoded when editing attribute options

Bug report
Issue Description
When saving some text with an HTML entity (for example double quotes) in the admin forms (for example an attribute value), the values get saved to the database as an HTML entity. However, when loading that same value to edit, it does not get properly decoded back to its original character, instead it will load "10"" in the text field. And if I save that value again without correcting, it will get encoded again in the database as "10""
Preconditions
1. framework Version 1.1.2

Steps to reproduce
It is important to provide a set of clear steps to reproduce this bug.If relevant please include code samples.

Log in as admin
Edit an attribute
Go to "Options" section
save one of the name fields with a character that gets converted to an HTML entity (&, ", >, etc)
save the attribute
edit the attribute again

Expected result
The HTML entity character should be loaded in its decoded form.
Actual result
The character gets loaded into the form an as HTML entity, which causes it to get saved incorrectly.

@MattApril
The issue is resolved now https://prnt.sc/sk8bhs.
Feel free to reopen the issue if it still exists.

Thank you


Example of more user-friendly error handling

Short Description and Why It's Useful
When details from Vuex can't be properly loaded (for other reasons beyond the scope of this PR), the errors that you receive are often not user-friendly. A simple PR like the following would improve things. What do you guys think of improving the Dev Experience this way?

@lukeromanowicz Thanks. But before moving ahead, let's have a chat on this first. Doesn't this have an impact on the bundle size, with an eye on tree shaking? I'm no tree shaking expert, but it might be an issue. What do you think?

@jissereitsma Hey :) Probably there a lot of places where we need more logging, but I'm not sure if this is a good example. Right now here we throw error https://github.com/DivanteLtd/vue-storefront/blob/master/core/modules/cms/store/page/actions.ts#L35 if cms page doesn't exist. And we catch it here https://github.com/DivanteLtd/vue-storefront/blob/master/core/pages/CmsPage.js#L25 . So I think that flow is ok.
Cms page doesn't exist => we catch it in asyncData - which is called before component is resolved so getter will not crash => we get redirection to page not found
So we get info for dev in console, for example:
CMS query returned empty result null
Redirect for resource not found : /i/customer-service

and user gets info that this page doesn't exist.
In other hand if we will keep user on that page with cmsPageContent as {} then he will see empty page with no information.
Also getter is not the best place to log info :thinking: It should be dumb. get data => transform it => return data
IMO best place to log info is where we get it. Catch error there and return falsy data or throw error to handle it in higher order function.


ImageUploadField validation does not allow leaving the file as is

I have a form where one of the fields is an ImageUploadField. If I edit an SQLA model using it, but leave the file alone (I'm editing other data), then the form and/or model doesn't validate because I haven't specified a new file.  I would like to just keep the file name the same as before.
This very well could be using ImageUploadField improperly, but after chasing my tail for a few hours, I figured I'd just ask.
If you give me a pointer on where this validation might be failing, I'll fix the issue in a pull request.

Here is a simplified version of what I'm doing.
class Parent(BaseModel):
    __tablename__='parent'
    id=Column(Integer(), primary_key=True, nullable=False, autoincrement=True)
    readable_name=Column(String(64), nullable=False, server_default='---')
    type=Column(String(32))

    __mapper_args__ = {
        'polymorphic_identity':'parent',
        'polymorphic_on':type
    }

class Child(Parent):
    __tablename__='child'
    id=Column(Integer(), ForeignKey('parent.id'), primary_key=True)
    image_url=Column(String(255), nullable=False)

    __mapper_args__ = {
        'polymorphic_identity':'child',
    }

and the view:
class ChildView(flask.ext.admin.contrib.sqla.ModelView):
    form_excluded_columns = ('type',)
    form_overrides = dict(image_url=ImageUploadField)
    form_args = dict(
        image_url=dict(label='Image:', base_path='/tmp/mydir', allowed_extensions = ('jpg', 'jpeg', 'png'))
    )

What's your Flask-Admin version? This one was fixed some time ago.

Flask-Admin==1.2.0

I just realized that in the example app running at http://examples.flask-admin.org/forms/admin/, the path in:
class Image(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.Unicode(64))
    path = db.Column(db.Unicode(128))

    def __unicode__(self):
        return self.name

is nullable, where in my case, image_url is not:
class Child(Parent):
    __tablename__='child'
    id=Column(Integer(), ForeignKey('parent.id'), primary_key=True)
    image_url=Column(String(255), nullable=False)

    __mapper_args__ = {
        'polymorphic_identity':'child',
    }

Getting rid ot the nullable=False allowed this to work as expected.


[DOCS] Add contribution guidelines

Description
I can work on this if required.
Screenshots
No response

I would love to work on this.

I would love to work on this.

Yes, go ahead. This should be the pattern and content. Change the link and tech accordingly.
https://github.com/Pradumnasaraf/Post-My-Message/blob/main/CONTRIBUTING.md


Improvements to handling OpenShift Ingress

Functionality was added to enable the configuration of Ingress resources to support OpenShift to enable a streamlined way of integrating these charts to support their ecosystem.
These opinionated configurations work great for the simple use case. However, challenges have been experienced when customizing for more complex configurations and improvements can be made to support additional integrations.
Challenges

Annotations overwritten

Annotations that are set on Ingress resources are overwritten by opinionated configurations

Inability to fully define certain properties

Certain properties, such as path and pathPrefix cannot be defined

Opinionated TLS

OpenShift manages certain configurations via annotations along with applying certain defaults. For example, if route.openshift.io/termination annotation is set to edge, it is still possible to define the TLS certificate that will be applied to the ingress

Holistic alignment of Ingress Configurations

These charts include several Ingress resources exposing varying capabilities. The configurations and options are currently not uniform which causes challenges when looking to apply certain configurations
OpenShift Logic
OpenShift enables the "upconverting" of native Ingress resources to OpenShift Routes. The logic that is employed is located here
The following are several valid examples that can be defined within OpenShift to expose access to resources using Ingress resources

Passthrough Termination

No TLS termination occurs at the Ingress Controller as the backend pod is serving SSL certificates
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    meta.helm.sh/release-name: spire
    meta.helm.sh/release-namespace: spire-mgmt
    route.openshift.io/termination: passthrough
  labels:
    app.kubernetes.io/instance: spire
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: spiffe-oidc-discovery-provider
    app.kubernetes.io/version: 1.8.7
    helm.sh/chart: spiffe-oidc-discovery-provider-0.1.0
  name: spire-example-passthrough
  namespace: spire-server
spec:
  rules:
  - host: <hostname>
    http:
      paths:
      - backend:
          service:
            name: spire-spiffe-oidc-discovery-provider
            port:
              number: 443
        pathType: ImplementationSpecific

Edge Termination using default Ingress Certificate

TLS termination occurs at OpenShift Ingress Router using the default certificate defined within the Ingress Controller. Traffic to the backend pod is unencrypted
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    meta.helm.sh/release-name: spire
    meta.helm.sh/release-namespace: spire-mgmt
    route.openshift.io/termination: edge
  labels:
    app.kubernetes.io/instance: spire
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: spiffe-oidc-discovery-provider
    app.kubernetes.io/version: 1.8.7
    helm.sh/chart: spiffe-oidc-discovery-provider-0.1.0
  name: spire-example-edge
  namespace: spire-server
spec:
  rules:
  - host: <hostname>
    http:
      paths:
      - backend:
          service:
            name: spire-spiffe-oidc-discovery-provider
            port:
              number: 80
        path: /
        pathType: Prefix

Edge Termination using Specified Certificate

TLS termination occurs at OpenShift Ingress Router using the a provided certificate. Traffic to the backend pod is unencrypted
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    meta.helm.sh/release-name: spire
    meta.helm.sh/release-namespace: spire-mgmt
    route.openshift.io/termination: edge
  labels:
    app.kubernetes.io/instance: spire
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: spiffe-oidc-discovery-provider
    app.kubernetes.io/version: 1.8.7
    helm.sh/chart: spiffe-oidc-discovery-provider-0.1.0
  name: spire-example-edge
  namespace: spire-server
spec:
  rules:
  - host: <hostname>
    http:
      paths:
      - backend:
          service:
            name: spire-spiffe-oidc-discovery-provider
            port:
              number: 80
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - <hostname>
    secretName: <frontend_cert_secret>

Reencrypt using default Ingress certificate and trusted destination certificate

TLS reencryption occurs using the default Ingress certificate and destination certificate that is trusted within the cluster. Most likely using a certificate generated via Service Serving Certificates
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    meta.helm.sh/release-name: spire
    meta.helm.sh/release-namespace: spire-mgmt
    route.openshift.io/termination: reencrypt
  labels:
    app.kubernetes.io/instance: spire
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: spiffe-oidc-discovery-provider
    app.kubernetes.io/version: 1.8.7
    helm.sh/chart: spiffe-oidc-discovery-provider-0.1.0
  name: spire-example-reencrypt
  namespace: spire-server
spec:
  rules:
  - host: <hostname>
    http:
      paths:
      - backend:
          service:
            name: spire-spiffe-oidc-discovery-provider
            port:
              number: 443
        path: /
        pathType: Prefix

Reencrypt using provided ingress certificate and trusted destination certificate

TLS reencryption occurs using provided ingress certificate and destination certificate that is trusted within the cluster. Most likely using a certificate generated via Service Serving Certificates
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    meta.helm.sh/release-name: spire
    meta.helm.sh/release-namespace: spire-mgmt
    route.openshift.io/termination: reencrypt
  labels:
    app.kubernetes.io/instance: spire
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: spiffe-oidc-discovery-provider
    app.kubernetes.io/version: 1.8.7
    helm.sh/chart: spiffe-oidc-discovery-provider-0.1.0
  name: spire-example-reencrypt-frontend-dest
  namespace: spire-server
spec:
  rules:
  - host: <hostname>
    http:
      paths:
      - backend:
          service:
            name: spire-spiffe-oidc-discovery-provider
            port:
              number: 443
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - <hostname>
    secretName: <frontend_cert_secret>

Reencrypt using provided Ingress certificate and provided destination certificate

TLS reencryption occurs using provided ingress certificate along with a provided certificate served by the pod
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    meta.helm.sh/release-name: spire
    meta.helm.sh/release-namespace: spire-mgmt
    route.openshift.io/destination-ca-certificate-secret: <destination_cert_secret>
    route.openshift.io/termination: reencrypt
  labels:
    app.kubernetes.io/instance: spire
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: spiffe-oidc-discovery-provider
    app.kubernetes.io/version: 1.8.7
    helm.sh/chart: spiffe-oidc-discovery-provider-0.1.0
  name: spire-example-reencrypt-frontend-dest
  namespace: spire-server
spec:
  rules:
  - host: <hostname>
    http:
      paths:
      - backend:
          service:
            name: spire-spiffe-oidc-discovery-provider
            port:
              number: 443
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - <hostname>
    secretName: <frontend_cert_secret>

Reencrypt using default Ingress certificate and provided destination certificate

TLS reencryption occurs using provided ingress certificate along with a provided certificate served by the pod
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    meta.helm.sh/release-name: spire
    meta.helm.sh/release-namespace: spire-mgmt
    route.openshift.io/destination-ca-certificate-secret: <destination_cert_secret>
    route.openshift.io/termination: reencrypt
  labels:
    app.kubernetes.io/instance: spire
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: spiffe-oidc-discovery-provider
    app.kubernetes.io/version: 1.8.7
    helm.sh/chart: spiffe-oidc-discovery-provider-0.1.0
  name: spire-example-reencrypt-frontend-dest
  namespace: spire-server
spec:
  rules:
  - host: <hostname>
    http:
      paths:
      - backend:
          service:
            name: spire-spiffe-oidc-discovery-provider
            port:
              number: 443
        path: /
        pathType: Prefix

Thanks for the good overview of the issues you've hit.
To help prioritize solutions, are there any of these that are more of a problem for you then others?
I think there are probably some cases where supporting every permutation of options is undesirable. For example, spire-server's port must be passed through. Configuring it for retermination will only produce an unusable install. We need to identify the gaps in configuration options along with the softwares constraints.

@sabre1041 Any thoughts on the questions by @kfox1111 ?


Update Merlin to use Kserve 0.11.0

What this PR does / why we need it:

This PR updates Merlin so it can use Kserve 0.11.0.
Kserve 0.11.0 introduces a breaking change on the generated component name and URL (ref). It no longer includes the default suffix on both predictor and transformer. Hence, Merlin needs to be modified as well.
Prior to Kserve 0.11.0, the predictor pod name would be something like this: sklearn-sample-s-36-predictor-default-00001-deployment-7cbkpzq5. On Kserve 0.11.0, the default is removed, resulting the pod name to be sklearn-sample-s-36-predictor-00001-deployment-7cbkpzq5.
This PR also updates the e2e test to use the newer version of infrastructure components, namely:

Kubernetes 1.26.7
Istio 1.18.2
Knative 1.10.2
Kserve 0.11.0
Cert Manager 1.12.2

Which issue(s) this PR fixes:

Fixes #
Does this PR introduce a user-facing change?:

NONE

Checklist

[x] Added unit test, integration, and/or e2e tests
[x] Tested locally
[ ] Updated documentation
[ ] Update Swagger spec if the PR introduce API changes
[ ] Regenerated Golang and Python client if the PR introduce API changes

@ariefrahmansyah, could you add a summary to the PR with the main changes? Will be easier to review the PR with this initial understanding.

@ariefrahmansyah, could you add a summary to the PR with the main changes? Will be easier to review the PR with this initial understanding.

Updated. Please let me know if more information is needed.


Horizontal rule

@edokoa here are some ideas that @colebemis and I explored today

We both like the single line better.
https://www.figma.com/file/2rjsQp42uKvzPXzLZIqOeA/Octicons-v2-Source?node-id=597%3A1448

https://primer.style/octicons-v2/horizontal-rule-16

Should we group it with other elements instead of the list and quote? In those icons, the lines make reference to text lines. I think it would work better if we switched it to the side of the code and link buttons.

Should we group it with other elements instead of the list and quote? In those icons, the lines make reference to text lines. I think it would work better if we switched it to the side of the code and link buttons.

yeah i think so. @colebemis and i mentioned that yesterday and seeing you bring it up to @edokoa makes me feel more confident that it's a stronger recommendation.


convert blake2b::Digest to const generics

This is still a WIP. The basic method was to define an inner type
that behaves the way we want it to, e.g. with special Drop impls,
etc. Then for each newtype we want to create, we create a small
wrapper over the inner type, like struct Digest(Blake2bArray),
and implement two small traits, essentially From and AsRef, to
convert to that inner type.
In another module, we provide more complex blanket implementations
for any types that implement From and AsRef for our inner type.
This allow us to, for example, auto-implement len, from_slice,
etc for the newtypes without exposing the inner type (which could
be hazardous for inner types like the planned PrivateArray type.

So there are lots of problems with this branch as-is.

It's missing lots of documentation.
The location/name of the base.rs module is probably not ideal.
There's probably a better way to do these trait gymnastics than the OrionDeref trait I defined.

So this is more of a proof-of-concept that we might be able to use traits and const generics to achieve both implementation deduplication and the safety of newtypes.
@brycx Let me know what you think. I'm probably going to try this same thing on some kind of secret data type tomorrow night to see if the same strategy would work there. The inner type will have some more complex logic, but I think it should still work.

So I tried another iteration, this time splitting up PublicData and SecretData. It's simpler that way, and more easily allows us to define separate methods on them without worrying about trait bounds and Public/Secret marker traits (those marker traits were removed).
Basically, the new design is based around two structs:
struct PublicData<B, C> {
    bytes: B,
    context: C,
}

struct SecretData<B, C> {
    bytes: B,
    context: C,
}

The B type parameter allows us to use different byte storage objects to hold the underlying data, such as arrays, Vecs, and maybe even eventually bytes::Bytes. Both PublicData and SecretData share these underlying storage mechanisms.
The C type parameter stands for "context", and allows us to express the purpose of the data store. Practically, it ensures we never accidentally misuse a data store meant for a different purpose. If we have SecretData<_, EdPubKey> and SecretData<_, EdPrivKey>, we can't accidentally mix them up.

In order for us to evaluate these different strategies for viability (or non-viability), I think it would be good to come up with some criteria. Here's a first-draft list of what we would need from a successful design around const-generics. @brycx Let me know if you have comments/edits.

[x] Define newtypes (not aliases) for various types such that they can't be erroneously mixed together
[x] Avoid source code duplication across newtypes. Right now we're at about 7 or 8 LoC per newtype, and it's all data entry (e.g. defining min and max size for the type).
[x] (Obviously) support all the various methods we already have defined via macros.
[x] Define separate methods for public vs. secret types.
[ ] Per-type documentation. It's annoying to see documentation for an HMAC SHA256 Tag when we're looking at a PasswordHash. The current macro design also has this issue. See below for some notes on the current docs situation in this iteration of the const-generics design.
[x] (?) Define ad-hoc additional methods per context. For example, we could define some random extra methods on SecretData<VecData, PasswordHash> if for some reason we wanted methods specific to a password hash.

Right now the documentation situation is… meh. Anyone trying to read through the docs for either SecretData or PublicData will get bogged down in generic types if they look too closely. That said, the methods available on these types are pretty simple (basically from/to slice, get len, etc.). Maybe normal users don't need to really understand the generics.
It's nice that the SecretData and PublicData docs are split up in this iteration. Having the secret/public data methods intermingled was something I really didn't like about the previous design.
Also, we can still have documentation on the type alias itself. If we look at the docs for orion::hazardous::hash::blake2::blake2b::Digest in this branch, we see some (currently nonsensical) documentation for the type alias itself. I'm not sure what we'd want to put there vs. in the module-level docs (which is what we use currently), but it's an option.

In order for us to evaluate these different strategies for viability (or non-viability), I think it would be good to come up with some criteria.

So far, I haven't come across additional criteria. Most of it seems to be covered by what you found!

Recording here the original motivation for trying to replace the macro implementations. There were basically three reasons.
Byte Storage Parameterization
It's desirable for us (and maybe users) to be able to easily configure the storage mechanism used by the Orion APIs. For example, the type emitted by orion::auth::authenticate is orion::auth::Tag, which is an array. We can imagine an application where an Orion user is frequently reading Tags from the network and verifying them.
Right now, the user would have to copy the data from the network buffer into an owned Tag for verification. This is because the Tag type is currently hard-coded to be an array. Ideally, we would be able to support more than one byte storage type for things like Tag. We could maybe support a tag that holds a byte slice, or even a bytes::Bytes object, which is common in networking code.
Readability / Auditability
Macros frequently pose challenges for those trying to investigate the implementation of specific types. As the most recent example, when I tried to figure out what the backing storage type of orion::auth::Tag was, I went to the docs page, clicked on auth, then Tag, and finally on "source", which brings you to this construct_tag! macro invocation. In order to understand more, I had to open my local copy of Orion, rg for macro_rules! construct_tag, and go check out that file.
Types defined using the const-generics+traits+newtypes have a better story here. After clicking on Tag, I would have seen that it was a newtype for something like PublicData<ArrayData, Blake2bTag>, and then I could have clicked through to each of those three individual types to learn more.
Documentation
This is a minor point, but if we check out that same Tag documentation (this also applies to most of the newtypes we have defined), we find an example that starts with:
use orion::hazardous::mac::hmac::sha512::Tag;

This is the wrong type, which is a bit confusing. Ideally it would say something like:
use orion::auth::Tag;

We actually see the same problem with the poly1305::Tag. The poly1305::Tag documentation shows the same example starting with orion::hazardous::mac::hmac::sha512::Tag. The underlying issue is that the macro_rules! construct_tag has the HMAC documentation inside it, which is necessarily shared with every newtype created by the construct_tag macro.
We can probably solve this without moving away from macros. (What would happen if we just moved the docs to above the declaration of the newtype from out of the body of the macro_rules!?) However, I think we can do a bit better by having specific documentation on the primary types and their operations (PublicData/PrivateData), the contexts (e.g. Blake2bTag), and the byte storage types (ArrayData/VecData/etc.).

I think many of the traits that we define for these newtypes should be contained within a private module so that we avoid users being able to define their own newtypes perhaps?
… Just wondering if users'd be able to make invalid newtypes and pass them to a primitive's API.

I think it would be okay for users to define their own newtypes, but we should think carefully about this.
Users creating their own newtypes — at those if they want those newtypes to be usable with the Orion API — would only be able to customize the byte storage. They could certainly do problematic things with the byte storage, such as logging the underlying bytes to stdout on creation or choosing random subsets of bytes to return on each AsRef call.
But these traits are in the hazardous module, and that's kind of what the module is there for. There are plenty of ways to shoot yourself in the foot by using functions and traits defined in hazardous. Adding "dangerous" traits to the mix doesn't seem like a big change from status quo.
If we wanted to prevent users from implementing traits like Bounded (should probably be renamed to Bound) and Generate, we'd probably have to "seal" the traits instead of making them private. I think we need them to be public if public methods on e.g. PrivateData are restricted by those traits.

I mentioned in my last comment that users "would only be able to customize the byte storage". I should justify this. There are some subtleties here, and decisions to be made.
The reason they can only customize the byte storage is because I might expect Orion functions to take inputs like:
type SecretKey<B> = SecretData<B, XChaCha20Poly1305Aead>;
type Tag = PublicData<Array, Poly1305Tag>;

pub fn authenticate<B: Bound>(secret_key: &SecretKey<B>, data: &[u8]) -> Result<Tag, UnknownCryptoError>;

Basically, I'm saying that we can allow certain Orion functions to be generic over the byte storage type, which would allow us to take advantage of the byte storage parameter. I can't really imagine a scenario where we'd want to be generic over the context. The whole purpose of the context parameter was to prevent use of the wrong types that are otherwise identical.
That said, for this initial iteration, we could just sidestep this problem and say "you have to use exactly what type we give you", which is closest to what we do now. We can then open a separate issue about how/whether to allow parameterizing over the type.

@brycx This is more or less in a place where I'm looking for "final" feedback on the general design. After that, I'm ready to move forward and actually implement all the public types in terms of const generics, and try to take this PR out of "draft" status.
When you have a chance, could you take a look at how the tests are declared per type? Here's an example of the AEAD SecretKey type's tests.

@vlmutolo I think this design is good. I'd say it's ready to go on to the next round.
Re the tests: I think they look good. I took a quick look at the macros and so on; they seem not too cluttered and should offer the same coverage as the previous ones. Unless there's something specific you'd want me to look into there, I'd also say this is in good shape!

There are a couple TODOs left in the code that I could use a second opinion on. Nothing major, and nothing that can't wait until we have a full, non-draft PR to look at.
For example, here's one regarding the naming of one of the "context" types.
I'll start filling in the rest of the types, and then we can revisit the minor TODOs (mostly just nitpicks).

The TODOs I saw didn't seem too major, but maybe I missed some. The naming I've found no problem with yet, but in the case we want to change some, can always replace all references - which most IDEs support.

True, but the context parameter names do technically show up in the public interface, even if usually hidden behind type defs. Once this PR gets closer to finished I'll try to think through the various context parameter names.

Sounds like a very good plan.


Multiple Main Overlay

Description
I currently have this requirement: I use built-in indicators like MACD in the framework to calculate a numerical MACD, but this numerical value is not OHLCV, but another value calculated. However, the built-in indicators in the framework currently use OHLCV data as the main overlay, and I found through testing that even if I create another pane and pass in the calculated value, I cannot use that value with the built-in indicators. Is there another way to meet this requirement? Looking forward to your reply.
Suggested solution
I currently don't have any suggestions.
Alternative
No response
Additional context
No response
Validations

[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Datasets that were used in TVJS is not tested/implemented yet. But you could make a hack putting your data in the main (hiding it), adding candles as overlay.

Datasets that were used in TVJS is not tested/implemented yet. But you could make a hack putting your data in the main (hiding it), adding candles as overlay.

Thank you very much, I'll try it.


Test light client Expired state

what i'm currently trying to figure out is how to simulate light client expiry. basically, for two chains to connect and make a connection, they need to run light clients of eachother. light clients are small versions of the other blockchain's state machine. using light clients the two chains can prove things about each other. for example, a relayer might prove attempted delivery when returning a timeout.
light clients (for reasons i think are related to them being "light") have an expiration. in the trusting period. if a light client expires, it enters this strange state of "expired". we need to learn more about this state.
the code can be found on the zeke/strangelove branch and is based on this test from the ibc-go team:
https://github.com/cosmos/ibc-go/blob/main/e2e/tests/core/client_test.go
if you read through the test you can see how they make a client expire and then use x/gov prop to bring it back to life. the expired state is different from closed. my current understanding is that in the expired state it won't accept packets, what i want to learn is if, in that state it will allow timeouts to be returned to the sending chain?

done in 57c80a9f9312620f3f75a4b4434990e941473ed6


How to convert a list of ra and dec into a ds9 region file?

I have a numpy array of ra and dec coordinates which I first make a skycoord object and then try to write a region file from that.

I keep getting this error :
'center' must be a scalar SkyCoord
Amy suggestions?

The center SkyCoord input to CircleSkyRegion must be scalar, i.e., only have one RA/Dec coordinate. (use center.isscalar to check).
You need to create a CircleSkyRegion for each coordinate and then pass a list of CircleSkyRegion objects to the Regions class, which can then written to a DS9 file.

Hey Larry,
Thanks for getting back, I actually tried something like that, but I guess the "Regions" class cannot recognize a list.

Maybe I am doing something wrong?

You're close, but missing a step.  reglist is just a regular python list.  You need to create a Regions object (https://astropy-regions.readthedocs.io/en/stable/api/regions.Regions.html#regions.Regions) from your reglist:
>>> from regions import Regions
>>> regs = Regions(reglist)
>>> reg.write(....)

from regions import Regions

Perfect! This makes sense. Thanks so much for getting back quickly 👍


Admin interface does not honour configured ports

Hi,
I've had a bit of a nightmare changing the admin and API ports. I suspect there are two separate issues here.
I'd been running a standalone v0.8.8 (on CentOS 7) for a bit testing things, and wanted to change the admin and API ports due to our restrictive office firewall. I changed [admin]->port to 8443 and [api]->port to 2087 in /opt/influxdb/shared/config.toml and restarted influxdb, but neither port was listening when checked with lsof. Changing the ports back and restarting still left influxdb not listening on any port but 8090. I think this is similar to issue #198 which was for a very old version.
In the end, I had to blow away the data directory to get influxdb listening again on the ports I'd configured (8443/2087). So that's issue one - changing ports seems to require the data directory to be purged.
The main issue here though is that the admin interface is not honouring the API port. When I managed to get the ports changed and listening correctly, trying to login via the admin interface I can see the interface trying to connect to the server via port 8086 in browser dev tools, rather than the port I've configured (2086).

Did you put in the new port number on the spot on that login page? It doesn't get populated automatically, so if you change the port, it's up to you to put it in the admin interface when you want to log in.


Report oldest log times

Fixes #98
Still need to discuss the right way to output this. It's kind of a mess.

Example with the days approach:

Example with OutPath:

I think this is still too ugly. The massive table below the "Nothing suspicious" message really clutters things up.

Should add a way to break up the results of each server. When i first read that, didn't realize that the results were from different servers.
Might be ideal to do in the following order:

write to host "results for server X"
proxy logs ages
proxy logs test results - good or bad

Without the new log file age stuff, the output from the current version of the script is pretty clean:

So we need a way to preserve that while also showing something about the log file ages.

How about merging this? Even a bad solution is better than no solution here. Lot's of orgs will scan their logs and think they're green, not even realizing that their logs don't cover a significant time span.

We'll probably go with this for now. Still not great, but at least it indents and only takes up 1 line if your shell is wide enough.


Alternative model for proposing suggestions

The current (v0.1.0) mobility specs require the sending institution to allow receiving institution to directly change the mobility object. This was one of the requirements from WP2's output.
However, @janinamincer-daszkiewicz claims that that - in practice - the receiving HEI only suggests these changes, and it is always the sending HEI who actually applies them. This discussion lead us to thinking of some alternatives, but before I start on actually specifying them, I'd like us to discuss this here.
Is it required to allow the receiving HEI to change the Mobility object "in real time" (as in current specs)? Or, would it enough if they only proposed such changes, and the sending HEI would store them "on the side" and review them later (without changing the actual mobility object in real time)?
Currently, both solutions sound feasible to me, but our internal team claims that "suggestions" would be much simpler for them to implement. @erasmus-without-paper/all-members - what do you think?

We will abstract the api to suggestions either way, so if we use suggestions by design it would fit even better. Usually universities are not very happy if some 3rd party members change their student data. For our most recent customers (last ~2 years) it is even legally forbidden, since they have to state every person which has access to this data.

This concept is already in the model, but it's connected to Learning Agreement (which, in practice, means changes to the underlying Components): A New Revision of a LA has a "Suggesting IIA Partner" and Sending/Receiving Approval Dates. But if it always is the receiving HEI that suggests, the IIA Partner Reference isn't needed. I will replace it with a Suggesting Date (which should have been there anyway).
BTW, this connects with the discussion about which Mobility information that needs to be versioned: The Suggesting and Approval Dates are connected to LA, not the Mobility itself, which means that the Mobility fields Status, Planned/Actual Arrival/Departure Dates etc. are not subject to the proposed suggestion process.

Mobility fields Status, Planned/Actual Arrival/Departure Dates etc. are not subject to the proposed suggestion process.

As far as I know, actual arrival/departure dates are always provided be the receiving HEI.
I will think how this can be implemented. But probably there will be a couple of various types of suggestions one can send. Perhaps we will even need a separate API for each type of suggestion (because we need the sending HEI to be able to cover only a subset of all possible suggestions).

As far as I know, actual arrival/departure dates are always provided be the receiving HEI.

Hm - yes, of course. It seems there are three bad solutions here, model-wise:

The Actual Arrival/Departure Dates are moved from Mobility to LA (even though they have nothing to do with the agreement per se) - meaning that the receiving HEI updates the dates in the final LA Revision.

The Suggestion Date and Sending/Receiving Approval Dates are moved from LA to Mobility - meaning that the mechanism for suggesting/approving changes applies to the Mobility as a whole, not just the LA.

The Suggestion Date and Sending/Receiving Approval Dates are duplicated from LA to Mobility - meaning that both Mobility and LA have a mechanism for suggesting/approving changes.

Alternative 3 is the worst, but I'm not sure about the other two. What do you think, @wrygiel ?

How about storing suggestions as XML blobs?
-- pseudosql
create table suggestions (
    mobility_id varchar,
    author_hei_id varchar,
    author_email varchar,
    date date,
    status? enum(...),
    suggested_change_xml text,
    -- possibly more... (comments? revisions?)
)

Since these are suggestions only, they will probably be processed by a single piece of software only. Only after they are reviewed, they would go to the actual data tables and become visible to other pieces of software.
If so, then there's no real gain in keeping these suggestions in multiple specialized tables - we may keep all kinds of suggestions in a single blob-based table, and suggested_change_xml would contain the actual suggestion, exactly as received from the partner, in XML format (specified by EWP).

How about storing suggestions as XML blobs?

Hm, maybe... Are you suggesting that these be used for versioning as well, i.e. for reconstructing the change history? If that is doable, it would solve the versioning issue as well.

Are you suggesting that these be used for versioning as well, i.e. for reconstructing the change history?

No. Versioning history is a somewhat separate issue. But this would make implementing versioning history easier, I think, because there would be only one "committer" in such history.

As fas as I know, versioning has to be implemented for components only, and maybe nothing more. While suggesting needs to be implemented for a broader set of fields.
But this is not a mature concept yet. It requires much more thought on my part.

As far as I know, versioning has to be implemented for components only, and maybe nothing more.

Hopefully. I will remove versioning at the Mobility level for the time being, to unclutter the diagram.

While suggesting needs to be implemented for a broader set of fields.
But this is not a mature concept yet. It requires much more thought on my part.

I will think about this at my end too...

The new way of proposing suggestions is described here.


bump patch version

you released 2.2.1, but didn't update the version

Ah true, oops. Good catch, thanks!


Template not found error on Slack when accessing settings/manage page with invalid form identifier

Description
An error is thrown in the web application when accessing the settings/manage page with an invalid form identifier. This causes an alert log to be sent on Slack.
Steps to reproduce

Go to https://forms-staging.cdssandbox.xyz/en/form-builder/thisisatest/settings/manage
See error Error: Template not found on Slack in the #forms-staging-events channel

Expected behaviour
We should not be notified of such error on Slack.
Additional context
Discussion about the problem https://gcdigital.slack.com/archives/C05G766KW49/p1721329614030249

Issue has been fixed with PR #4571


Fix broken link

The link at the bottom of https://google.github.io/styleguide/shell.xml is
broken. When changing from cppguide.xml to cppguide.html, it works.
Also removed trailing whitespace.

I do apologize for the delay in getting to this; previously, no one was currently watching this repository. Thank you for your contribution.


add load-test module

load test can be run with:
sbt
project load-test
gatling:testOnly org.http4s.load.DemoSimulation

html report is output at load-test/target/gatling

This appears to be loading the demo? I expect that to change to a local server in the future. The demo is running on an EC2 micro instance so the performance will be very stochastic based on the other processes running on the physical hardware.

yes it just sending a get request to the index of the demo. We can change the url target and add more sophisticated cases like url form, json, etc but I just wanted to show the pattern.

Wonderful. I'm excited to get this in place. As a side note (related only
by the need to spin up servers), we've been talking about it for a while,
but we also need to start spinning up live servers for testing purposes too
to avoid issues like PR #224. I suspect there will be a bit of overlap with
your work here.
On Fri, Feb 27, 2015 at 12:08 PM, Julien Truffaut<EMAIL_ADDRESS>wrote:

yes it just sending a get request to the index of the demo. We can change
the url target and add more sophisticated cases like url form, json, etc
but I just wanted to show the pattern.
—
Reply to this email directly or view it on GitHub
https://github.com/http4s/http4s/pull/225#issuecomment-76430629.

Where does this PR stand? I would hate for good work to get stale.

Basically this PR simply add the basic architecture for load testing but we will have to write more complex scenario to be useful. The main issue is that we need some demo to test against it.

Does that need to be in this PR? If so, we should get it done so this can get merged. If not, we should merge this and open a new ticket for 'More intense and diverse load test routes' or something like it. That would be a really good 'help wanted' issue that someone could use to get familiar with http4s while making a good contribution.

I would prefer to merge this PR and then create another ticket as you suggested. I wrote a few gatling scenario so I am ready to help but I am pretty busy atm

Alright, lets do that. @rossabaker: object soon if you don't want this merged. I'll likely take care of it this afternoon.


Dropping a partition column throws NPE

table.updateSchema().deleteColumn(col1).commit() throws NPE if the table is partitioned by col1
Stacktrace:
Caused By (java.lang.NullPointerException) null     org.apache.iceberg.PartitionSpec.checkCompatibility():485     org.apache.iceberg.TableMetadata.updateSchema():285     org.apache.iceberg.SchemaUpdate.commit():209

@pprudhvi would you please provide a simple reproducible code, thanks.

public static void main(String... args) {     IcebergTableOperations tableOperations = new IcebergTableOperations(new Path("/tmp/student"), new Configuration());     Schema schema = new Schema(Types.NestedField.required(1, "id", Types.IntegerType.get()),         Types.NestedField.required(2, "name", Types.IntegerType.get()));     PartitionSpec partitionSpec = PartitionSpec.builderFor(schema).identity("id").build();     TableMetadata metadata = TableMetadata.newTableMetadata(tableOperations, schema, partitionSpec, "/tmp/student");     Transactions.createTableTransaction(tableOperations, metadata).commitTransaction();     Transactions.newTransaction(tableOperations).updateSchema().deleteColumn("id").commit();   }

Looks like checkCompatibility needs to be updated to throw an exception with a better error message when a column is not present. @pprudhvi, would you like to submit a PR to fix this?

yes, I can submit a patch but it won't fix the issue with dropping a partition colum. Or do we need to follow a different path to drop such columns - update partition spec first and then call deleteColumn ?

@pprudhvi, I think #716 is going to add a nice error message for this. #532 added a check to the validation, but that error message was confusing.

#714 tracks the error message, and #532 fixed the NPE this reported so I'm going to close this.


Support domain socket

Describe the proposal
Ref https://github.com/dapr/dapr/issues/2864
Release Note

RELEASE NOTE: ADD support domain socket.

@daixiang0
I think this won't be as useful until the CLI can actually return the UDS path in an environment variable:
https://github.com/dapr/cli/issues/969
Once that is complete I am happy to add support for UDS (and it will be easier for us to test too).
Implementing UDS support isn't hard for gRPC, but is trickier for HTTP.

I am curious why it is trickier for HTTP, listen one UDS likes addr+port both for gRPC and HTTP, do you mean the limit of python-sdk itself.

@daixiang0 because the Python requests library - the most commonly used HTTP client - does not have support for UDS. I am against replacing this library.
I found the following https://pypi.org/project/requests-unixsocket/ but I do not trust this package so far.
Perhaps monkeypatching as described here https://github.com/msabramo/requests-unixsocket might be possible -- in this case I prefer using a context manager instead of global monkey patching to avoid any unintended side effects.
https://github.com/msabramo/requests-unixsocket#implicit-monkeypatching

/assign

This is already supported for gRPC, but will not be implemented for HTTP which only supports service invocation anyway.
Example:
dapr run -u /Users/bverst/testfolder this will create a dapr-$appid-grpc.socket file in this folder.
Now in Python we can use this socket like so:
from dapr.clients import DaprClient
d = DaprClient(address='unix:///Users/bverst/testfolder/dapr-flying-giraffe-grpc.socket')
d.get_metadata()

Ironically this was supported all along thanks to the underlying gRPC library!


Embed bots input & add thumbnail w/ each leagues logos

Current output, need to find a way to embed this and add thumbnail

All league codes have a thumbnail and have been embedded, pushed to main branch


Surface GraphQL V2 IDs in webhook payloads

Initially requested in https://opencollective.slack.com/archives/C4TC3AYDT/p1676909213782629
Our webhook events currently surface numerical IDs:
{
  "createdAt": "2022-07-18T10:30:44.479Z",
  "id": 309906,
  "CollectiveId": 16658,
  "type": "collective.transaction.created",
  "data": {
    "fromCollective": {
      "id": 4469,
      "type": "USER",
      "slug": "betree",
      "name": "Benjamin",
      "twitterHandle": "Betree83",
      "githubHandle": "Betree",
      "repositoryUrl": "https://github.com/Betree",
      "image": "https://opencollective-staging.s3.us-west-1.amazonaws.com/550ac070-e0f8-11e9-9d4c-e9c71c24ba70.jpg"
    },
    "collective": {
      "id": 16658,
      "type": "COLLECTIVE",
      "slug": "captainfact_io",
      "name": "CaptainFact",
      "twitterHandle": null,
      "githubHandle": "test",
      "repositoryUrl": "https://github.com/CaptainFact",
      "image": "https://opencollective-staging.s3.us-west-1.amazonaws.com/10dd8f00-54c8-11eb-bfdc-17c9ddbead53.png"
    },
    "transaction": {
      "id": 233159,
      "kind": "CONTRIBUTION",
      "type": "CREDIT",
      "uuid": "a6a00550-95c4-48b2-bb32-ceb185232725",
      "group": "9268b46d-74e7-4360-ac99-9413f78bb73e",
      "amount": 4198,
      "isDebt": false,
      "OrderId": 50684,
      "currency": "EUR",
      "isRefund": false,
      "ExpenseId": null,
      "createdAt": "2022-07-18T10:30:14.942Z",
      "taxAmount": null,
      "description": "Monthly financial contribution to CaptainFact (Fixed recurring)",
      "CollectiveId": 16658,
      "hostCurrency": "EUR",
      "CreatedByUserId": 4829,
      "FromCollectiveId": 4469,
      "amountInHostCurrency": 4198,
      "hostFeeInHostCurrency": 0,
      "netAmountInHostCurrency": 4033,
      "platformFeeInHostCurrency": 0,
      "UsingGiftCardFromCollectiveId": null,
      "netAmountInCollectiveCurrency": 4033,
      "amountSentToHostInHostCurrency": 4033,
      "paymentProcessorFeeInHostCurrency": -165,
      "formattedAmount": "€41.98",
      "formattedAmountWithInterval": "€41.98"
    }
  }
}

To promote our public GraphQL API and deprecate numerical IDs, we should start surfacing them in the payloads. This should be done with a new field to make it non-breaking.
Suggestions: publicId, idV2.

I found myself wanting this earlier today so it would be quite appreciated.

Requested again in https://opencollective.slack.com/archives/C4TC3AYDT/p1695911085050079


Retest Only: Custom Data download filter - 508 issue

Context
Testing complete for 2231 - issue found when no results are returned for a combobox...such as owner operator. When the filter logic causes no results, if you open the combox it says 'no owners/operators' match your search. However this text is not accessible to a screen reader. This may be a non issue because I believe it was stated the filter button will be disabled in a future sprint, however right now this scenario would be flagged.

Retest ticket when Disable filters that do not contain selectable data #2343 is completed

@aprematta This ticket is ready for testing

Closing issue, since the filter button is now disabled with no results, you can't get to the inaccessible text.


Fix leaking proposals

Fix issue #538

Hi @eltonscm sorry for the late. I'm doing the merge, everything looks fine.
Thanks!
o/


NFS 3.0 and SFTP can't be enabled on the same storage account.

NFS 3.0 and SFTP can't be enabled on the same storage account.

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

#label:"aq-pr-triaged"

Good catch. The acronym "SFTP" is undefined in this doc. Can you please replace "SFTP" with "SSH File Transfer Protocol (SFTP)"? Thx

@normesta Thanks for pointing it out. Changes done. Please check

Thank you!
#sign-off


[ChatContainer] JsonObject retrieves Optionkeys instead of String

Hi,
When calling 'createDirectConversation' I get a error:
"Caused by: java.lang.ClassCastException: io.skygear.plugins.chat.Conversation$OptionKey cannot be cast to java.lang.String"
My guess is that the JSONObject (at line: 97 of the ChatContainer class) in the 'createConversation' method is expecting a String in his constructor instead of the OptionKey from the enum.
Correct me if I am wrong! Look forward to a fix.

@spmvanmierlo Thanks for reporting! Yes, there is some problem in createDirectConversation. We already created an issue https://github.com/SkygearIO/chat-SDK-Android/issues/68 for that. Will fix it very soon and update in the coming release. :)

Fix on #68


chore: update readme in preparation for awesome-go application

Adds the Go Report card and centres all the cards in the README.
You can see the layout here
Whilst aligning them all in the centre looks "nicer", its made me question if they would be better living under the Templ gif in the README rather than in the documentation section? I'll let someone else decide that and I can make the change if needs be.
Also if you don't care about the cards being in the centre, I can change that back.
I don't think this specifically closes #196 but gets us a step closer as I can open a PR in awesome-go once this is all merged.

I agree, under the Gif

Thanks!


No AUX case for BNO085 (SlimeVR) chips

The AUX case is too small for the BNO085 (SlimeVR) chips. Any chance someone has this file? I can try to edit the existing design myself but I dont have any relevant experience for the job (new to 3d printing in general).

I decided to look in the untested folder and found it! im going to leave this up and report back on how well the chip fits.
Speaking of how well the chip fits, I cant seem to get the BNO085 (SlimeVR) chip to fit into the tray without cutting out most of the walls around the slot for it. I dont believe its an issue with printer settings but as I said im new to this so its possible. Just seems a little too off to be my settings since everything else seems to be accurate

so the file I found (https://github.com/Smeltie/Hyperion/blob/main/Untested/AUX_Housing_BNO08x.stl) is close but like the BNO08x tray its just a little too tight. I can probably cut it down like I have to do with the tray and make it work. I might try to get into the design files and modify it to fit but my confidence is fairly low

so the file I found (https://github.com/Smeltie/Hyperion/blob/main/Untested/AUX_Housing_BNO08x.stl) is close but like the BNO08x tray its just a little too tight. I can probably cut it down like I have to do with the tray and make it work. I might try to get into the design files and modify it to fit but my confidence is fairly low

Can you sand the edges of the BNO08 board to make it fit?

so the file I found (https://github.com/Smeltie/Hyperion/blob/main/Untested/AUX_Housing_BNO08x.stl) is close but like the BNO08x tray its just a little too tight. I can probably cut it down like I have to do with the tray and make it work. I might try to get into the design files and modify it to fit but my confidence is fairly low

Can you sand the edges of the BNO08 board to make it fit?

 I modified the files to make it fit, its a bit off but it works.

so the file I found (https://github.com/Smeltie/Hyperion/blob/main/Untested/AUX_Housing_BNO08x.stl) is close but like the BNO08x tray its just a little too tight. I can probably cut it down like I have to do with the tray and make it work. I might try to get into the design files and modify it to fit but my confidence is fairly low

Can you sand the edges of the BNO08 board to make it fit?

 I modified the files to make it fit, its a bit off but it works.

Have you posted the STL's anywhere? I've just printed the ones from Untested folder, but waiting on the BNO08's to arrive from slimevr before I can build

@ItsVRK no I havent, they are a bit too flawed for me to want to share them. I reached out to the creator on discord to see if he is willing to adjust them in a less jank way. I am going to move forward with my flawed version but id like to get the files fixed to avoid this situation in the future

@ButterMeWaffle My BNO085's arrived from SlimeVR today and fit in the versions of https://github.com/Smeltie/Hyperion/blob/main/Untested/AUX_Housing_BNO08x.stl that I printed fine, perhaps you need to calibrate your printer?


Route only a specific subnet

Is it possible to route only <IP_ADDRESS> traffic through the ssh server.
e.g.
Machine A (local machine) IP is <IP_ADDRESS>
Machine B (remote machine which the Machine A can login using ssh) is <IP_ADDRESS>
B has access to <IP_ADDRESS>.
How can I access the <IP_ADDRESS> using A.

This may work.
Machine-A $ wsshuttle -r <IP_ADDRESS> <IP_ADDRESS>/8


Propose Otoroshi, API Management layer and reverse proxy

Propose Otoroshi into the list of API Gateways / Edge Services

Already added.

Thnk you !!


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


BusError only with mega model

Running the command from the README:
python image_from_text.py --text='a comfy chair that looks like an avocado' --mega --seed=4
gives me this output:
Namespace(mega=True, torch=False, text='a comfy chair that looks like an avocado', seed=4, image_path='generated', image_token_count=256)
parsing metadata from ./pretrained/dalle_bart_mega
tokenizing text
['Ġa']
['Ġcomfy']
['Ġchair']
['Ġthat']
['Ġlooks']
['Ġlike']
['Ġan']
['Ġavocado']
text tokens [0, 58, 29872, 2408, 766, 4126, 1572, 101, 16632, 2]
loading flax encoder
encoding text tokens
2022-06-28 11:32:39.180526: E external/org_tensorflow/tensorflow/compiler/xla/service/cpu/simple_orc_jit.cc:202] Unable to resolve runtime symbol: `___extendhfsf2'.  Hint: if the symbol a custom call target, make sure you've registered it with the JIT using XLA_CPU_REGISTER_CUSTOM_CALL_TARGET.
JIT session error: Symbols not found: [ ___extendhfsf2 ]
Bus error: 10

This only happens with the mega model.

Indeed it is - thanks!


Collection New/Edit Form - Branding is not displaying

Summary
I can save branding settings for a collection, however they do not display on the collection.
Example
Public Interface

Saved Settings

This is an example of what it should resemble/
Acceptance Criteria

[ ] As an admin user, I can set the branding for a collection through the Edit collection form, can save it, and it displays on the public and dashboard interface

Kirk to update the submodule and retest.

Dupe. Test with