Add a model for spectral corrections

Additional context
First of all, I introduce myself, my name is Jose Antonio Caballero, and I have recently finished my PhD in photovoltaic engineering at the University of Jaén, Spain.
I have developed a python script to apply spectral corrections as a function of AM, AOD, PW based on this work (https://doi.org/10.1109/jphotov.2017.2787019).
We have found that in pvlib there is already a similar methodology developed by First solar, in which the spectral corrections are based only on the AM and PW parameters, so we intend to include our proposed method in pvlib in a similar way.
As an example, I attach the code developed in python (.zip file) to estimate the spectral effects related to different flat photovoltaic technologies from the AM, AOD and PW parameters included in a .csv file.
PV-MM-AM_AOD_PW_data.csv
PV_Spectral_Corrections.zip
Kind regards

Hello @Jacc0027 and welcome to this community.
I would welcome submission of a function implementing that model. It differs from the existing functions by including parameters for perovskite cells.
It would need to be coded as a function similar to first_solar_spectral_correction using the same parameter names, where possible.
The script isn't in a function format. The time series in the .csv file appear to be related to the SMARTS simulations used to set up this model, is that correct? If so, then these data don't need to come into pvlib.

My pleasure @cwhanse , thank you very much for the welcome.
No problem, I can adapt the code in a similar way to the one you attached, and assuming the same variables.
Yes, you are right, the script I attached is not made as a function, it was just a sample to verify the results. And again you are right, the time series in the .csv file are obtained through SMARTS simulations
Therefore, I will attach in this thread the modified code as we have just agreed.

Hi @cwhanse , please find attached the updated script, in which we have tried to meet the requested requirements.
I look forward to any comments you may have.
AM_AOD_PW_spectral_correction.zip

I suggest putting some information into the doc string about the range of applicability.  Is it for clear-sky conditions only, or all sky?  Is it for 30-degree tilt only, a range of tilts, or any orientation?

Hello Anton,
the proposed experimental equations are applicable in all sky conditions.
The fit coefficients were obtained experimentally with integrated and spectral irradiance measurements with an inclination of 30º above the horizontal. Strictly speaking, this would be the valid tilt for the model.
Regarding the orientation, the experimental installation was completely oriented towards the south, so it can be applied considering this scenario and subsequently applying the corresponding adjustment for orientation losses associated with a different orientation to the one considered in the model. This methodology is usually applied in the modelling of PV systems independently of this spectral adjustment.
The limitations of the model remain to be verified, as indicated in both,  the proposed python script and the published paper. It remains to be seen how the adjustment coefficients are modified in locations with extreme climates where AOD and PW values are frequently high.
In any case, we are firmly convinced that this model performs better than others that do not consider AOD as an input parameter, since it is an important factor that affects short wavelengths significantly.
I remain at your disposal in case of any further questions.


Fix uncategorized post bug

Description
If, for any reason, a post does not have a category associated, it breaks at Metadata component trying to get the slug.
It just adds a check if at least there is one category in order to mount the categories list item or not.
Screenshots

Error

looks great @GuilleAngulo thank you!
@all-contributors please add @GuilleAngulo for code


Requesting for script to connect to loco trivia socket

@Exaphis On sniffing my phone traffic I got that loco trivia provides questions on its websocket
& for connecting to websocket first we have to enter the socket site and in response it provides sid everytime we click the site . Then in websocket address we have to put sid value then it gets connected to socket and questions come in.
Please weite a script so that it automatically browse the  socket address, take the sid value and with that sid and it gets connected to websocket .
If you want the sniffed traffic I can provide you

Duplicate of #47


Update to inline SPIR-V

Some features in the inline SPIR-V are hard to use, and some features are
missing. This proposal suggestes some changes that we can consider.

@s-perron, sorry, we’ve had a couple busy weeks and the holiday last week had lots of people out. I’ve assigned this to myself, @tex3d, and @pow2clk so that it shows up on our work queues.
I had some comments that I had started to put together (nothing big), and I’ll get those posted today or tomorrow and we can aim to get this merged soon.

@llvm-beanz Ping.

Both are done. I opened https://github.com/microsoft/hlsl-specs/issues/76 to follow up on Nathan's idea.

let me show you a vaguely "nuts" usage of SPIR-V intrinsics
https://godbolt.org/z/EEoebnTPK
As you can see I'm a bit impatient for proposals 0006 and 0010 to get ironed out and decided, so I want to make a bit of my own throw away code.
struct MyStruct{
    uint32_t a;
    uint32_t b;
    uint32_t c;
};
// 15 just happens to guess typeid(MyStruct) by accident, also its only ever defined if its used somewhere else outside BDA
#define typeid_MyStruct 15

namespace nbl
{
namespace hlsl
{

namespace spirv
{

namespace impl
{

// I need to call it myself in a way reachable from the entry point which is mildly annoying
[[vk::ext_type_def(60,/*SpvOpTypePointer*/ 32)]]
void createPtrType([[vk::ext_literal]] int storageClass, [[vk::ext_literal]] int type);

// Shouldn't I be doing the rest with?
typedef /*vk::ext_result_id<*/vk::ext_type<60> /*>*/ imm_p_MyStruct;

[[vk::ext_capability(/*SpvPhysicalStorageBufferAddresses*/ 5347)]]
[[vk::ext_instruction(/*SpvOpConvertUToPtr*/ 120)]]
imm_p_MyStruct ConvertUToPtr(uint64_t src);

template<typename T>
[[vk::ext_instruction(/*SpvOpLoad*/ 61)]]
T bda_load(imm_p_MyStruct ptr, [[vk::ext_literal]] int memoryOperands);

template<typename T>
[[vk::ext_instruction(/*SpvOpStore*/ 62)]]
void bda_store([[vk::ext_reference]] T val, imm_p_MyStruct ptr, [[vk::ext_literal]] int memoryOperands);

}

template<typename T>
T bda_load(uint64_t addr)
{
    nbl::hlsl::spirv::impl::createPtrType(5349,typeid_MyStruct);

    return impl::bda_load<T>(impl::ConvertUToPtr(addr),/*None*/0x1);
}

template<typename T>
void bda_store(inout T val, uint64_t addr)
{
    nbl::hlsl::spirv::impl::createPtrType(5349,typeid_MyStruct);

    impl::bda_store<T>(val,impl::ConvertUToPtr(addr),/*None*/0x1);
}

}

template<typename T>
struct ssbo_pointer_t
{
    T deref()
    {
        return spirv::bda_load(value);
    }
    ssbo_pointer_t<T> operator+(const int64_t incr)
    {
        ssbo_pointer_t<T> retval = {value+sizeof(T)*incr};
        return retval;
    }

    uint64_t value;
};

template<typename T, typename U>
ssbo_pointer_t<U> _reinterpret_cast(ssbo_pointer_t<T> ptr)
{
    ssbo_pointer_t<U> retval = {ptr.value};
    return retval;
}

//what can you do when you can't overload operator-> (again not really appropriate, cause its not deref)
//#define MEMBER(t,m) nbl::hlsl::_reinterpret_cast<decltype(decltype(t)::m)>(t.value+offsetof(decltype(t),m))
// Another way to do it is operator-> an `ssbo_reference_t` struct and more intrinsics to construct a whole OpAccessChain via spawning `ssbo_reference_t`

}
}

struct PushConsts {
  nbl::hlsl::ssbo_pointer_t<MyStruct> addr;
  MyStruct dummy;
};
[[vk::push_constant]] PushConsts pushConsts;

[shader("compute")]
[numthreads(1, 1, 1)]
void test( uint3 DTid : SV_DispatchThreadID )
{
    MyStruct mystruct = nbl::hlsl::spirv::bda_load<MyStruct>(pushConsts.addr.value+4);
    mystruct.a = 6;
    nbl::hlsl::spirv::bda_store(mystruct,pushConsts.addr.value);

//    nbl::hlsl::ssbo_pointer_t<uint> p_a = MEMBER(pushConsts.addr.value,a);
}

if you want to make SPIR-V intrinsics more useful, try to get it to a place where things like this are possible.
I believe everything I need for this (Except for offsetof and decltype I only need for member access) is already throught about (templated custom SPIR-V types from HLSL user-types, no weird function calls to declare types) in this PR. But sharing anyway in-case I'm wrong.

@llvm-beanz Anything left?


[TOOL-2815] Nebula - handle disconnected wallet state, use connected account address in execute config

Problem solved
Short description of the bug fixed or feature added

PR-Codex overview
This PR primarily focuses on refining the chat functionality and user experience in the ChatBar and ChatPageContent components. It enhances wallet connection handling, streamlines message sending, and introduces a dialog for when the wallet is disconnected.
Detailed summary

Added e.preventDefault() in ChatBar to prevent default behavior on Enter key.
Removed unused wallet address fetching in several components.
Updated config type to allow null in Chat API.
Introduced WalletDisconnectedDialog in ChatPageContent.
Enhanced state management for showing different login pages.
Improved context filter updates based on wallet address and active chain.
Added conditional rendering for wallet connection prompts.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

#5821  👈 (View in Graphite)
main

How to use the Graphite Merge Queue
Add either label to this PR to merge it via the merge queue:

merge-queue - adds this PR to the back of the merge queue
hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.


Support instances across Win-10 virtual desktops

VSCode Version: 1.6.1
OS Version: Windows 10

Steps to Reproduce:

Open VSCode on one virtual desktop.
Create a new virtual desktop.
Open VSCode.

The result is that windows will take you back the first desktop instead of spawning a new instance on the new desktop.

Any update?

No update so far. I got the same issue too.

Please close, this is no longer happening by default

For me, the old behavior (click launch icon, switch to existing v-desktop) would be more useful, more of the time. Is there an option to toggle it back to the original behavior?


Server config location issue

On most default installation the server.conf location is /etc/openvpn. The openvpn-ui code requires hardwired a /config/server.conf directory in controllers/ovconfig.go.
This should be parametrized so default installation will become supported.
The location of the client.conf might also be a parameter.

Hi @thomas2108  it is known issue.
It is preconfigured this way historically, due to I used subdir config for server and client config files separation.
I planned to change it eventually in the ver 1.0 to announce important configuration change between the major versions, as it will demand to adjust server side configuration for all the config trees with config subdirectories.
I'll think on it, maybe will add some automation in backend to move all the files smoothly, or just announce it, so humans will aware of the changes.

So, Mr. @thomas2108 it seems I forced to change this default configuration, as there is demand from other users as well :D
I'll try to do it and rebuild all the containers accordingly.
Cheers.


Taxonomy of models

Now that we're building up  a collection of models I believe a taxonomy is emerging.
These models all have the same interface and behavior's, not suggesting any code/spec changes, just I think a language is emerging, I think @srini1978 was discussing this on a call recently as well.
Import Model - A type of model that queries another platform imports observations from another platform, e.g. like the #129 which imports observations from Azure.
Enrichment Model - A type of model that doesn't directly measure some environmental impact but enriches the observation with required data for the calculation. E.g. #125 and #173 are examples of these, they are just enriching the observations with data which is used by other models downstream.
Impact Model - A model which outputs something which we perhaps is an environmental impact (we've not clearly defined what those are, perhaps worthwhile doing in the units.yaml file) e.g. #103, #121 etc.. are examples of that.
Adaptor Model - We've not created one of these yet but say an AWSLamdaModel as described in the spec, it converts observations from one unit to another so it can be used by another model (this is one way we can measure managed services) https://github.com/Green-Software-Foundation/ief/blob/dev/docs/Model Pipeline.md#modelling-managed-services
Simulation Model - Again, not created yet but we can create a model which helps simulate a chanfge to the system, like e.g. changing the instance type as described here https://github.com/Green-Software-Foundation/ief/blob/dev/docs/Model Pipeline.md#simulation
Export Model - We've not created one of these yet as well, but this is a type of model added to the end of the pipeline to export the data at that point in the pipeline to somewhere. Used perhaps for visualization, debugging, integrating into monitoring systems.
There are no action items here, just points for discssion.

Closing as obselete


Implement From for u8

Currently we have an implementation of Into for u8, if we implement
From<u5> for u8 we get the Into implementation for free.

One should avoid implementing Into and implement From instead. Implementing From automatically provides one with an implementation of Into thanks to the blanket implementation in the standard library.

ref: https://doc.rust-lang.org/std/convert/trait.Into.html

Actually, this breaks MSRV. I personally wouldn't mind if all Rust Bitcoin projects bumped MSRV to 1.41.1 but others want to keep it lower.

Why do you think it breaks MSRV? Try and From are available from Rust 1.0.0? Did you mix up this with TryFrom (which is 1.34.0)?

u8 is not from this crate and the very documentation you linked contains a whole section explaining why it's a problem :)

Oh, wait, sorry, I think it does work for non-generic types.

Yes, exactly, please disregard my previous objection


didSelectItemAt not always called

I have trouble getting didSelectItemAt called for tapped cells, or even UIButton:s added to cells. Sometimes the didSelectItemAt is called, but mostly not. Somehow it's more often called when I tap on cell edges, but it might be just a coincidence...
UIButton:s aren't tappable at all for now.
BTW I am still experimenting with the Timetable sample app.
The above happens if I use just one or two channels. Update: I confirmed that if I use the default channels
    let channels = [
        "ABC", "NNN", "BBC", "J-Sports", "OK News", "SSS", "Apple", "CUK", "KKR", "APAR",
        "SU", "CCC", "Game", "Anime", "Tokyo NX", "NYC", "SAN", "Drama", "Hobby", "Music"]

taps seem to work ok (didSelectItemAt at least)
If I use
	let channels = [
		"ABC"]

taps do not work well; mostly only when I tap on the grid lines between cells.

Thank you for reporting and investigating. I'll figure out what happens later soon.

@zapjonny Could you try https://github.com/kishikawakatsumi/SpreadsheetView/pull/31 if you get a chance?

@kishikawakatsumi It seems like tapping on a cell works good now. Thanks!!
Still a UIButton inside a cell cannot be tapped still. I'm not sure why...

UIButton inside a cell cannot be tapped still. I'm not sure why...

I forgot to read that sentence, sorry. I'll investigate soon.

BTW I think the way UITableView allows touches to UIButton:s etc, is something that has to do with delaysContentTouches of UIScrollView.

@kishikawakatsumi so #31 seems ok for the didSelectItemAt part. Will you merge that?


Implementation of $model and $iter

Codecov Report

Merging #226 into master will increase coverage by 0.45%.
The diff coverage is 100%.

@@           Coverage Diff            @@
##           master   #226      +/-   ##
========================================
+ Coverage   99.54%   100%   +0.45%
========================================
  Files          24     24
  Lines         438    473      +35
========================================
+ Hits          436    473      +37
+ Misses          2      0       -2

Impacted Files
Coverage Δ

src/index.js
100% <100%> (ø)
:arrow_up:

src/validators/ipAddress.js
100% <0%> (+6.25%)
:arrow_up:

src/validators/macAddress.js
100% <0%> (+11.11%)
:arrow_up:

Continue to review full report at Codecov.

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


Add instructions to readme on how to add content

Need to write instructions on how to add blog posts, projects etc.

Also instructions on how to use markdown

this will be rolled into  "Onboarding" and "Contributing" overhaul effort


TestConcurrentRangeQueries: skip some more slow tests

These time out quite often during CI.

Upstream version: https://github.com/prometheus/prometheus/pull/12101

Upstream PR merged; closing.


crash: unexpected JSON token at offset

I think the tier field value is coming as string / empty and it is expecting a num type.
Using the latest SNAPSHOT build.
Can this be caused due to an older qBittorrent version (v.4.3.9)?
j9.f: Illegal input
 at k9.d.a(SourceFile:193)
 at j9.b.d(Unknown Source:73)
 at kotlinx.coroutines.flow.j.a(SourceFile:97)
 at j9.c.a(Unknown Source:13)
 at y9.v.P(SourceFile:73)
 at kotlinx.coroutines.d0.U(SourceFile:78)
 at q8.a.f(SourceFile:531)
 at q8.a.h(SourceFile:23)
 at q8.a.N(SourceFile:49)
 at q9.j.g(SourceFile:36)
 at q9.j.c(SourceFile:26)
 at q8.b.f(SourceFile:180)
 at q8.b.N(SourceFile:34)
 at q9.j.g(SourceFile:36)
 at q9.j.c(SourceFile:26)
 at q9.j.e(SourceFile:8)
 at w8.m.f(SourceFile:64)
 at w8.m.N(SourceFile:27)
 at q9.j.g(SourceFile:36)
 at q9.j.c(SourceFile:26)
 at q9.j.a(SourceFile:24)
 at q9.d.a(SourceFile:184)
 at r8.c.a(SourceFile:166)
 at lb.x.g(SourceFile:181)
 at lb.h.f(Unknown Source:12)
 at da.a.s(Unknown Source:8)
 at q9.j.h(SourceFile:69)
 at q9.j.g(SourceFile:16)
 at q9.i.s(SourceFile:23)
 at da.a.s(Unknown Source:31)
 at q9.j.h(SourceFile:69)
 at q9.j.g(SourceFile:16)
 at q9.i.s(SourceFile:23)
 at da.a.s(Unknown Source:31)
 at q9.j.h(SourceFile:69)
 at q9.j.g(SourceFile:16)
 at q9.i.s(SourceFile:23)
 at da.a.s(Unknown Source:31)
 at q9.j.h(SourceFile:69)
 at q9.j.g(SourceFile:16)
 at q9.i.s(SourceFile:23)
 at da.a.s(Unknown Source:31)
 at q9.j.h(SourceFile:69)
 at q9.j.g(SourceFile:16)
 at q9.i.s(SourceFile:23)
 at da.a.s(Unknown Source:31)
 at q9.j.h(SourceFile:69)
 at q9.j.g(SourceFile:16)
 at q9.i.s(SourceFile:23)
 at da.a.s(Unknown Source:31)
 at q9.j.h(SourceFile:69)
 at q9.j.g(SourceFile:16)
 at q9.i.s(SourceFile:23)
 at da.a.s(Unknown Source:31)
 at kotlinx.coroutines.l0.run(Unknown Source:102)
 at android.os.Handler.handleCallback(Handler.java:942)
 at android.os.Handler.dispatchMessage(Handler.java:99)
 at android.os.Looper.loopOnce(Looper.java:201)
 at android.os.Looper.loop(Looper.java:288)
 at android.app.ActivityThread.main(ActivityThread.java:7898)
 at java.lang.reflect.Method.invoke(Native Method)
 at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
 at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
 Suppressed: kotlinx.coroutines.j0: [x1{Cancelling}@26bf20d, Dispatchers.Main.immediate]
Caused by: db.j: Unexpected JSON token at offset 92: Expected numeric literal at path: $[0].tier
JSON input: .....um_seeds":0,"status":2,"tier":"","url":"** [DHT] **"},{"msg".....
 at kotlinx.coroutines.d0.m(Unknown Source:32)
 at kotlinx.coroutines.d0.l(Unknown Source:34)
 at db.a0.o(SourceFile:62)
 at db.a0.p(Unknown Source:12)
 at db.a0.j(Unknown Source:221)
 at db.x.m(Unknown Source:2)
 at qa.p.F(Unknown Source:5)
 at nb.h0.e(SourceFile:84)
 at db.x.v(SourceFile:67)
 at qa.p.t(SourceFile:11)
 at db.x.t(SourceFile:49)
 at bb.u.k(SourceFile:8)
 at bb.a.j(SourceFile:38)
 at bb.a.e(Unknown Source:5)
 at db.x.v(SourceFile:67)
 at bb.a1.e(Unknown Source:13)
 at db.x.v(SourceFile:67)
 at cb.b.b(SourceFile:25)
 at k9.d.a(SourceFile:102)
 ... 62 more

Very annoying, thanks for the report.  Looks to have been reported to qBittorrent already https://github.com/qbittorrent/qBittorrent/issues/13302
Try the latest snapshot, I've added special handling for this case where it attempts to turn the string into an int or uses -1 otherwise.

Very annoying, thanks for the report. Looks to have been reported to qBittorrent already qbittorrent/qBittorrent#13302
Try the latest snapshot, I've added special handling for this case where it attempts to turn the string into an int or uses -1 otherwise.

Thanks, will check out with the latest snapshot.

Works fine now!

@DrewCarlson is the latest snapshot published on maven?

@DrewCarlson is the latest snapshot published on maven v1.0.0-beta01?

I need it so that I can publish the app on fdroid, as it doesn't support sonatype snapshot listing.

@DrewCarlson can you please publish the latest changes on maven central?
I need it so that I can publish my app on fdroid, as it doesn't support sonatype snapshot listing.

Version 1.0.0-beta02 has been published.


Is it possible to pas an argument to nix-shell --pure to use additional packages in the shell?

It would be useful to let user to use other packages, e.g. gitMinimal or gnumake at the nix-shell, while shell is pure.  Could it be passed by arguments?  And would it be still possible to re-use binary cache for huge packages like dfx and canisters?

Would it make sense to use flakes?

The usual approach is to write your own shell.nix file, and add extra packages in there. I gave an example in this discussion, let me know if you have any success.

A simpler alternative of writing shell.nix is something like below:
{ pkgs ? import <nixpkgs> { } }:
with pkgs; let
  dfx-env = import (fetchTarball https://github.com/ninegua/ic-nix/releases/download/20230508/dfx-env.tar.gz) {};
in dfx-env.overrideAttrs (old: {
  nativeBuildInputs = old.nativeBuildInputs ++ [
   # list the extra packages here
  ];
})

It uses release binary (so please first check if the particular release supports your machine architecture) instead of compiling from source (of a given revision & sha256 hash).

Can I re-use binary cache of dfx-env in my custom shell.nix then?  Because it really takes long and noticeable amount of memory to build.

Looks like next works for me, thank you:
$ nix-shell -E "

with import <nixpkgs> {}; let
  dfx-env = import (fetchTarball https://github.com/ninegua/ic-nix/releases/latest/download/dfx-env.tar.gz) {};
in dfx-env.overrideAttrs (old: {
  nativeBuildInputs = old.nativeBuildInputs ++ [
    (import ./mops.nix {})
    wasmtime
    coreutils cacert gnupg less which tree ripgrep gitMinimal gnumake
  ];
})

"

Or simpler:
nix-shell https://codeload.github.com/gist/c247945f8ef2db0aefc7b393596b4de3/zip/2b7a7c36d0321373afa93b7ce21b4687e4754791

https://gist.github.com/Pitometsu/c247945f8ef2db0aefc7b393596b4de3

FYI @nomeata and thanks for provided snippets.

And for direnv integration with the code editor of your choice:
echo 'use nix --pure --keep DIRENV_DUMP_FILE_PATH https://codeload.github.com/gist/c247945f8ef2db0aefc7b393596b4de3/zip/2b7a7c36d0321373afa93b7ce21b4687e4754791
' > ./.envrc
nix profile install nixpkgs#direnv
nix profile install nixpkgs#nix-direnv
echo 'source $HOME/.nix-profile/share/nix-direnv/direnvrc' > ~/.config/direnv/direnvrc
cat >> ~/.config/nix/nix.conf <<EOF
keep-derivations = true
keep-outputs = true
EOF
direnv allow


Minimize android app from initial screen not working

I have two scenes like below
render() {
    return <Router>
      <Scene key="root">
 	      <Scene key="Feed" component={Feed}   initial={true}  hideNavBar={true} />
 	      <Scene key="Refer"   headerTitle={Refer} gesturesEnabled={true} hideNavBar={true} component={Refer}   />
        </Scene>
    </Router>;
  }
}

When I am in Refer page and When I press back button , Its working fine and navigating to Feed page , I want app to minimize if I press back again in Feed page , but its not working

Duplicate of #2487


Calls to the createConversation return wrong payload type, invalid payload data

Version
4.7.0-111757
Describe the bug
When calling the createConversation API, such as here in the core Bot Framework Adapter, the Emulator responds with an incorrect payload.
Whereas the code expects the payload to include the new conversation id in the id field, emulator returns it in the conversationId field.
In addition, if the value returned in conversationId IS used to send messages, they do not appear in Emulator.
To Reproduce
Use the adapter.createConversation() method. The expectation is this will create a new conversation that includes the bot and the user. (Usually this means a 1:1 private message in Teams.) This is used in many proactive scenarios.
Expected behavior

Expect the emulator to return a valid conversation id in the id field of the payload
Expect the conversation id to be usable - either to result in messages appearing in the same chat tab OR preferably open a new tab automatically to contain the newly created conversation.

Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
[bug]

Related to https://github.com/howdyai/botkit/issues/1834

The payload shape can easily be changed, however, making it so that the Emulator will show the correct UI when sending messages with the supplied conversation ID is not.
The Emulator controls the flow of creating a conversation most of the time -- this case being an exception -- and so there is some heavy lifting done client-side that sets up the redux store to properly display the UI for the new conversation in addition to telling the Emulator's backend (channel) to create a record for the new conversation.
When you just hit the create conversation endpoint, the Emulator is not performing the other half of the work so the UI will not behave the way it usually does and display a tab for the conversation.

This was a side effect of the work done in #2034 . At the time I was unaware of any scenario in which an external source would be starting the conversation and so setting up the new conversation flow this way didn't seem problematic.

R9 commitment:

Expect the emulator to return a valid conversation id in the id field of the payload

We'll fix this. For:

Expect the conversation id to be usable - either to result in messages appearing in the same chat tab OR preferably open a new tab automatically to contain the newly created conversation.

This will be a larger undertaking and we will scope & prioritize.

The R9 commitment was addressed. We'll close this and tackle the larger effort in a separate work item.


Automatically toggle video suggestions to videos from creator if no videos are matching

Is your feature request related to a problem? Please describe.
Sometimes, no video suggestions are found, instead of showing that there are no suggestions, it could switch to the videos of the creator by default.

We're revamping this area soon and that should happen. It doesn't work on refresh either right?

Refreshing didn't help, I tried that, but now it works for some reason. 😅

Let me know if it happens again... we're aware of some issues with 1 of the servers, so you probably hit the bad one.


Cfb update

added fpdf
added pegasuspy

This PR is put in pending status to wait for the WDL task part to be finished.


Add support for mini zaps

Adds supports for mini zaps, currently only .3 sec zaps, which are handled by the api by setting to duration to 100 for .1 sec or 300 for .3 secs

Alternate implementation in (ebe8631)[https://github.com/TheHeadPatCat/WoLightning/commit/ebe8631a3e57554c6ad90f814b59b9b8b847ade9]


[HOLD for payment 2023-10-24] [$500] Web - App keeps both right click LHN popup and delete message popup open together

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open the app
Open any report
Focus on composer
Right on any report in LHN to open right click LHN popup
Type anything and press enter to send
Click up arrow to edit the sent message
Remove all content using backspace and click enter
Observe that app does not close right click LHN popup and opens delete popup too along with it.

Expected Result:
App should close existing open popup on opening any other popup in the app
Actual Result:
App keeps both right click LHN popup and delete popup open together
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: v1.3.74-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/115492554/5ccbf5dd-6ea5-4189-8f02-b70cf1c7f501
https://github.com/Expensify/App/assets/115492554/e52a1a16-5779-410f-b628-b2154d9d7a8c
https://github.com/Expensify/App/assets/115492554/8521de3b-5399-440e-96d4-4d9dcce00b95
Expensify/Expensify Issue URL:
Issue reported by: @Dhanashree-Sawant
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1695654750958139
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01b7d70b5aeb6fba4a
Upwork Job ID:<PHONE_NUMBER>662357504
Last Price Increase: 2023-09-27
Automatic offers:

jjcoffee | Reviewer | 27017549
Dhanashree-Sawant | Reporter | 27017552

Proposal
Please re-state the problem that we are trying to solve in this issue
App keeps both right click LHN popup and delete popup open together.
What is the root cause of that problem?
The problem is that within the PopoverReportActionContextMenu.js component, the LHN popup is not being closed before the delete message popup is opened.
What changes do you think we should make in order to solve the problem?
Within the PopoverReportActionContextMenu.js component I called the hideContextMenu function within the showDeleteModal function which makes sure the LHN popup is closed before the delete message popup is being opened:
   const showDeleteModal = (reportID, reportAction, shouldSetModalVisibility = true, onConfirm = () => {}, onCancel = () => {}) => {
        onCancelDeleteModal.current = onCancel;
        onComfirmDeleteModal.current = onConfirm;

        reportIDRef.current = reportID;
        reportActionRef.current = reportAction;

-        setShouldSetModalVisibilityForDeleteConfirmation(shouldSetModalVisibility);
-        setIsDeleteCommentConfirmModalVisible(true);
+        hideContextMenu(() => {
+            setShouldSetModalVisibilityForDeleteConfirmation(shouldSetModalVisibility);
+            setIsDeleteCommentConfirmModalVisible(true);
+        });
    };

What alternative solutions did you explore? (Optional)
N/A

Proposal
Please re-state the problem that we are trying to solve in this issue.
The LHN does not receive focus when clicking on it.
What is the root cause of that problem?
In the OptionRowLHN, default actions are prevented when the mouse is clicked.
onMouseDown={(e) => {
  if (!e) {
      return;
  }
  // Prevent losing Composer focus
  e.preventDefault();
}}

What changes do you think we should make in order to solve the problem?
We can re-enable the default actions by removing the code block above.
Results:
28324(safari).webm
28324(chrome).webm
What alternative solutions did you explore? (Optional)
If you prefer not to have this behavior, you have the option to call the hideContextMenu function within the showDeleteModal function to ensure the LHN popup is closed before opening the delete message popup.

Please re-state the problem that we are trying to solve in this issue
The LHN popup is still open after opening the delete message popup.
What is the root cause of that problem?
The root cause of the issue is in the file PopoverReportActionContextMenu.js, within the showDeleteModel function. The issue occurs because the delete modal is opened without closing it first, resulting in both the delete modal and any previously open popups remaining visible simultaneously.
What changes do you think we should make in order to solve the problem?
Add this line of code which closes LHN popup before opening the delete popup
https://github.com/Expensify/App/blob/main/src/pages/home/report/ContextMenu/PopoverReportActionContextMenu.js#L264
if (this.state.isPopoverVisible) {
            this.hideContextMenu();
     }

Video:-
https://drive.google.com/file/d/1ifmq4_JOlrPy7gMaT7ahxPTgGQuQRFMl/view?usp=sharing

@jjcoffee mind giving these proposals a review today?

Oh I'm sorry, not sure how this one slipped past me! Reviewing today!

Looks like the correct RCA here is in @astrohunter62's proposal, as we are always keeping focus on the composer when we should be defocusing since we're opening the right click menu.
It looks like this is a regression from this PR, which was attempting to ensure that the composer refocuses when clicking an already-open chat in the LHN. So, we want to keep that behaviour but right clicking LHN should lose focus from composer.
Could you update your proposal based on the above @astrohunter62? Also a side-note, can you please link to the code snippet you mention in your proposal - makes it much easier to review!
The other two proposals are decent, but miss out because of not identifying the correct RCA.
:ribbon::eyes::ribbon: C+ reviewed

@jjcoffee
I updated my proposal https://github.com/Expensify/App/issues/28324#issuecomment-1738077181

@astrohunter62 Perfect, thanks! I think code block you're proposing to remove would cause a regression from this PR though.

@jjcoffee Thank you.
If you prefer not to remove it, you can alternatively insert DomUtils.blurActiveElement(); into the onSecondaryInteraction within OptionRowLHN. However, I believe this action is more unnecessary
onSecondaryInteraction={(e) => {
    showPopover(e);
    DomUtils.blurActiveElement();  // add
}}

But I think the previous solution(https://github.com/Expensify/App/issues/28324#issuecomment-1738077181) is better than this one.

@astrohunter62 Sorry I don't see how your proposal addresses the issue in that PR. I was thinking more to limit the onMouseDown to return early for right-clicks.

@jjcoffee Did you see my alternative solution(https://github.com/Expensify/App/issues/28324#issuecomment-1746702357)?

@astrohunter62 Yes, I still don't see how it's related. Can you explain more? Did you look at the PR I mentioned?

@jjcoffee
By using e.preventDefault(); within the onMouseDown, prevent the input from losing focus when clicking on the same chat in LHN.
In my alternative solution, I don't remove it, and the composer loses focus when the Popover is displayed. This solution doesn't cause a regression from https://github.com/Expensify/App/pull/21552

@astrohunter62 Ah I get you now, thanks! I think I still prefer an early return in onMouseDown as onSecondaryInteraction runs for long presses as well as right-clicks. We can deal with this on the PR though, so you can go ahead and raise it!

The PR is ready to review. cc @jjcoffee @dylanexpensify

@dylanexpensify PR is under review.

@dylanexpensify Looks like this actually got fixed by another PR https://github.com/Expensify/App/pull/28953. Is there any compensation due in that case?

@dylanexpensify Actually that PR fixes it in a way that causes issues on tablets. Is that worth us continuing with our PR to fix do you think?

So just to update, that other PR's fix isn't really complete as beyond it not working on tablets it also doesn't refocus on the composer if clicking onto the same chat after closing the context menu (see here), which is a regression from https://github.com/Expensify/App/pull/21552. So we're proceeding with our fix here.

@jjcoffee
I sent a proposal on Upwork, but I haven't received any offer.
When can I expect an offer?

@astrohunter62 For your first job you will usually get hired on Upwork once payment is ready to be made (which happens once the PR hits production + a 7 day regression period). Then for future issues you should start automatically receiving Upwork offers as soon as you get assigned to the GH issue.

@astrohunter62 Are you able to handle the above regression?

Yes.

@jjcoffee
Can you review this code?

onSecondaryInteraction={(e) => {
    showPopover(e);
    // Ensure that we blur the composer when opening context menu, so that only one component is focused at a time
    if (DomUtils.getActiveElement()) {
        DomUtils.getActiveElement().blur();
    }
}}

@astrohunter62 Please raise a PR, I will review there.

Can I make PR?

@astrohunter62 Yes, make sure to link the regression issue as well as this one.

@jjcoffee  Can you review this PR?

Fix is merged!

@jjcoffee Hi,
When can I get an offer?

The PR that introduced the bug has been identified. Link to the PR: https://github.com/Expensify/App/pull/21552 (also https://github.com/Expensify/App/pull/28953 which attempted to fix it)
The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: https://github.com/Expensify/App/pull/21552#discussion_r1365671613 (original PR) and https://github.com/Expensify/App/pull/28953#issuecomment-1780666536 (attempted fix PR)
A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N/A - just needed more thorough testing
Determine if we should create a regression test for this bug. Yes
If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Regression test proposal

Open any report and click on the composer to focus it.
Right click on any report in LHN to open the context menu.
Verify that the composer loses focus.
Click on the same chat in LHN and verify that the composer regains focus.

Do we agree 👍 or 👎

Payment summary:

Reporter: @dhanashree-sawant $50
Contributor: @astrohunter62 $250
Contributor+: @jjcoffee $250

Please request money or apply to upwork job!

@astrohunter62 sent offer!
@dhanashree-sawant and @jjcoffee payment sent!

@dylanexpensify
I have sent my work. Could you approve it?

@jjcoffee ah I requested half back for you to refund! It was easier than sending a new offer, waiting for you to accept, etc. haha! @astrohunter62 looking now!

payments sent!

@dylanexpensify Oooh, interesting, for some reason Upwork didn't send a notification with the refund request. Refunded now!


Server Certificate for jscompress.com expired

The SSL Server Certificate for jscompress.com expired on August 29th, 2019

ty!


Add tests for robotic problems

As mentioned in #67 we are still missing unit tests for functions already merged into the master branch, one of these implementations are robotic problems.

Done by 3751b33a9572c94112341b3f21f60a88f035de98


chore(build): use latest xvfb-action version

Now that https://github.com/GabrielBB/xvfb-action/issues/10 has been merged
Checklist

[ ] Tests added / updated
[ ] Docs added / updated

Does this PR introduce a breaking change?

[ ] Yes
[x] No

@philsturgeon Kind bump?


Handle OPTIONS requests in web API

This is necessary for some clients doing cross-origin requests (even for GET). See e.g. http://stackoverflow.com/questions/22452804/angularjs-http-get-request-failed-with-custom-header-alllowed-in-cors.

(Triggered by user reports in IRC)


Deprecated function used in example.

Under IOS implementation.
viewController.PresentModalViewController(imagePicker, true);

Is used even though PresentModalViewController is deprecated.

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

ID: 22cd76be-2702-6a58-498c-a84c723d9588
Version Independent ID: 9f98549e-ff3d-5b8d-67e6-523834c4dd6d
Content: Picking a Photo from the Picture Library - Xamarin
Content Source: docs/xamarin-forms/app-fundamentals/dependency-service/photo-picker.md
Product: xamarin
Technology: xamarin-forms
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Hi @wrkettlitz
Thanks for pointing this out. I've updated the samples that use the deprecated method, and I've also updated the docs in a PR that will go live later today.


HTTPS integration is unusual

While the format and contents of the Challenge, Attestation and Response payloads look good to me, the integration of those payloads in the HTTPS schema is quite unusual, which would make its implementation more complex and, quite possibly, somewhat unreliable:

As @thomas-fossati already pointed out in #4, a GET with a payload is weird, and many web frameworks don't support it.
Using the same route /kbs/key/key_id for all payloads forces both the server and the client to first identify the nature of the payload, and then deserialize it. Most web frameworks are designed to support a single payload per route, otherwise requiring manual parsing of the body contents. This means more error-prone work on the shoulders of the devs implementing the protocol.
The use of a JSON web token for the purpose of identifying a previous successful authentication requests is significantly more complex than the usual cookie+session strategy. I understand this is done to make the KBS stateless, but in the end this brings more complexity to the server implementation than having an in-memory table of valid sessions and their cookies.
Explicit versioning on the route (i.e. /kbs/v0/key/key_id) is less error prone and more reliably than having it as a field on a JSON object.

I think something like this would be a more conventional approach (this example assumes a session/authentication is only valid in the context of a key_id):

A GET to /kbs/v0/key/<key_id> without a valid session_id cookie returns HTTP/401 Unauthorized.
A client can request a new authentication session by POSTing a Request payload to /kbs/v0/key/<key_id>/session. The server replies to this POST with a Challenge payload, possibly extended with a status and/or error field to cover cases in which the request couldn't be server for some reason (i.e., the TEE type not being supported by the KBS).

In case the server can process the request, it will also generate a new session entry, storing the parameters from Request on it, and returning an identifier referring to it to the client, as a cookie.

Using the cookie with the session id received from the server, the client can POST a Attestation payload to /kbs/v0/key/<key_id>/attest.

If the attestation succeeds, the server updates the corresponding in-memory session entry to mark it as authenticated.
The server replies with a payload containing a status and/or error field to inform the result of the operation.

If the attestation is successful, the client can issue again a GET to /kbs/v0/key/<key_id> and this time, having a cookie with a valid session_id, it will receive a Response payload.

Is there already software implementing the current KBS attestation protocol or are we still in time to introduce some changes to it?

I am very new to KBS and so this might be completely off :-)  However, if the goal is to authorise access to web resources using attestation as a "better" form of authentication, then maybe another way to achieve the objective is to extend existing protocols -- e.g., OAuth 2.0 (for the Web) and ACE (for the constrained space) -- to introduce attestation evidence as another type of identity credential.

I am very new to KBS and so this might be completely off :-) However, if the goal is to authorise access to web resources using attestation as a "better" form of authentication, then maybe another way to achieve the objective is to extend existing protocols -- e.g., OAuth 2.0 (for the Web) and ACE (for the constrained space) -- to introduce attestation evidence as another type of identity credential.

In a general context I would agree, but I'd say in this particular context the most likely scenario is that clients will only be using this schema for boot-time (or pre-boot time, in the case of SEV and SEV-ES) attestation, accessing a single type of object (a key for opening the encrypted payload). After it has booted, likely the TEE will switch to a different attestation mechanism, such as one based on a vTPM. In this case, I think trying to extend an existing protocol would probably be too expensive.
Another question is what happens when we'll want to provide a signed attestation quote to consumers of a service (Intel has proposed an HTTP variant for this, called HTTPA or to sign artefacts, but that's a completely different story.

If this is the only expected interaction, I agree with your minimalist approach.
Thanks for the explanation @slp.

@hdxia @jiazhang0 @jialez0 have you guys seen some of the recent feedback about the KBS? What is the development status? I think we should probably try to integrate some of these suggestions.

In a general context I would agree, but I'd say in this particular context the most likely scenario is that clients will only be using this schema for boot-time (or pre-boot time, in the case of SEV and SEV-ES) attestation, accessing a single type of object (a key for opening the encrypted payload). After it has booted, the TEE will likely switch to a different attestation mechanism, such as one based on a vTPM. In this case, I think trying to extend an existing protocol would probably be too expensive.

For Confidential Containers, at least, I think we are planning to use the KBS at runtime as well. We will still have just one attestation at boot, but that session will then be used to request many different confidential resources as containers are verified, decrypted, and run. Generally I'm not thinking that we'll have a vTPM in this context, but if we do, one way to consume its measurement could be to send a quote to the KBS as evidence. We would also need to provision the vTPM somehow so we'll need to think more about this, but point is I think the scope might be a little bit broader.

Those confidential resources are also serviced by KBS or by other components?
In case they are serviced by other components, I can understand the need for a signed token that can be federated. But, even in this case, I think it'd be simpler and more effective to use a session cookie for the interactions with KBS, and then have it emit a signed token when the attestation is successful including it as part of the Response payload.
I also think it'd be nice if the emission of this token is optional and must be explicitly requested by using a dedicated field in the Request payload, since it's likely some TEE use cases don't need it.

Another question is what happens when we'll want to provide a signed attestation quote to consumers of a service

One thing that has been proposed is allowing the Attestation Agent in the guest to provide the hw evidence directly to the workload. A workload could then present this to some other party such as an end user. Guest owners could then also implement their own attestation processes in a container.
In certain circumstances it might be nice to have the KBS in the loop. xIn simple-kbs we have an experimental feature where the KBC can request a signed attestation report from the KBS. simple-kbs is only for SEV(-ES) where the launch measurement is not durable, so this report feature is kind of handy. It would probably be good if we could make these ideas a little more generic and standardized.

The option of having a  KBS-signed attestation sounds really interesting. Honestly, I haven't put much thought into this because that requires adaptations in userspace and we're barely getting the guest up and attested ;-)

I think something like this would be a more conventional approach

That sounds reasonable to me. Besides the weird GET with a payload approach, I think simply using a cookie should be enough for the current KBS purpose. As long as the cookie is valid, a KBC should be able to reuse the cookie in ordre to skip the Attestation and Challenge step to request more resources from the KBS.
I'm planning to soon send an update of the KBS document, I'll try to integrate this proposal to it.

Is there already software implementing the current KBS attestation protocol or are we still in time to introduce some changes to it?

We have not seen anything yet. @jialez0 @hdxia may know more.

Those confidential resources are also serviced by KBS or by other components?

I think the KBS will fulfill future requests, although it might get some secrets from an external party. I think you're right that we don't need anything more than some kind of cookie.

Is there already software implementing the current KBS attestation protocol or are we still in time to introduce some changes to it?

I'm glad to see these constructive suggestions for KBS protocol, which is very helpful for us to optimize the remote attestation system of confidential containers.
I don't know about the current implementation progress of KBS. @hdxia is doing the implementation work. Maybe he can give some updated information about the current implementation progress.

Using the same route /kbs/key/key_id for all payloads forces both the server and the client to first identify the nature of the payload, and then deserialize it. Most web frameworks are designed to support a single payload per route, otherwise requiring manual parsing of the body contents. This means more error-prone work on the shoulders of the devs implementing the protocol.

This is reasonable to me. Putting more information in the request into the route will indeed make the implementation simpler and easier to maintain. Thanks for this proposal.

I think something like this would be a more conventional approach

That sounds reasonable to me. Besides the weird GET with a payload approach, I think simply using a cookie should be enough for the current KBS purpose. As long as the cookie is valid, a KBC should be able to reuse it in order to skip the Attestation and Challenge steps to request more resources from the KBS.
I'm planning to soon send an update of the KBS document, I'll try to integrate this proposal to it.

Is there already software implementing the current KBS attestation protocol or are we still in time to introduce some changes to it?

We have not seen anything yet. @jialez0 @hdxia may know more.

Current kbs protocol can also short circuit the Attestation and Challenge steps. So from this point, there are no differences between the existing design and new proposal.
We talk current token scheme is stateless. Essentially, the so-called "state" is the unsigned token. In session cookie scheme, it just holds the "state" in kbs side. In token scheme, we transfer the "state" with signature protection and expiration check in form of token. Right?

@slp I see the thing becomes complex rather than relaxed. More specifically, kbs becomes relaxed but kbc become complex because it is not stateless any more.
In addition, the interaction overhead increases in slow path:
[GET] request vs [POST] request  // Yeah using GET method should be fixed
          Challenge response vs Challenge response
[GET] attest vs [POST] attest
          Response (with the encrypted resource) vs Response statue
[GET] none vs [GET] requested resource
           none vs Response (with the encrypted resource)

KBS protocol using token scheme targets to support cc scenario with the considerations to support broader usage such as passport model of attestation defined by RATS arch. For example, maybe current attestation-service can communicate with kbs directly and attestation-service then communicate with kbs or simple-kbs and eventually return a token to kbs to access more external services (not all resources are hosted by kbs) authenticated by the issued token.
Also, we need to listen the opinions from kbs maintainer @hdxia , after all what I heard from @peterzcst is that the kbs will be submitted soon according to current kbs protocol. I don't oppose session cookie scheme, but we want to see more benefits from it.

I think something like this would be a more conventional approach

That sounds reasonable to me. Besides the weird GET with a payload approach, I think simply using a cookie should be enough for the current KBS purpose. As long as the cookie is valid, a KBC should be able to reuse it in order to skip the Attestation and Challenge steps to request more resources from the KBS.
I'm planning to soon send an update of the KBS document, I'll try to integrate this proposal to it.

Is there already software implementing the current KBS attestation protocol or are we still in time to introduce some changes to it?

We have not seen anything yet. @jialez0 @hdxia may know more.

Current kbs protocol can also short circuit the Attestation and Challenge steps. So from this point, there are no differences between the existing design and new proposal.

Yes, both the current design and @slp proposal allow for skipping attestation and challenge steps. But in the current design we're using a full JWT token basically for carrying the TEE public key and have the KBS use that to encrypt the symetric key it uses for the Response. That public key is something the KBS already got from the Attestation payload.
Keeping track of that (and any other KBC session related parameter) through a standard Cookie-based sessionid value seems simpler. The KBS only need to map a session id to a public key instead of deserializing a JWT to get the key.
Are there any other reasons for using a full JWT token as part of the Request payload instead of a standard HTTP cookie?

We talk current token scheme is stateless. Essentially, the so-called "state" is the unsigned token. In session cookie scheme, it just holds the "state" in kbs side. In token scheme, we transfer the "state" with signature protection and expiration check in form of token. Right?

Correct. With the current design the KBS side is stateless but we need to carry the state with every Request message. It's basically an ad-hoc scheme for letting the KBS know how to wrap the symmetric key used in the Response. AFAICT we're always going to pass the same key, the TEE public one.
Do you see use cases where the KBC would want to request the KBS to use other keys? Wouldnt that be a security concern?

KBS protocol using token scheme targets to support cc scenario with the considerations to support broader usage such as passport model of attestation defined by RATS arch. For example, maybe current attestation-service can communicate with KBS directly and attestation-service then communicate with KBS or simple-kbs and eventually return a token to KBS to access more external services (not all resources are hosted by KBS) authenticated by the issued token.

As I wrote before, I think it's possible to combine both authentication models (cookie and signed token), obtaining the best of both models.
The Request payload could be extended to indicate that the requester (KBC), in addition to authenticating with the KBS, wants to obtain a signed token from the latter. This is to avoid the overhead of forcing the KBS to generate a signed token for the case where the client won't need it (combined TEE+vTPM models, such as Confidential VMs, or smaller footprint models, such as Confidential Workloads).
Then, a new payload could be introduced to be sent by the KBS in response to a successful attestation through POST /kbs/v0/key/<key_id>/attest with the Attestation payload that, in addition to the attestation result, returns a signed token, in case it was requested and the attestation was successful.
Finally, the KBS can define the same route /kbs/v0/<key_id> with both a GET and a POST method. This is valid and supported by every web framework, triggering different code paths. The GET method would rely on a existing cookie for authentication, while the POST method would expect to receive a payload that includes a signed token.
With this schema, a KBC wanting to rely only on signed tokens would be able to obtain the secret with this interaction:

POST to /kbs/v0/key/<key_id>/session with Request

Receives Challenge as response

POST to /kbs/v0/key/<key_id>/attest with Attestation

Receives a payload with the result of the attestation and a signed token

POST to /kbs/v0/key/<key_id> with a payload including the signed token

Receives Response including the secret

...while providing a more natural HTTP workflow and simplifying the implementation of the server and the clients that only want to request a one-time attestation.

In addition, the interaction overhead increases in slow path:
[GET] request vs [POST] request  // Yeah using GET method should be fixed
          Challenge response vs Challenge response
[GET] attest vs [POST] attest
          Response (with the encrypted resource) vs Response statue
[GET] none vs [GET] requested resource
           none vs Response (with the encrypted resource)

IMHO, mixing authentication and authorization in the schema is not a good idea, but if we really need to reduce the interaction to two HTTP operations, the Request payload could be extended to include a field to indicate that the client wants to receive the secret in the reply to the POST to /kbs/v0/key/<key_id>/attest.
But I really think this should be an optional feature of the protocol that some KBS implementations may decide not to adopt. Clients can easily support for models by looking for the field that should hold the secret and issuing a GET/POST to  /kbs/v0/key/<key_id> if they find it empty.

One other advantage of the flow proposed by @slp with the KBC doing POST for the challenge consists that it could be easily extendable if the attestation is initiated by the KBS instead of the KBC.
In today's schema, the attestation is always initiated by the attestation agent because it needs to retrieve the secret in order to start the workload.
However, for other remote attestation projects (e.g keylime), the attestation flow is started by the server. For example, in order to health check the system. In this case, the KBS starts the attestation and provides the key_id of the session. If we decide to introduce the POST for the challenge, then the rest of the attestation flow remains the same as the KBC can simply reply with the POST challenge and use the key_id provided by the KBS

@slp I see the thing becomes complex rather than relaxed. More specifically, KBS becomes relaxed but KBC become complex because it is not stateless any more. KBC running inside a TEE should be more simpler.
In addition, the interaction overhead increases in slow path:
[GET] request vs [POST] request  // Yeah using GET method should be fixed
          Challenge response vs Challenge response
[GET] attest vs [POST] attest
          Response (with the encrypted resource) vs Response statue
[GET] none vs [GET] requested resource
           none vs Response (with the encrypted resource)

You're right, @slp proposal adds one more KBC message, to eventually get the resource.
Current design:
-> GET /kbs/key/key_id [Payload: Request]
<- Response [Payload: Challenge]
->  GET /kbs/key/key_id [Payload: Attestation]
<- Response [Payload: Response]

Proposal:
-> POST /kbs/key/<key_id>/session [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/key/<key_id>/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]
-> GET /kbs/v0/key/<key_id> [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

The proposal is not that different from the current design, and is closer to an idiomatic HTTP flow imho.
If we change the current design to use a POST as its first message, it would expect to get a resource back from the POST, through the HTTP response body, which is a bit weird as well.

KBS protocol using token scheme targets to support cc scenario with the considerations to support broader usage such as passport model of attestation defined by RATS arch. For example, maybe current attestation-service can communicate with KBS directly and attestation-service then communicate with KBS or simple-kbs and eventually return a token to KBS to access more external services (not all resources are hosted by KBS) authenticated by the issued token.

What would the token look like in those cases?

Also, we need to listen the opinions from KBS maintainer @hdxia , after all what I heard from @peterzcst is that the kbs will be submitted soon according to current KBS protocol.

Yes, definitely, their feedback are needed.

Yes, both the current design and @slp proposal allow for skipping attestation and challenge steps. But in the current design we're using a full JWT token basically for carrying the TEE public key and have the KBS use that to encrypt the symetric key it uses for the Response. That public key is something the KBS already got from the Attestation payload.
Keeping track of that (and any other KBC session related parameter) through a standard Cookie-based sessionid value seems simpler. The KBS only need to map a session id to a public key instead of deserializing a JWT to get the key.

Yes, both the current design and @slp proposal allow for skipping attestation and challenge steps. But in the current design we're using a full JWT token basically for carrying the TEE public key and have the KBS use that to encrypt the symetric key it uses for the Response. That public key is something the KBS already got from the Attestation payload. Keeping track of that (and any other KBC session related parameter) through a standard Cookie-based sessionid value seems simpler. The KBS only need to map a session id to a public key instead of deserializing a JWT to get the key.
Are there any other reasons for using a full JWT token as part of the Request payload instead of a standard HTTP cookie?

It is still the challenging point between stateful and stateless in web service design.
Authentication has been a stateful affair for a long time. All user details associated the session ids are stored in KBS side. Many components in TEE that requires some sort of info about the workload provider must communicate with KBS. Most of user data is centralized. In complex scenarios, it is a limit that getting data from the central KBS for operations can be troublesome. If authorization and authentication were stateless,  each operation can carry all necessary data contained in them. With stateless token scheme, we can keep the opaque of token intact but meanwhile embed arbitrary data in it. That means that getting to that data in KBS side needs no additional communication between KBS and its backend data store: the KBS only needs to decrypt the data contained in that token.
Additionally, in so-called transport model of attestation, KBC would request attestation-service directly to get a signed token and then request various external services to access the data with that token as proof for authorization. This scenario is very possible because not all resources are centralized in KBS. This is somewhat a OAuth2 scenario mentioned by @thomas-fossati .
The last point of using token scheme is that the initial design doesn't assume the transport protocol must be HTTPS. The messages defined in KBS protocol can be self-protected even without the support from transport protocol.

IMHO, mixing authentication and authorization in the schema is not a good idea, but if we really need to reduce the interaction to two HTTP operations, the Request payload could be extended to include a field to indicate that the client wants to receive the secret in the reply to the POST to /kbs/v0/key/<key_id>/attest.
But I really think this should be an optional feature of the protocol that some KBS implementations may decide not to adopt. Clients can easily support for models by looking for the field that should hold the secret and issuing a GET/POST to /kbs/v0/key/<key_id> if they find it empty.

How about to define a set of new APIs to specifically acquire the signed token instead of opt-in it in Request message?

IMHO, mixing authentication and authorization in the schema is not a good idea, but if we really need to reduce the interaction to two HTTP operations, the Request payload could be extended to include a field to indicate that the client wants to receive the secret in the reply to the POST to /kbs/v0/key/<key_id>/attest.
But I really think this should be an optional feature of the protocol that some KBS implementations may decide not to adopt. Clients can easily support for models by looking for the field that should hold the secret and issuing a GET/POST to /kbs/v0/key/<key_id> if they find it empty.

Let me quote Sameo's workflow chart:
// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/key/<key_id>/session [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/key/<key_id>/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

So if splitting the flow into two phases, it looks more reasonable, right? In addition, is it necessary to request  /kbs/key/<key_id>/session and /kbs/v0/key/<key_id>/attest with resource route path? Actually the authorization for resource access can occur in resource access phase. If so, the URI in authentication phase can be simplified to:
// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

Does it make sense to you?

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/key/<key_id>/session [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/key/<key_id>/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

So if splitting the flow into two phases, it looks more reasonable, right?

Looks good to me. We might also want to have a POST method for the resource (/kbs/v0/key/<key_id>) that receives a payload with a signed token (perhaps marking it as optional?), thus preserving the current ability to obtain and use a federated token as an opt-in feature:
> -> POST /kbs/v0/key/<key_id> [Payload: new payload including the signed token]
> <- Response [Set-Cookie: <session-id>] [Payload: Response]

In addition, is it necessary to request  /kbs/key/<key_id>/session and /kbs/v0/key/<key_id>/attest with resource route path? Actually the authorization for resource access can occur in resource access phase. If so, the URI in authentication phase can be simplified to:
// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

Does it make sense to you?

Yes, as I wrote before, I wasn't sure if the authentication/authorization was restricted to the scope of the resource, or was global to the KBS (and, potentially, some other federated services). In the latter case, dropping the resource type and resource id from the route, as you suggest, is the way to go.

I think it is a more appropriate choice to take the authentication phase as the global route of KBS, which will make the implementation of the server more clear. In this implementation mode, in order to still ensure the distinguishability of authentication on the resource scope, we can extend the Request payload message and add a field to it to indicate to KBS which resource the KBC want to access, which allows KBS to make a decision on "whether a specific KBC can access a specific resource".

// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

That looks pretty good to me. Authentication is not bound to a specific resource.

So if splitting the flow into two phases, it looks more reasonable, right? In addition, is it necessary to request /kbs/key/<key_id>/session and /kbs/v0/key/<key_id>/attest with resource route path? Actually the authorization for resource access can occur in resource access phase. If so, the URI in authentication phase can be simplified to:
// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

I think it is a more appropriate choice to take the authentication phase as the global route of KBS, which will make the implementation of the server more clear. In this implementation mode, in order to still ensure the distinguishability of authentication on the resource scope, we can extend the Request payload message and add a field to it to indicate to KBS which resource the KBC want to access, which allows KBS to make a decision on "whether a specific KBC can access a specific resource".

Or should we keep the authentication phase simple and let KBS decide which resource a KBC/Attestation evidence can access when trying to get that resource?

I think it is a more appropriate choice to take the authentication phase as the global route of KBS, which will make the implementation of the server more clear. In this implementation mode, in order to still ensure the distinguishability of authentication on the resource scope, we can extend the Request payload message and add a field to it to indicate to KBS which resource the KBC want to access, which allows KBS to make a decision on "whether a specific KBC can access a specific resource".

Or should we keep the authentication phase simple and let KBS decide which resource a KBC/Attestation evidence can access when trying to get that resource?

I agree. Fine grained authorization definitions can easily grow out of control. Sounds like one of those things that it's better to leave for a future version of the protocol. 😉

Or should we keep the authentication phase simple and let KBS decide which resource a KBC/Attestation evidence can access when trying to get that resource?

OK, it does look clearer. Although I'm not sure whether this will cause some problems in the implementation, at present, it may be a good idea.
So let me summarize the results of our current discussion. If KBC needs to request /kbs/v0/key/<key_id>, there are two flow as follows:
If KBC uses session scheme:
// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request (token: No)]
<- Response [Set-Cookie: <session-id>] [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

If KBC uses the signed token scheme:
// resource access phase
-> POST /kbs/v0/key/<key_id> [Token: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request (token: Yes)]
<- Response [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response  [Payload: Token]

// resource access phase
-> POST /kbs/v0/key/<key_id> [Token: <signed token>]
<- Response [Payload: Response]

@sameo @slp @fitzthum @thomas-fossati @jiazhang0 Right?
And, @hdxia Does this make sense to you?

Or should we keep the authentication phase simple and let KBS decide which resource a KBC/Attestation evidence can access when trying to get that resource?

OK, it does look clearer. Although I'm not sure whether this will cause some problems in the implementation, at present, it may be a good idea.
So let me summarize the results of our current discussion. If KBC needs to request /kbs/v0/key/<key_id>, there are two flow as follows:
If KBC uses session scheme:
// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request (token: No)]
<- Response [Set-Cookie: <session-id>] [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

If KBC uses the signed token scheme:
// resource access phase
-> POST /kbs/v0/key/<key_id> [Payload: Token: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request (token: Yes)]
<- Response [Payload: Challenge]
-> POST  /kbs/v0/attest [Payload: Attestation]
<- Response  [Payload: Token]

// resource access phase
-> POST /kbs/v0/key/<key_id> [Payload: Token: <signed token>]
<- Response [Payload: Response]

@sameo @slp @fitzthum @thomas-fossati @jiazhang0 Right?

That seems correct, although if we make the Cookie non optional and the token optional, then we can really have a common flow for both paths.

If KBC uses session scheme:
// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request (token: No)]
<- Response [Set-Cookie: <session-id>] [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

If KBC uses the signed token scheme:
// resource access phase
-> POST /kbs/v0/key/<key_id> [Payload: Token: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request (token: Yes)]
<- Response [Payload: Challenge]
-> POST  /kbs/v0/attest [Payload: Attestation]
<- Response  [Payload: Token]

// resource access phase
-> POST /kbs/v0/key/<key_id> [Payload: Token: <signed token>]
<- Response [Payload: Response]

@sameo @slp @fitzthum @thomas-fossati @jiazhang0 Right?

That seems correct, although if we make the Cookie non optional and the token optional, then we can really have a common flow for both paths.

I also think making the Cookie non-optional is a good idea. Supporting cookies for the client is virtually free with most HTTP client libraries and very easy to implement for the server too.
With that, both paths for the authentication phase would be the same, with the only difference that if the emission of a ticket is desired, in Request the emit_token field would be set to true (instead of false), and the token field in the Response would carry the signed token (instead of being empty).

I've just started writing a crate (kbs-types) to implement the types defined by the KBS attestation protocol in a way that can be easily consumed by Rust-based servers and clients, and found a small inconvenience with the payload format.
Currently, payload formats are defined like this:
{
  "payload_name": {
    "version": "0.1.0",
    (...other payload fields...)
  }
}

This means that, while parsing this as a JSON, we get a root object that holds a single payload_name object, and then the payload fields (Root Object->payload_name->field).
Since there are no fields outside payload_name, and the type of the payload is already defined by the route that's being serviced/accessed, I think it'd be nicer to remove the second object and just put the fields in the root:
{
  "version": "0.1.0",
  (...other payload fields...)
}

Another minor issue I've found is that the use of hyphens instead of underscores (or CamelCase) in field names means that we need to annotate some fields with #[serde(rename = "name-with-hyphens")], but this is a Rust specific issue with an existing workaround.

Well, I agree that making session and cookies non-optional, this will make the authentication process more unified. However, if so, I don't think token needs to be an optional scheme. KBS can open a resource route for token acquisition separately, that is, treat token as the resource itself and obtain it like this: GET /kbs/v0/token/. In this way, we don't need to add an instruction to enable token in the payload of ` POST /kbs/v0/auth '.
The reason why we need a token scheme is to support some scenarios of distributed services. In this way, attester can obtain a token from KBS, and then hold this token to request resources from other servers. In the future, it can even communicate directly with Attestation-Service, obtain a token from Attestation-Service, and hold the token to request a decryption key from KBS. This is what we often call the "passport model", We hope that the protocol we are designing now can be compatible with this. As I said above, we can request tokens as resources, so that we can obtain tokens through the following process:
// resource access phase
-> GET /kbs/v0/token [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>] [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/token [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

This token acquisition method will be more natural and more compatible.
@sameo @slp @jiazhang0

// resource access phase
-> GET /kbs/v0/token [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>] [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/token [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

This token acquisition method will be more natural and more compatible. @sameo @slp @jiazhang0

I think it's more elegant than an dedicated payload field, I like it. I don't mind the extra GET call for getting the token, I think the protocol clarity we get from it is worth it.

// resource access phase
-> GET /kbs/v0/token [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>] [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/token [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

This token acquisition method will be more natural and more compatible. @sameo @slp @jiazhang0

I think it's more elegant than a dedicated payload field, I like it. I don't mind the extra GET call for getting the token, I think the protocol clarity we get from it is worth it.

I like it too, thanks!

FYI, I've started writing a reference implementation of the tentative KBS attestation protocol, using the kbs-types crate, to have a better idea of how well it fits with the most common TEE attestation mechanisms: reference-kbs

FYI, I've started writing a reference implementation of the tentative KBS attestation protocol, using the kbs-types crate, to have a better idea of how well it fits with the most common TEE attestation mechanisms: reference-kbs

+1 Thanks @slp. @hdxia Could we sync with Sergio here to make sure we're not duplicating efforts?

It seems that we have reached an agreement. It is time to update the document to follow up our discussion results in this issue.
@sameo I see you mentioned in #3  that you will update the KBS protocol document, how is it going?

It seems that we have reached an agreement. It is time to update the document to follow up our discussion results in this issue.
@sameo I see you mentioned in #3 that you will update the KBS protocol document, how is it going?

@jialez0 I'm working on it.


[feature request] Please aggregate errors and report them in the end

Currently synth stops immediately when some error occurs in one of port scans. Port scans can take a long time, and rerunning them after each error only to find another one is unreasonably time consuming.
Proposed fix: maintain the list of errors, and only report them together in the end.
Thanks!

sorry, a port scan error is fatal.  It is not possible to continue.  The problem has to be fixed immediately.  It shouldn't happen on a stock tree (unless somebody commits an error) and maintainers are expected to fix errors synth detects.

sorry, a port scan error is fatal. It is not possible to continue.

If the port is a leaf port, why is the error for this port fatal for the rest of the port scan?

How is synth supposed to know that it's a leaf port?
The scan is expected to be 100% integrity.  If a flaw is found, synth can't trust anything and most stop, otherwise corrupt data will cause issues later.
It is fatal.

Just consider the rest of the scan not 100% clean after the first error, report the list of errors in the end, and ask the user to fix them and rerun.

I don't know how many ways to say it can't be done.  Certain errors cause infinite loops.
The average user can't fix it anyway.  The tree is corrupt.
The only case where this is a problem is when a port developer is testing a port they're working on, and they are the one that likely caused the bug.  How many scan errors would there be in that case anyway?


Load Balancers Should Have Editable Scheduling Parameters

Right now, load balancers (as far as I can tell) cannot be scheduled onto certain hosts like other services can. Ideally, you should be able to specify scheduling parameters for the load balancer service much like other services so that you know which IPs to configure DNS for.

This is in the next release.

Thanks, I just found the relevant change log item. I'll go ahead and close this since it's already implemented.


Discrepancy between the described data tables and the examples

In the road_events table description it refers to types_of_work as a separate table that has a foreign key reference of road_event_id to the road_events table. I noticed the same thing with the lanes table description. However, when you look at the examples lanes and types_of_work are actually nested elements of the road_events element, not some separate element that refers to road_events by a foreign key. In fact, road_event_id does not appear in either of the lanes or types_of_work elements themselves. See below for an example. If the examples are the correct way for the feed to look, then I think you could just add lanes and types_of_work to the road_events table description as type lanes and types_of_work respectively.
{      "type": "Feature",      "properties": {        "road_event_id": "67890",        "subidentifier": "State_Project_002",        "road_name": "Barrett Street",        "road_number": "I-200",        "direction": "west bound",        "beginning_cross_street": "King St",        "ending_cross_street": "Hampton Garden Dr",        "beginning_milepost": 120.10,        "ending_milepost": 121.50,        "beginning_accuracy": "estimated",        "ending_accuracy": "estimated",        "start_date": "2010-01-01T01:03:01Z",        "end_date": "2010-01-02T01:07:01Z",        "start_date_accuracy": "verified",        "end_date_accuracy": "verified",        "event_status": "completed",        "total_num_lanes": 2,        "vehicle_impact": "all-lanes-open",        "workers_present": true,        "reduced_speed_limit": 30,        "restrictions": [],        "description": "Dummy work zone",        "issuing_organization": "Testco",        "creation_date": "2010-01-01T01:01:01Z",        "update_date": "2010-01-01T01:01:01Z",        "types_of_work": [          {            "type_name": "roadside-work",            "is_architectual_change": false          }        ],        "lanes": [          {            "lane_edge_reference": "left",            "lane_number": 1,            "lane_status": "open",            "lane_type": "left-lane",            "lane_restrictions": [              {                "restriction_type": "no-trucks"              }            ]          },          {            "lane_edge_reference": "left",            "lane_number": 2,            "lane_status": "open",            "lane_type": "right-lane"          }        ]      },      "geometry": {        "type": "LineString",        "coordinates": [           [             -72.63547003269196,             42.333474551052404           ],           [             -72.63563096523285,             42.333450757565444           ],           [             -72.63599574565887,             42.333446791983405           ],           [             -72.63645708560944,             42.33349041337203           ],           [             -72.63735830783844,             42.33354593145921           ],           [             -72.63793766498564,             42.33359748392484           ],           [             -72.63901591300964,             42.33368472646276           ],           [             -72.63960599899292,             42.33373627881463           ],           [             -72.64037847518921,             42.3337997278051           ]         ]      }    }

The tables (in data-tables) detail how to structure WZED data when storing it as well as indicating the relationship between entities. The output of the WZDx feed (the GeoJSON file shown in examples) is built from the data stored in the tables but uses the relationship to nest entities. Thus the ID fields are often not needed or would simply be clutter on the feed output.


Issue#7, issue#10, issue#11

Adding Interfaces for initializing the Petri core
Adding a thread pool executor
Adding Dummy Threads for executing tasks

This change is

Reviewed 3 of 3 files at r1.
Review status: all files reviewed at latest revision, 4 unresolved discussions.

BaboonFramework/src/org/unc/lac/baboon/main/DummiesExecutor.java, line 13 at r1 (raw file):

public DummiesExecutor()

pass the pool size as constructor parameter. This way, the pool size can be equal to the tasks amount

BaboonFramework/src/org/unc/lac/baboon/main/DummiesExecutor.java, line 14 at r1 (raw file):

TimeUnit.NANOSECONDS

We may have threads waiting for long periods of time, change this to minutes or hours

BaboonFramework/src/org/unc/lac/baboon/main/DummyThread.java, line 39 at r1 (raw file):

this.topic = topic;
this.task = task;
this.petriCore = petriCore;

check for nulls

BaboonFramework/src/org/unc/lac/baboon/main/DummyThread.java, line 56 at r1 (raw file):

topic.getPermission()

what if this topic doesn't have permissions?
petriCore will throw an exception, and you will wrap it in a RuntimeException
is this expected? a topic can not have permissions?

Comments from Reviewable

Review status: all files reviewed at latest revision, 4 unresolved discussions.

BaboonFramework/src/org/unc/lac/baboon/main/DummiesExecutor.java, line 13 at r1 (raw file):
Previously, airabinovich (Ariel Iván Rabinovich) wrote…

public DummiesExecutor()

pass the pool size as constructor parameter. This way, the pool size can be equal to the tasks amount

Done.

BaboonFramework/src/org/unc/lac/baboon/main/DummiesExecutor.java, line 14 at r1 (raw file):
Previously, airabinovich (Ariel Iván Rabinovich) wrote…

TimeUnit.NANOSECONDS

We may have threads waiting for long periods of time, change this to minutes or hours

Done.

BaboonFramework/src/org/unc/lac/baboon/main/DummyThread.java, line 39 at r1 (raw file):
Previously, airabinovich (Ariel Iván Rabinovich) wrote…

this.topic = topic;
this.task = task;
this.petriCore = petriCore;

check for nulls

Done.

BaboonFramework/src/org/unc/lac/baboon/main/DummyThread.java, line 56 at r1 (raw file):
Previously, airabinovich (Ariel Iván Rabinovich) wrote…

topic.getPermission()

what if this topic doesn't have permissions?
petriCore will throw an exception, and you will wrap it in a RuntimeException
is this expected? a topic can not have permissions?

I'll create another patch for throwing an exception when trying to subscribe a Task to a topic with no permission. Happening Handlers can be executed with no permission but Tasks need permission.

Comments from Reviewable

Review status: 1 of 3 files reviewed at latest revision, 2 unresolved discussions.

BaboonFramework/src/org/unc/lac/baboon/main/BaboonPetriCore.java, line 62 at r2 (raw file):

factory = new PetriNetFactory(pnmlFilePath);

factory is a static member. Either construct it once or make it an object member

BaboonFramework/src/org/unc/lac/baboon/main/DummyThread.java, line 70 at r2 (raw file):

NotInitializedPetriNetException

this might have to be replced by PetriNetException in the future. Don't do it now though.

Comments from Reviewable

Review status: 0 of 3 files reviewed at latest revision, 1 unresolved discussion.

BaboonFramework/src/org/unc/lac/baboon/main/BaboonPetriCore.java, line 62 at r2 (raw file):
Previously, airabinovich (Ariel Iván Rabinovich) wrote…

factory = new PetriNetFactory(pnmlFilePath);

factory is a static member. Either construct it once or make it an object member

Done.

Comments from Reviewable

Reviewed 2 of 2 files at r2, 1 of 1 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Update branch + checkout tutorial + authorization model

Hi @thecodester,
can you also please change the name of the following group: https://developers.sap.com/group.abap-env-authorizations.html into Create Authorization Model with SAP Cloud Platform ABAP Environment
Thank you.
Best regards,
Merve

@mervey45 Could you please resolve the conflicts? Thank you.

Hi @MichaelCzcz ,
I updated the branch tutorial. Are those conflicts resolved now? Or what should I do in order to resolve them?
Thank you.
Best regards,
Merve

@mervey45 I am closing this PR. I could merge it myself and resolve the issues but not sure you would then be listed as author.
Please:
1: Reset your fork:
```
git fetch upstream
git reset --hard upstream/master
git push origin master --force
```

Push again to production with plugin (normal way)

Call me if you need help.


Rename /forget_password url to /forgot_password

Hold on a second, there are duplications in each and every translation :/
I'm not sure what happened. Maybe someone added a question mark after I initially made the PR, and the rebase didn't recognize it. Fixing it

@strk every file has a duplicated line.

ok, figured. The forgot_password key is currently being used as the title for the Forgot Password page,
while the forget_password key is used for the link text.
So the new commit (replacing the others) changes forgot_password to forgot_password_title and then changes forget_password to forgot_password. Should be good now.

This needs a big disclaimer in the changelog 😛

@bkcsoft you seemed less concerned in https://github.com/go-gitea/gitea/pull/862#issuecomment-279224102 ? Or is this specifically for the translation keys ?

@strk Well, people might depend on the link, so we need a changelog entry, as for the API it doesn't care 🙂

Did anyone setup that changelog/ support mechanism ?
I'd be glad to provide a changelog within this PR if that's the case
(and if so: where is it documented?)

Why we need two similar strings?

One is the link text (usually ends with a question mark: "Forgot password?")
the other is the title of the HTML page where you click the confirmation
button (thus the "_title" suffix in the new key).

LGTM except @bkcsoft 's opinion

@bkcsoft I'm ok with the changelog entry, should I add it to the current CHANGELOG, drafting the new line (and fixing conflicts as we go) ? Or we could use a [changelog:compatibility] tag in commit logs to extract later ? Or what else do you want me to do for this to be accepted ?

Put it in the Changelog under "Unreleased" (make a section at the top) and someone will take take of it 😉

LGTM

@bkcsoft section added, and squash rebased against master


Fixed tokenize_message

Fixes tokenize_message to replace aliases with the mod name (Because it didn't seem to work before)
Enables aliases for ?mod command

Example: ?mod the servant should now work

I was not able to get the discord bot working so this was just unit tested on the ?mod command. I didn't test how it affected other commands, since those require the bot to be hooked up to discord.

Should not be merged right now. Doesn't quite meet the previous specification


Use settings.yaml with svd2rust for RISC-V devices

Opening as draft as this is still incomplete, but will eventually close #297.
For the ESP32-C2 and ESP32-C3, I believe this should be relatively (or fully) complete, however it will require some review. Priority levels were stated in the TRM (though I'm not entirely sure if these should be 0- or 1-indexed). Core interrupts were taken from esp-riscv-rt, and I believe these should be correct.
The above also applies for the ESP32-C6 and ESP32-H2, though they are notably missing both the CLINT and PLIC sections in their respective settings.yaml files.
Copying blindly from https://github.com/greenlsi/e310x/pull/1, I believe CLINT should be as simple as:
clint:
  name: "CLINT"
  freq: 32768
  async_delay: false

However, I'm unsure where this frequency comes from exactly; will required some investigation.
I tried adding the following for PLIC, but encountered some issues; it's been awhile, forget what exactly, but IIRC it was due to there being no PLIC peripheral in the PAC. Again, needs investigation.
plic:
  name: "PLIC"
  core_interrupt: "MachineExternal"
  hart_id: "H0"

This changes the src/interrupts.rs file quite a bit, so I suppose additional changes will be required in esp-hal and/or esp-riscv-rt to reflect these.

doing a quick search, in case of e310, freq comes from the RTC that is clocking CLINT

unfortunately I can't find a similar diagram for C6, but very likely this is the clock source for MTIME register


Function registry

I think this is pretty far along. Some issues though:

I plan to add some more documentation.
The errors are strings, which was easiest to incorporate, but definitely not ideal. However, cleaning this up will take some thinking, so I propose we do that in a different story.

The Matcher module is fairly messy, but I think we're likely to refactor it a bit later, and it doesn't touch much of the other code. (Only two functions are exposed).
The Matcher code should ideally use a hashmap to organize and find function definitions. Now it just lists them all in one array.
This only includes a few of the distributions in the library. Later we can include the rest, but I wanted to get this in first.
There are no tests of the internals of this, though there are of course integration tests that test the functions themselves (like, normal(5,2)). It would be nice to have tests of the internals, maybe a bit later on.

Codecov Report

Merging #545 (f30de20) into develop (fbb79b2) will decrease coverage by 1.05%.
The diff coverage is 31.28%.

@@             Coverage Diff             @@
##           develop     #545      +/-   ##
===========================================
- Coverage    56.80%   55.75%   -1.06%
===========================================
  Files           45       45
  Lines         2776     2913     +137
===========================================
+ Hits          1577     1624      +47
- Misses        1199     1289      +90

Impacted Files
Coverage Δ

...c/rescript/Distributions/PointSetDist/Discrete.res
20.83% <0.00%> (-0.22%)
:arrow_down:

...cript/Distributions/PointSetDist/Distributions.res
55.55% <ø> (ø)

.../src/rescript/Distributions/PointSetDist/Mixed.res
11.53% <0.00%> (-0.09%)
:arrow_down:

...istributions/PointSetDist/PointSetDist_Scoring.res
27.77% <0.00%> (-55.56%)
:arrow_down:

...ckages/squiggle-lang/src/rescript/MagicNumbers.res
100.00% <ø> (ø)

packages/squiggle-lang/src/rescript/Utility/E.res
41.62% <0.00%> (-1.24%)
:arrow_down:

...s/squiggle-lang/src/rescript/Utility/Operation.res
35.55% <0.00%> (-0.40%)
:arrow_down:

...le-lang/src/rescript/Distributions/GenericDist.res
61.27% <15.38%> (-3.76%)
:arrow_down:

...script/Distributions/PointSetDist/PointSetDist.res
70.47% <28.57%> (-0.82%)
:arrow_down:

...g/src/rescript/Distributions/DistributionTypes.res
17.10% <33.33%> (-0.71%)
:arrow_down:

... and 13 more

Continue to review full report at Codecov.

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

This functionality will likely be changed a lot by @umuro later on, to be connected with bindings. Therefore, I care less about its testing and error messages. We can come back to this later on.


yii2-pdf  version???

yii2-pdf  version???

@huaiguoguo what about it?

@Borales do you have a yii2-pdf version ?
you yii-pdf   is very niubility ！！

@huaiguoguo no, there are a lot of similar packages from other developers,
I would recommend using this one - https://github.com/yii2tech/html2pdf