Add Azure Storage Policies

Summary of the Pull Request

Add Azure Storage Policies based on documented gaps. Please review internal doc for more details.

PR Checklist

[x] Closes Issue #xxx
[x] Code of Conduct signed. If not, go to Code of Conduct.

Validation Steps Performed

@krnese


HTTP/3 hot restart should be supported with eBPF

In #19454, software-level support was added for HTTP/3 during hot restart, in which packets are forwarded from parent instance to child instance for the duration of the hot restart handoff.
Ideally this soft support could be bypassed using eBPF filters to deliver packets to the right instance first time.
To achieve this it would be necessary to:
[ ] have the QUIC eBPF rule direct packets to the newer instance if they don't have an instance ID in the QUIC header.
[ ] have the QUIC ID generator include encoding an instance ID.
[ ] have the QUIC eBPF rule direct packets to the specified instance if they do have an instance ID.
[ ] modify the hot restart behavior that causes the new instance to not listen until the parent is shut down, to listen immediately if there is eBPF support available. (Probably in pause())

@danzh2010 for awareness (it's possible I might work on this but unlikely, and definitely not soon)


Remove Windows branding

[x] Resolves issue #1033.
[x] Code is rebased on origin/master.
[ ] Add tests that fail without your changes. (No test is added as the change is on banner, tested on Linux, windows system)
[ ] Update all relevant documentation. (not necessary)

Why would you need the copyright notice on every launch?
Tell your lawyers that Notepad.exe doesn't show me a copyright notice on every launch either.
If i want to see the copyright information (which is very rare), i can do so explicitly.


Test Code Scanning

@ScriptSlayer0
I want to test some new code scanning workflows I've put in. Is there any way you can open a pull request early. We won't make it an official release just yet, just a test.

It works well, but only analyze the syntax using pylint.

I was working for a new PR, I created a new fork thinking it was my bad creating a new bug or error. But now I know it is this new version with compression and decompression problems and I need your help to get this software fixed and working again.

Can you let me know how to reproduce the issue? What file was used?

Only run the menu.py, choose option 2
info: Generating keys...Keys generated and saved.
Traceback (most recent call last):
  File "D:\github\bivittatusDB\BivittatusDB\BDB_io.py", line 165, in ReadTable
    data = loads(decompress(unhexlify(data)).decode())
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\github\bivittatusDB\BivittatusDB\BDB_tb.py", line 46, in __read__
    self.data=self.io.ReadTable(self.table_name)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\github\bivittatusDB\BivittatusDB\BDB_io.py", line 169, in ReadTable
    raise metaclass.BDBException.ReadError(f"Error reading data from table {tablename}: {e}")
metaclass.BDBException.ReadError: Error reading data from table table1: Compressed file ended before the end-of-stream marker was reached
None
Traceback (most recent call last):
  File "D:\github\bivittatusDB\BivittatusDB\BDB_io.py", line 165, in ReadTable
    data = loads(decompress(unhexlify(data)).decode())
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\github\bivittatusDB\BivittatusDB\BDB_tb.py", line 46, in __read__
    self.data=self.io.ReadTable(self.table_name)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\github\bivittatusDB\BivittatusDB\BDB_io.py", line 169, in ReadTable
    raise metaclass.BDBException.ReadError(f"Error reading data from table {tablename}: {e}")
metaclass.BDBException.ReadError: Error reading data from table table1: Compressed file ended before the end-of-stream marker was reached

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\github\bivittatusDB\BivittatusDB\BivittatusDB.py", line 26, in load_table
    return table(self.db, self.database_name, table_name)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\github\bivittatusDB\BivittatusDB\BDB_tb.py", line 24, in __init__
    self.__read__()
  File "D:\github\bivittatusDB\BivittatusDB\BDB_tb.py", line 50, in __read__
    raise BDBException.ReadError(f"Courld not read table {self.table_name}")
metaclass.BDBException.ReadError: Courld not read table table1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\github\bivittatusDB\BivittatusDB\menu.py", line 59, in <module>
    main_menu()
  File "D:\github\bivittatusDB\BivittatusDB\menu.py", line 52, in main_menu
    if not handle_option(option):
           ^^^^^^^^^^^^^^^^^^^^^
  File "D:\github\bivittatusDB\BivittatusDB\menu.py", line 40, in handle_option
    result = action()
             ^^^^^^^^
  File "D:\github\bivittatusDB\BivittatusDB\menu.py", line 31, in <lambda>
    "2": lambda: (pause_and_clean(0), add_names_to_db()),
                                      ^^^^^^^^^^^^^^^^^
  File "D:\github\bivittatusDB\BivittatusDB\DB_manage\adding_rows.py", line 10, in add_names_to_db
    tb1 = test_db.New_table(
          ^^^^^^^^^^^^^^^^^^
  File "D:\github\bivittatusDB\BivittatusDB\BivittatusDB.py", line 53, in New_table
    return self.load_table(name)
           ^^^^^^^^^^^^^^^^^^^^^
  File "D:\github\bivittatusDB\BivittatusDB\BivittatusDB.py", line 28, in load_table
    raise metaclass.BDBException.IOError(f"Error finding table {table_name}")
metaclass.BDBException.IOError: Error find

I have found it's affecting all the example files as well. The error starts occuring in commits 660e151 (for WIN32) and d586724 (for UNIX). It seems like our update in BivittatusDatabase was not as functional as expected.

It looks like we got control of the code scanning, so I'll go ahead and close this


Slow performance when parsing specific text with Griddler::EmailParser.extract_reply_body

Hello,
First and foremost thank you for creating such an awesome project for email processing.
The reason why this ticket is created is because there is a particular email that in our production system (using griddler 1.5.2) manifests really slow 80s - 150s execution times for Griddler::EmailParser.extract_reply_body depending on the machine.
Since this can be theoretically used for denial of service attacks it is preferable to hand over the script that consistently reproduces the problem in a non public channel.
Thanks for letting me know how this issue can proceed.
Regards,
Cristian

Create PR https://github.com/thoughtbot/griddler/pull/310 with a possible fix.


Assign learner TTT task membership based on code in training application

This can happen after #2379.
When we assign a learner task at a TTT event, we can assign it to a membership.  This should automatically fill in the membership associated with the code in that learner's TTT application.  We should still have the option to remove that associated membership.

From discussion with ITT: ideally there should also be a way to assign memberships to tasks automatically during bulk matching (i.e. select trainees with different codes, match them to a training, and AMY takes care of matching the membership up).
This expands the scope of this task a bit, but it should be possible (especially since we added a bulk error handling pattern in #2471)

Update to the bulk matching thoughts - this would actually go best with a feature like #2562. Currently, it wouldn't bring much benefit, as you still need to search for individual attendees to match them to a training anyway.


Providing Personalized Recommendations on the basis of results #20

I have added personalised message for each detail. All of these messages will change for each particular input according to what is appropriate.
for eg - if Blood Pressure input is > 130  the high blood pressure message will be there, So on for each input
If diabetes is detected they will be given an option to know more about the disease, and if not detected then they can know how to prevent it - all with the blue button displayed at the bottom.

Thank you for submitting your pull request! 🙌 We'll review it as soon as possible. In the meantime, please ensure that your changes align with our CONTRIBUTING.md. If there are any specific instructions or feedback regarding your PR, we'll provide them here. Thanks again for your contribution! 😊

Hi @BamaCharanChhandogi Please revert to my PR

Hi @BamaCharanChhandogi Please revert to my PR

What happens?

What happens?

I just want to know if it will be merged or not.

I have reviewed it. please make the changes. After changes, I could merge.

@BamaCharanChhandogi made the required changes, Kindly check

I was a little bit busy. Now we can work on our project.
you have made a lot of unnecessary changes.

you do not have to show this log file. you can add it in the git-ignore file.

I think here you have to allow all origins.

Here, why did you add the logging command?

I was a little bit busy. Now we can work on our project. you have made a lot of unnecessary changes.

you do not have to show this log file. you can add it in the git-ignore file.

I think here you have to allow all origins.

Here, why did you add the logging command?

I will fix this and push again


IPTT exports (French and Spanish only): Capitalize the translated word for "Met"

Reported by Marco for Spanish, confirmed to be the same for French.
Issue
In our Excel exports, we are not capitalizing the translated word for "Met" in the string % Met, wherever it appears in the table header. (It's fine for English.)

Acceptance criteria
Recent progress IPTT

[x] % Met column is capitalized in Spanish
[x] % Met is capitalized in French

Target vs Actuals IPTT

[x] % Met column is capitalized in Spanish -- both LoP and individual target periods.
[x] % Met is capitalized in French -- both LoP and individual target periods.

% Met is consistently capitalized in Spanish and French.
I did notice that months are not capitalized in French, in both types of report. @camgnostic any idea if this is the preferred format for French, or if we need to capitalize those too? (We are capitalizing months for Spanish.)

After poking around a bit, it looks like the pattern is to capitalize the month in a phrase like Avril 2018.
If there were also a day in there, we wouldn't capitalize -- i.e. le 8 avril 2013.


docs: Fix broken url

Summary
if you visit https://www.smooth-code.com/open-source/xstyled/docs/responsive directly,  will go to a broken page.

Test plan

Thanks!


Fatal Error

I have encountered an error:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 147456 bytes) in C:\wamp\www\SCP\vendor\leafo\scssphp\src\Formatter.php on line 244

I juste want to report it.
Thank you

If your SCSS file requires more than 1GB of memory to compile, your SCSS file is probably too big, too complex, or has a circular import

The error appened when i made an mistake in the scss script.

@CallMarl : if you can paste a snippet here to reproduce, we'll see if we can mitigate the problem; otherwise, there isn't much to go on


Converted server back to thin, pulling this to master and development

Changes Unknown when pulling fd89f3687ff21d5bd5c792fb2df867936340330f on convert-back-to-thin into ** on development**.

Changes Unknown when pulling fd89f3687ff21d5bd5c792fb2df867936340330f on convert-back-to-thin into ** on development**.


video not working in dev1568 May 19th - was working May 11th

Videos no longer works - called from either shows or from mode slides.  (2nd slide in my attract should play welcome.mp4 video)
C:\mpf\NBX>pip install mpf-mc --upgrade
Requirement already up-to-date: mpf-mc in c:\python34\lib\site-packages
Requirement already up-to-date: mpf>=0.30.0.dev1568 in c:\python34\lib\site-packages (from mpf-mc)
Requirement already up-to-date: pypiwin32 in c:\python34\lib\site-packages (from mpf-mc)
Requirement already up-to-date: kivy.deps.sdl2-dev in c:\python34\lib\site-packages (from mpf-mc)
Requirement already up-to-date: kivy.deps.glew in c:\python34\lib\site-packages (from mpf-mc)
Requirement already up-to-date: ruamel.yaml<0.11,>=0.10 in c:\python34\lib\site-packages (from mpf-mc)
Requirement already up-to-date: kivy.deps.gstreamer-dev in c:\python34\lib\site-packages (from mpf-mc)
Requirement already up-to-date: kivy.deps.sdl2 in c:\python34\lib\site-packages (from mpf-mc)
Requirement already up-to-date: kivy in c:\python34\lib\site-packages (from mpf-mc)
Requirement already up-to-date: mock in c:\python34\lib\site-packages (from mpf>=0.30.0.dev1568->mpf-mc)
Requirement already up-to-date: pyserial in c:\python34\lib\site-packages (from mpf>=0.30.0.dev1568->mpf-mc)
Requirement already up-to-date: ruamel.base>=1.0.0 in c:\python34\lib\site-packages (from ruamel.yaml<0.11,>=0.10->mpf-m
c)
Requirement already up-to-date: Kivy-Garden>=0.1.4 in c:\python34\lib\site-packages (from kivy->mpf-mc)
Requirement already up-to-date: six>=1.9 in c:\python34\lib\site-packages (from mock->mpf>=0.30.0.dev1568->mpf-mc)
Requirement already up-to-date: pbr>=0.11 in c:\python34\lib\site-packages (from mock->mpf>=0.30.0.dev1568->mpf-mc)
Requirement already up-to-date: requests in c:\python34\lib\site-packages (from Kivy-Garden>=0.1.4->kivy->mpf-mc)

2016-05-19-12-02-26-mc-REG-CSL14843.zip

updated installation instructions to include how to download the complete codec pack so all video formats work


Add note about outdated metadata in transform_images

What changes are proposed in this pull request?
Add documentation about outdated metadata after resizing images with transform_images.
How is this patch tested? If it is not, please explain why.
Not tested. It's documentation only. Please LMK if the format is off.
Release Notes
Is this a user-facing change that should be mentioned in the release notes?

[x] No. You can skip the rest of this section.
[ ] Yes. Give a description of this change to be included in the release
notes for FiftyOne users.

What areas of FiftyOne does this PR affect?

[ ] App: FiftyOne application changes
[ ] Build: Build and test infrastructure changes
[ ] Core: Core fiftyone Python library changes
[x] Documentation: FiftyOne documentation changes
[ ] Other

Before we merge, could you add this note to the other methods in this module that take a sample_collection as input and could resize the images/videos?

Yes of course.

@brimoor
I don't see any public methods that take in a collection and would potentially resize the images. Is your request about another module or about private methods?

@brimoor
I don't see any other public methods that take in a collection and would potentially resize the images. Is your request about another module or about private methods?

Ah my bad, I was thinking of the fiftyone.utils.video module, which has an analogous method for transforming videos.

All right then. LMK if you require any changes.

@willyd all set, thanks for the contrib!


enh(JavaScription): refactor doubly link list

PR Checklist:

[x] My submission is formatted according to the guidelines in the contributing guide
[x] My addition is on refer on the language README.md file
[x] My addition does not have a spelling problem
[x] My submission has a proper and user-friendly description of the algorithm
[ ] My submission has the time complexity of the algorithm
[ ] My submission has sample input-output of the program (NOT FOR PYTHON)

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[ ] New algorithm
[ ] Optimization in previous algorithms
[ ] Code style update
[x] Refactor
[ ] Documentation
[ ] Other, please describe:

Briefly describe the changes in this PR

Reference Issue : #628
What does this implement/fix? Explain your changes?
This PR refactors doubly link list in javascript, to accurately reflect the instance of DLL.
Please refer the Issue no. mentioned above for any additional details regarding the same.
Other information:

None

Hi @underager,
Did you remove all console.log?

@ming-tsai Sorry about that, I hope the latest commits takes care of that.


FEA Add SentenceEncoder

Reference
https://github.com/skrub-data/skrub/issues/1047
What does this PR propose?
This PR wraps the SentenceTransformers library, in the same fashion as ragger-duck and embetter does.
Following the good empirical baselines of arxiv.org/abs/2312.09634, this PR also proposes to:

Add a PCA within the estimator, controlled by a n_components parameter. This also allows the class to stay consistent with the other skrub encoders and perform HP tuning more easily. Following the paper, we set n_components=30 by default.
Add a normalization option, with a default "l2". This simplifies cosine distance to dot products and brings embeddings as comparable features to distance-based estimators (e.g., NearestNeighbors). This is useful when other normalized features are used (fuzzy joining).

What the SentenceEncoder does not:

perform weights or embedding quantization (kept for later research)
set torch threading, which doesn't interact well with joblib and raises an error if called twice.
choose a different embedding Pooling scheme (only mean pooling is implemented in SentenceTransformer)

See the implementation of the paper for more details.
Todo in another PR
Enriching an existing example from skrub with the SentenceEncoder.

Pixi is extremely annoying. It has negative returns on productivity as far as I am concerned.

OK, so it seems that we would be able to make the CI works with sentence-transformers=2.X. Basically, the latest release have not been created on conda-forge but I'm trying to work something out: https://github.com/conda-forge/sentence-transformers-feedstock

This CI effort is worth a couple of 🍻

This CI effort is worth a couple of 🍻 (I still don't get how people deal with the DL stack without being an expert).

Wouhou! I'm buying the first round 😉

There are a lot of codecov warnings on the _sentence_encoder.py file, but this is a display bug; the coverage is close to 100%.

We will be able to remove torchvision from the optional dependency once @glemaitre PR on conda forge is merged. Having a dep on torchvision is not detrimental for this POC, though.

I also wonder about pickling. maybe we should not store the model in an attribute but only store the name, and reload the model as necessary? or if we are worried about loading it many times we can cache it in an attribute that does not get pickled and repopulate the cache when necessary

cache it in an attribute that does not get pickled

this can be done by defining __getstate__ as shown here

here is a toy example with functools.cached_property
encoder.py
import functools

class Encoder:
    def __init__(self, name):
        self.name = name

    def transform(self, x):
        return self._estimator(x)

    @functools.cached_property
    def _estimator(self):
        print(f'loading {self.name}')
        return lambda x: f"{self.name}({x})"

    def __getstate__(self):
        state = self.__dict__.copy()
        if '_estimator' in state:
            del state['_estimator']
        return state

usage
>>> import pickle

>>> import encoder

>>> e = encoder.Encoder('supermodel')
>>> print(e.transform(7))
loading supermodel
supermodel(7)

the model is only loaded once

>>> print(e.transform(8))
supermodel(8)

pickling works

>>> s = pickle.dumps(e)
>>> e1 = pickle.loads(s)

after unpicling we reload the model

>>> print(e1.transform(9))
loading supermodel
supermodel(9)
>>> print(e1.transform(10))
supermodel(10)

the `_estimator` itself could not be pickled

>>> pickle.dumps(e._estimator)
Traceback (most recent call last):
    ...
AttributeError: Can't pickle local object 'Encoder._estimator.<locals>.<lambda>'

TextEmbedding is nice, the only issue is vectors and embeddings are close concepts, so people might not understand its difference from other string-based encoders like MinHash. What about LLMEncoder?
Maybe DeepEncoder? I think if we put "LLM" in the name some users will think they can only use it if they have a big GPU

HuggingFaceEncoder would probably be more explicit

I also wonder about pickling. maybe we should not store the model in an attribute but only store the name, and reload the model as necessary? or if we are worried about loading it many times we can cache it in an attribute that does not get pickled and repopulate the cache when necessary

Why are you concerned about pickling? Note that loading using names wouldn't work for local models in another context. For example, if a user fine-tunes a sentence-transformer and gives the local path to the SentenceEncoder, pickling the SentenceEncoder and unpickling on, e.g., a remote server would fail because the model weights aren't there anymore. Users would have to ship the weights along with the pickle object and make sure the versions are correct, which is a bit burdensome.

I typically have a rule to never introduce a major feature without a corresponding example. I find that writing the example helps so much finding usability improvements.

Downloading the weights might be a bit slow though.

we can use the circleci cache so that downloading models does not happen often (if/when that turns out to be a problem)

Note that loading using names wouldn't work for local models in another context.

yes that's true, I was assumign the main use-case would be to use a pre-trained model directly from the huggingface hub. the reason I wonder about pickling is (i) model size: I imagine we might end up with quite a few variants of a skrub pipeline, or fitted models for different splits etc., but all of them using the same hugging face model, so including a copy of it in each pickle might not be optimal. but most importantly (ii) if the model has its weights on a gpu, what happens when we pickle it and unpickle on a machine that does not have the same device? if we get an error that could be a problem. the problem is we don't have a way to check this in the CI because the runners don't have a gpu. I'm also ok with saying we will investigate this further in another issue. still I would at least add a test to check that pickling and unpickling in the simple case (same machine, cpu, the only setup we have in the CI) works

Regarding loading, pickling, and memory usage, have you considered if this is a case for a Borg pattern (refs: https://www.oreilly.com/library/view/python-cookbook/0596001673/ch05s23.html https://stackoverflow.com/questions/1318406/why-is-the-borg-pattern-better-than-the-singleton-pattern-in-python )?

Thanks for the reference! If I understand correctly, this pattern could help maintaining the same state accross different instances, but I wonder how that could help in terms of memory. Say I have a shared model accross different instances, if I run them parallel I guess the RAM consumption will still explode, right? I mean, I have to bring the matrices somewhere in memory to perform my parallel forward passes. I don't see how this could help with pickling, however. @jeromedockes WDYT?

I don't see how this could help with pickling, however. @jeromedockes WDYT?

Indeed my question was not really about memory usage or sharing state between objects but rather whether the model weights should be included in the pickle file. (i) if yes, then it cannot be unpickled in a machine that does not have the same device (without taking extra steps, AFAIK, I may very well be mistaken on this one), and the pickle may be much bigger than it needs to be. for example I can see several skrub/scikit-learn pipelines re-using the same sentence encoder model (ii) if no, then it cannot be unpickled on a machine that does not have a copy of the sentenceencoder or a way to download it from the huggingface hub.
So neither option is perfect, we have to guess which is least likely to bother many users (and possibly add a parameter to let the user choose, in this pr or a later one)

Last piece missing: updating the encoder example

@GaelVaroquaux, I'd like to merge this PR now and, instead of adding a separate example, include the example in the current GapEncoder one in a separate PR.
The goal would be to compare the TextEncoder, MinHashEncoder, and perhaps some LSA as well, using the toxicity dataset that Jovan shared yesterday. It's a small text dataset (about 1000 entries), but I think it’s a good choice to illustrate the tradeoff between the TextEncoder's computation time and performance.

I'd like to merge this PR now and, instead of adding a separate example, include the example in the current GapEncoder one in a separate PR.

I would like to have a hard rule that no major feature gets merged without being in at least one example. In my experience this is good practice.

Okay, but I have to raise awareness that adding the dataset plus revamping the example might create a big PR and delay its merging.

Fair enough, but my experience is that often going through the process of the example forces to rethink the functionality and thus is really useful.
As long as we don't have the example, we're not sure that it's ready for the user.
Thanks!!
On Oct 16, 2024, 14:48, at 14:48, Vincent M @.***> wrote:

Okay, but I have to raise awareness that adding the dataset plus
revamping the example might create a big PR and delay its merging.
--
Reply to this email directly or view it on GitHub:
https://github.com/skrub-data/skrub/pull/1077#issuecomment-2416748486
You are receiving this because you were mentioned.
Message ID: @.***>

going through the process of the example forces to rethink the functionality and thus is really useful.

Got it, I like this point of view, it sounds healthy indeed!

screenshot from the rendered example :sweat_smile: :

Ping @jovan-stojanovic :)

@GaelVaroquaux can we merge this one?

I'm having a look right now. I played with the example on my computer. It's really cool
I've created a small PR to your branch here: https://github.com/Vincent-Maladiere/skrub/pull/1
If you're happy with it, can you merge it please?
Also, there is a conflict with main, which means that we cannot merge

Nice!!! thanks @Vincent-Maladiere ! very exciting -- let's try to release it soon :) :rocket:

Very exciting indeed! Bravo!

Darn, we have a build failure on circleCI on main:

I'm restarting the build.

Yes indeed. It fails reliably. I fear that it might be related to the PR: some nasty interaction between examples.
We'll need to bisect to know whether it's related to the dependencies that are being installed, or the code that is being run. I've created an issue to track this: https://github.com/skrub-data/skrub/issues/1143

Memory issues?

I can try to bisect on this tomorrow!


Debugging UI extension headers via Dear ImGui

This PR adds optional debugging UI extension headers (or rather: currently only one for sokol_gfx.h called sokol_gfx_imgui.h).
sokol_gfx.h gets a new API function to install callback functions for tracing the public sokol_gfx.h API calls.
TODO:

[x] in sokol_gfx_imgui.h: add the error callback functions to the frame capture
[ ] write proper usage documentation in sokol_gfx_imgui.h
[ ] add a README.md to the imgui subdirectory, which generally explains how to use the debug UI headers
[x] sokol_gfx.h: disable trace hook code by default, enable via config define, and wrap the hook calls into a macro.

@floooh Thanks for this work! I was reading your code modifications when I though about its effect when no trace hooking is installed. There is a total of 72 if (_sg.hooks.*) conditions with some of them that can be repeated during a pass. The cost of these conditions are negligible when no trace hooking is installed, but I was wondering if we can have a way to discard them completely. You may want to use the tracing tool in development mode, but discard any trace of it in production mode.
What about the possibility to include the trace code only when a macro is defined? For example
#if defined(SG_HOOK_ENABLED)
if (_sg.hooks.query_feature) {
         _sg.hooks.query_feature(f, res, _sg.hooks.user_data);
     }
#endif

The code above may be simplified by another macro.
SG_HOOK(query_feature, f, res);

The definition of SG_HOOK could be like below.
// NOT TESTED
#if defined(SG_HOOK_ENABLED)
#define SG_HOOK(fn, ...) \
  if (_sg.hooks.fn) { \
    _sg.hooks.fn(__VA_ARGS__, _sg.hooks.user_data); \
  }
#else
#define SG_HOOK(fn, ...)
#endif

Hmm, yeah, but I'm tending more towards a single "all or nothing" macro. Not sure yet whether default would be hooks enabled or disabled. I'll sleep over it ;)

Ok, I made up my mind :)
First, it seems all compilers support variadic macros, at least according to godbolt, which only seems to go have VS2017, I'll check on VS2015 too, but it looks like it's ok to use them in headers.
So basically, how you suggested, trace hooks are disabled by default and must be enabled (the public API declaration will remain the same though, but the implementation code will be removed), and I'll wrap the call to the hooks in a variadic macro.
Thanks for the suggestion :)

Ok, trace hook code is optional now, off by default, and the callback invocations are in a macro (see 23aadb04853add02ecda47f88f7f2fb1e15a1249)


[Language API 2022-04-01-Preview]Conversation API Async - Issue Resolution Detection and Transcription PII

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific langauge SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

Could you retarget this PR to the branch dev-cognitiveservices-Language-2022-04-01-preview. Seems there's two. I'll also start a thread internally to get this cleaned up. Ideally, we only want one target branch for the cognitiveservices/Language RP.

The folder should be changed to 2022-04-01-preview

reverting "inputModality" to "modality" as we need consensus between custom Conversation team and us regarding this. I will have a separate PR for handling that

@JeffreyRichter @johanste the breaking change to make error required is expected and will keep happening until the next GA is published (for May, so soon), and these Avocado errors are expected given Language is a single, pseudo-RP that won't always contain every sub-service like QnA here:

@bidisha-c there's a new Avocado error since you made some refactoring. This line needs to have "common.json" removed since it's now located within the same file.

@lmazuel @mayurid re: my comment, since this is targeting a release branch do we need to wait for breaking change approval, given this exact change has been approved for other PRs for the same reason as well? Or can you help merge this since there's expected validation errors and I can't merge myself.

@JeffreyRichter @johanste the breaking change to make error required is expected and will keep happening until the next GA is published (for May, so soon), and these Avocado errors are expected given Language is a single, pseudo-RP that won't always contain every sub-service like QnA here:

/cc @lmazuel @mayurid

OK, so you want me to approve this now and you'll keep reminding me that it's OK to approve as changes keep happening?

OK, so you want me to approve this now and you'll keep reminding me that it's OK to approve as changes keep happening?

@JeffreyRichter that, or we come to an understanding among @johanste, @mayurid, @lmazuel or others who are admins on this repo to ignore the breaking change notification until we go to merge the release branch to main.

This is another "ignore things not in main" situation waiting on https://github.com/Azure/azure-sdk-tools/issues/2856

I'm OK with trusting everyone and not having to get involved personally with each change.

It may be worth pointing out that strengthening the declared constraints for properties of an output model is a false positive regarding breaking changes. It may cause client library breaking changes (e.g. nullable value type -> value type), but that would probably be better handled with a per-language transform if breaking client library changes were desired.


[Feature Request] VirtualBox image with TestCaseDB pre-installed

The TestCaseDB installation process is not very straightforward especially since it currently only works with a specific version of Ruby on Rails 1.9.3
Even when the project is upgraded to use the latest Rails, a VirtualBox Image with TestCaseDB pre-installed should be available.
Also the instructions for initial setup can be more detailed for users who prefer to install it manually.

Docker would be a better option.

Yep agreed on Docker !
This is what I use : http://s000.tinyupload.com/index.php?file_id=36751328365054034762
There is the Dockerfile, a run script, docker-compose.yml, A modified Gemfile (master release miss the minitest gem), apahce config and modified database.yml

@moimael Thanks for sharing. I'll look into utilizing this.

I must say the Apache configuration has https disabled since i used this container to evaluate testcasedb (we are adopting it btw :) ) but some requests in the ui still are launched in https (but not all, ... strange). So the Apache configuration must be changed to handle https to work properly.

@moimael There is a Rails configuration setting to force SSL which is what is causing the behaviour that you're seeing.

Thanks !
In the meantime you should consider adding gem "minitest-rails", "~> 1.0" to the Gemfile, without it you can't install testcasedb.

Here is a complete version with everything needed to run a testcasedb instance !
http://s000.tinyupload.com/index.php?file_id=79281711468281013515

Hi,
I have tried using this docker on my Mac but no avail; this is what I get:
Loaded plugins: fastestmirror, ovl Cleaning repos: base epel extras updates Cleaning up everything Cleaning up list of fastest mirrors  ---> 5278e6df36c7 Removing intermediate container 59192c29f9f7 Step 6 : RUN gem install bundler rubygems-update passenger  ---> Running in 36168f09cfa8 ERROR:  Error installing passenger: 	rack requires Ruby version >= 2.2.2. Successfully installed bundler-1.12.5 Parsing documentation for bundler-1.12.5 Installing ri documentation for bundler-1.12.5 Successfully installed rubygems-update-2.6.6 Parsing documentation for rubygems-update-2.6.6 Installing ri documentation for rubygems-update-2.6.6 Successfully installed rake-11.2.2 2 gems installed The command '/bin/sh -c gem install bundler rubygems-update passenger' returned a non-zero code: 1
Any suggestions on this? I have the latest version of Docker installed. Working on a linux vm on virtualbox is ok for me, but I need to know if this is a platform issue (mac) or a global ruby version issue.
Many thanks


Complete translation to C/SDL

This used to have an issue but it was closed because it was mostly not about the specifics of the current effort (due to experiments with Python/Tk etc.) the key things to note are some changes in my coding approach.

We're not scared of global variables. This is a utility, not a library, so no-one should be using this code within their separate project unless they intend to replace Embroidermodder 2. So namespace pollution is not an issue.
All code files are included directly into embroidermodder.c so the build is really simple.
We're not using CMake for building this project since if someone has all the libraries as shared objects the compilation could be a single line of shell. There is a build.sh utility to help with this, but it's far simpler than a CMake build and optional.
This project, unlike libembroidery, is focussed mainly on the data structures and configuration. em2_data.c and em2_structs.c should be a really good way of understanding the code rather than starting with what the functions are. These hold the role that XML or another markup would hold in many other GUIs.
There are three core features which all other features are subordinate to, they all use integer constants to refer to their specific behaviours:

The actuator: a function that calls the action to be taken, connecting the user interface element to a function
The widget builders: functions that constructs a widget given the data describing the toolbars, menubars, context menus etc.
The settings system: a few arrays of all the settings to allow for bulk copying when the user wants to preview a feature without applying it or loading a setting from file.

The actual design of Embroidermodder 2 remains very similar and the specifics of the C++/Qt version have been hand translated into this version. The continuity from Embroidermodder 2 (before 2022) to Embroidermodder 2 (2022) should be easy to follow once the translation is complete.

For specifics on the actuator, we have issue #282 , this is the parent issue for that one.

Also for the history of this change start with #143

Conclusions on the Lisp/scripting front.
Postscript is a language that we may have to support in libembroidery anyway since it is used to describe a lot of the existing vector graphics files out there, also we may use it to produce the pattern printouts. Postscript is also a stack oriented Turing complete computer language so we could establish a subset of it as out "shape description" mechanism for Embroidermodder.
See this tutorial for details: https://staff.science.uva.nl/a.j.p.heck/Courses/Mastercourse2005/tutorial.pdf
In exercise 9 it shows we have the ability to describe non trivial functions in this syntax:
1 2 div 1 2 div 3 sqrt mul add dup mul

Represents the expression $(\frac{1}{2}+\frac{1}{2}\sqrt{3})^2$. Since postscript is concatenative, we may represent the function $(x+\frac{1}{2}\sqrt{3})^2$ by just chopping this expression down:
1 2 div 3 sqrt mul add dup mul

Since add takes two arguments we have an incomplete lambda expression, it's just the input format is anonymous (unlike lisp). This seems like a really good reason to replace our "shape description" language with postscript (compiled into libembroidery) and remove TinyScheme.


[AUTOPATCHER-CORE] Patched rust to address CVE-2023-27477 -

[AUTOPATCHER-CORE] Patched rust to address CVE-2023-27477
Upgrade pipeline run -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=341556&view=results
AMD64 build -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=341585&view=results
ARM64 build -> https://dev.azure.com/mariner-org/mariner/_build/results?buildId=341586&view=results

Closing- handled by #5496


CPU version compilation

If I use the CPU to predict a single image, do I need to recompile the CPU version of mmdetection?And why in mmdetection 2.0)  I didn't see the changes described in #2385？

MMDetection now supports both GPU and CPU inference. No changes are needed and you do not need to recompile it.

@hellock  Thank you for your reply! Using CPU to predict can use roialign and roipool normally？

Yes it can be compiled without CUDA. Please refer to the documentation.


Release v2.2.11

I've tested web and briefly extensions:

When I'm opening the last multisig accounts it redirects my automatically to my 1st multisig account in web wallet (it's not reproducible in extensions):

https://github.com/user-attachments/assets/d69ac965-5105-46b0-8c01-81dfe4e5dfb5

when Tx is in pending status:


Dynamic output to topics by value?

I'm quite familiar at kafka, kafka connect and new with ksml.
Is there a way that output topics can be caculated by value of message (in schema), or some function?

Yes, you can use the ToTopicNameExtractor operator to dynamically route messages to a specific target topic. Is that what you are looking for?

thank you, i'll try it.


[enhancement] Cleanup Darwin-related stuff from Emacs derivation

Issue description
The new Darwin SDK framework at https://github.com/NixOS/nixpkgs/pull/346043  and the recent mpv conversion to it at https://github.com/NixOS/nixpkgs/pull/350674 leaves a room for similar improvements for the current Emacs framework.

Marking @jian-lin and @Atemu

As mentioned before, I don't have access to a mac currently. Please don't ping me about it. Thanks

I do not want to touch darwin-related work at all.  I only touched that system because I tried to not let my general improvements of Emacs infra break users on that system


Proposal: standard JWT schema and path for better JWT support

This pull request suggests a path forward for Opencast to improve JWT support and cover a wide range of use cases, while also already implementing the first step of that plan. So this PR consists of not only the git diff, but also of the description containing the full proposal. I intend to discuss this with the community, in particular also discussing this in person on the D/A/CH conference tomorrow.

Why?
There are many parties interested in better JWT support. This discussion has been open for nearly a year now, while need for this has been around for way longer. Tools like LMSs and Tobira require Opencast to disable static file authorization completely in order to work. The annotation tool might require similarly problematic workarounds. And external apps cannot properly link to the Opencast editor (granting access to edit a video). There is also interest in having a service that can serve static Opencast files without needing a database.
At elan, many clients asked us about these use cases and specifically about JWT in Opencast. The GitHub discussion thread was an attempt to get this started, but I think at this point, one simply has to start working on it.
What?
Talking to various parties, thinking about different use cases, and examining what Opencast is already capablable of, I think we should take roughly the following steps to improve JWT support. Each of these is described further down.

Define a standard JWT schema and make it work out-of-the-box in Opencast (That's what this PR does!)
Add proper way to use JWTs in SFA (static file auth)
Add ability to merge login sessions
Create service for serving static files with authorization that keeps working when Opencast is down

EDIT: see this comment for a change of priorities.
(1) Standard JWT schema
After the cryptographic verification, a JWT is just a bunch of "claims" (JSON fields). How to interpret those fields is up to the communicating services. Since there are quite a few external projects in the Opencast ecosystem (Tobira, at least 3 LMS plugins, Annotation Tool), agreeing on a standard is reasonable to avoid diverging uses of JWTs. Having such a standard also means that we can make it work out of the box, without the need for admins to write complex role mappings.
This is what this PR does. Please check the git diff to read the actual schema proposal.
I think having one standard for all use cases makes sense. One could argue that one shouldn't mix static file auth with general user authentication/authorization. But this doesn't do that. This just defines a schema in which both, or a mix of the two, can be expressed. For static file auth, one would onle specify a single "oc": ["read:e:<id>"], while for usage of Studio you would specify user info an "roles": ["STUDIO"]. For usage of the editor, you can mix both: give specific roles, but also write access to a specific event. Having use case specific JWT schemata could possibly make the JWTs for each use case smaller, but only by a a few bytes. And personally, I think this tiny overhead is acceptable in order to have only one schema.
This PR also implements this standard as ocStandardRoleMappings, so that it's not necessary anymore to write role mappings manually.
With this done, external tools can start using this standard to attach JWTs to requests. And in Opencast, we can improve support for certain use cases.
(2) JWTs in SFA
While step (1) already makes this possible, it is far from perfect since the JWT handler require a username, display name and email for sessions created by the JWT. For static file authorization, all of this shouldn't be necessary. So in step 2, we should adjust Opencast's SFA to correctly work with JWTs that do not contain user info, but just a single oc entry giving access to one event. This can also improve performance of static file serving, as in the JWT case, loading the event's ACL is often not necessary.
I tried implementing this already, but didn't come very far due to lacking familiarity with Spring security and Opencast's auth system. But I think implementation details can be done at a later stage anyway.
(3) Merge login sessions
Currently, creating a login session via JWT while another login session exists either does nothing or, if you set checkForPrincipalChanges to true, it fully replaces the other session. This is not ideal. Consider someone opening the video editor via link in Tobira for two different videos in two different browser tabs. The first session that's created grants access to one video, the second one to the second video, rendering the first editor tab broken. There are a number of other scenarios where this can lead to problems.
Session merging should merge roles between the existing and new session, so that permissions stack. Details need to be figured out.
(4) External static file serving application
The goal is to create a small program that, together with a webserver like nginx, can serve Opencast's static files, even while Opencast is down -- without disabling authorization! This external service would only support JWT authorization, as well as serving public files without requiring a JWT. But even this limited auth support can cover a wide range of use cases. If the request cannot be authorized via JWT, the service would forward it to Opencast to let it decide.
This has three main advantages:

Reducing downtime: be it crashes or updates, Opencast downtime is just a fact of life and can become quite disruptive for institutions with large data sets during updates. With this file server, we can significantly reduce the perceived downtime for most users. The vast majority of time during "Opencast usage" is spent watching a video, i.e. downloading static files. And generally, most usage is read-only. Apps like Tobira or some LMSs keep a local copy of Opencast metadata and partially keep functioning during Opencast downtimes (this was an explicit requirement of Tobira). Keeping file serving working without Opencast, means that most users won't notice Opencast being down.

Improving performance: involving Opencast (and its whole framework/stack) in file serving, makes the operation a lot slower and use up a lot more computing resources. We are talking three-digit factors or more, compared to just nginx file serving.

Stateless file serving: this would make file serving less dependent on external factors, making it easier to scale it, deploy it to servers at different locations, use external storage solutions and the like.

For this to work well, Opencast should adopt some changes to its static file URL pattern and its NFS file paths. Public files (i.e. from events that ROLE_ANONYMOUS can read) should be placed in the file system in a special way such that an external service can easily identify them. Ideally the URL pattern is also adjusted. And for protected files, it should be possible to omit the ID from the URL path, since the JWT will contain the event's ID anyway and we don't want to specify it twice. Both these techniques are commonly used by big CDNs.
Open questions

Should we skip step 2 in favor of step 4? Once we have the external service, everyone should use it instead of letting Opencast serve. It just felt correct to have this work directly with Opencast itself. Or is that just wasted work?
When and when not to load existing user data for the supplied username? Currently the JWT login handler looks up user info (including roles) in the user reference table. We should decide when that should happen, and whether only the user references should be checked.
Similarly, decide when the user session created by a JWT is stored as user reference. For static file serving, it shouldn't. For Studio, Editor and other use cases, it should. Should it be saved whenever the user information is supplied in the JWT?
Maybe use kid claim (key id) to avoid having to check multiple keys? That can happen in the far future though.

Other TODOs
Here is an unordered list of other things that still need to happen.

(in this PR) add example in security config for returning list of roles
(in this PR) stop parsing SPeL expressions on every JWT request, but only once, using the parsed representation later.
Frontends/players need to be adjusted to deal with expired JWTs. If a user stops watching a video and returns a day later (keeping the tab open), that should work.

Background info: JWTs in web servers
Webservers like nginx can be configured to verify JWTs. The important summary is that the business-logic claim validation is always deferred to some user specified, turing-complete "script". So we are not constrained by this when it comes to the design of our JWT schema.

Nginx

Built-in: https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-jwt-authentication

only in nginx commercial solution
Can use external JWKS, with configurable caching
Verifies exp and nbf
Support for custom claim validation. Logic is encoded in map of externally via auth sub requests.

https://github.com/kjdev/nginx-auth-jwt

Seems to be basically an open source version of the official stuff?

https://github.com/TeslaGov/ngx-http-auth-jwt-module

Seems to be intended for user sessions (JWT is bad for that)
Cannot use JWKS URLs
Can extract claims into variables, custom checking in nginx code. But only string claims! (no number, bool, array, object)
-> Doesn't seem that great

Apache

Seems to have only very basic module built in... dunno

It seems like many people would use their own script/server to validate JWTs. Webservers would then call into that (via auth subrequest for example) to determine whether to serve a file. And then, super custom logic is possible of course.

Next steps
I invite everyone to read this proposal and give feedback. This will also be discussed at D/A/CH starting tomorrow. My intention is to get this started soon though. I don't want this PR to bit rod for half a year. So if you want to be involved in this discussion, please do so fairly quickly. In fact, I hope that after D/A/CH we will have agreed on a general direction.

We disused this two days ago on the DACH (un)conference. We didn't have much time to really dive deep, but the main points I took home were:

Generally, the plan makes sense and there is no big blocker that I overlooked.
The static file use cases should be prioritized over the tool use case for now. Especially since for some LMS, LTI already covers the tool use case.
The tool use case requires additional thought (regarding session merging, username matching, ...). Also a good reason to first do static file auth.
Regardless of priorities, people felt that using the suggested JWT schema, which is very general and can support far more than static file auth, is fine.
The question of whether omitting ROLE_ is fine was brought up, but hasn't been discussed further since at the end of the day, this part of the schema doesn't affect anything else.

Now replying to Matthias:

In what scenario can the external service not decide based on JWTs and needs to forward requests to Opencast? I would suggest simplifying and only supporting JWT authorization for serving files. Instead of forwarding to Opencast, simply fail the request with 403.

In cases where there is an Opencast Cookie-based session (i.e. JSESSION). This would be the case if someone simply logged into the admin UI, watching videos from there, for example. Eventually, I wouldn't mind doing everything via JWT! I just didn't want to make such a bold move now already, since it would require adjusting a few apps (like the admin UI).

Public files (i.e. from events that ROLE_ANONYMOUS can read) should be placed in the file system in a special way such that an external service can easily identify them. Ideally, the URL pattern is also adjusted. And for protected files, it should be possible to omit the ID from the URL path, since the JWT will contain the event's ID anyway and we don't want to specify it twice. Both these techniques are commonly used by big CDNs.

This is tricky:

We decided at the committers meeting to store ACLs in the DB and not require a republish when changing them. However, with your suggestion adding ROLE_ANONYMOUS would require a republish. Moving files might be fast for NFS, but this is not the case for S3 as you would need to reupload files. Therefore, ideally, you would not need to move files around when changing ACLs.
Changing the path (and thus the URL) is tricky for existing installations. Changing the element URLs would mean that we need to republish every event to update the URLs in the search service. Also, you need to change the files on disk / in S3 (i.e. reupload everything). Imagine doing this as Manchester (although they don't use search IIRC)!

I would, therefore, very much like to leave files at their current location and find a solution for public vs protected files. Maybe just require ACLs to be published and read them from disk/S3 + in-memory caching in the case where no JWT is given? The fast workflow doesn't seem to publish ACLs, but schedule-and-upload does.

Mhhhh yeah, I suppose I forgot about S3 and indeed assumed doing these "moving" operations are super fast. Mh this is tricky. I suppose it would be nice if Opencast would write the ACLs to the FS somehow so that this external service can read them. But I'm afraid this adds lot of complexity and depenencies between the service and OC. I would probably suggest that for now, we treat public files just like protected files and always require a JWT. Then we can see how much overhead the JWT generation and validation is and how strongly we should add the "public file optimization". That's after all all it is: an optimization to avoid some JWT operations. We can always add it later.

Should we skip step 2 in favor of step 4? Once we have the external service, everyone should use it instead of letting Opencast serve. It just felt correct to have this work directly with Opencast itself. Or is that just wasted work?

+1 and I think this was the consensus at DACH.

I'm not sure I took that as a consensus from DACH. Not that I mind, I just don't remember having such a clear answer on it.

How should the external service look like?
We could implement it in various ways (maybe even implement it multiple times if we cannot decide on one):

Webserver plugin: JWT validation is implemented as a plugin for the webserver (e.g. nginx module, Caddy plugin, ...).
Service running next to the webserver and using something like auth_request, i.e. the webserver would send a request to the service and it would answer if the original request should be allowed or not.
Service running as proxyed server and using something like X-Accel-Redirect headers.

I have no opinion on this. I suppose the last two are close enough such that converting one to the other should be very easy. Therefore, we could simply try both and check which one performs better. I'd be also interested to see if an nginx plugin would be faster, and I even think it should be quite doable, but I feel like this would make setup for admins quite a bit more annoying. Not sure though.

JWKS
Maybe we should implement a / use an existing JWKS service. Tobira is doing this internally already (I learned), but we need a central one that services public keys for all applications that will create JWTs (LMS, Tobira, etc.).

I'm not sure I understand why we need a service for this? Every JWT source (Tobira, LMS, ...) would have its own JWKS publicly available. Opencast knows all these URLs and fetches them whenever necessary. Opencast can cache them internally however it sees fit.

👍 to everything else in your first comment

I'm not sure I understand why we need a service for this? Every JWT source (Tobira, LMS, ...) would have its own JWKS publicly available. Opencast knows all these URLs and fetches them whenever necessary. Opencast can cache them internally however it sees fit.

We currently can only configure one JWKS URL in a JWT login handler. I don't care if we want to add the ability to add a list, but I personally would still configure Opencast to only fetch from one source which lists all keys.

I'm not sure I understand why we need a service for this? Every JWT source (Tobira, LMS, ...) would have its own JWKS publicly available. Opencast knows all these URLs and fetches them whenever necessary. Opencast can cache them internally however it sees fit.

We currently can only configure one JWKS URL in a JWT login handler. I don't care if we want to add the ability to add a list, but I personally would still configure Opencast to only fetch from one source which lists all keys.

Such a federated aggregation of metadata would require frequent updates in case of key rollovers and revocations;
A list of JWKS URLs could be a simpler solution, an aggregation service would still be possible then.

@LukasKalbertodt Shouldn't this be a draft still? :thinking:

@KatrinIhler that depends on how Opencast uses "draft PRs". There are open discussions, but it's not like this PR is "not yet done". Are there any guidelines when PRs should be drafts in this repository? (Maybe lets move this discussion elsewhere tho)

Draft is basically when the author wants to prevent people from merging bc the PR is not yet ready. I thought this might be the case here but now I think I might've been wrong.

Considering the goal here, I'm going to merge this.  While this implementation likely isn't complete or perfect, it's the basis of future (funded) work and not having this done is/will be blocking that work.


Implement basic PoC for ECDSA based signing and verification of tokens

This implements a PoC of the idea outlined in: https://github.com/TheTorProject/proteus/issues/24.
To build it run:
make build-orchestrate

The suggested workflow is as follows.

Private key-pairs are generated using the orchestrate keygen command:

./bin/orchestrate keygen -f /path/to/privkey

This will generate a ECDSA keypair using NIST curve P-256 (yeah, it could have a NSA backdoor, etc., but it seems like it's the only interoperable solution if we want to not be sad when we have to write the various verification code, since ED25519 support is openssl is a weak).
The public part of the key needs to be loaded into all the ooniprobe apps that need to support orchestration.

[ ] TODO: do we want to have one master key we share? Should we have a list of keys that we provision the clients with or some PKI-like approach?

The web application will generate a JWT token and give a string to copy paste on your machine for signing it.

This can be simulated by running this python snippet:
import base64
import json
import time
print(base64.b64encode(json.dumps({"iss": "art", "exp": int(time.time()+200), "foo": "bar"})))

You will get back something that looks like this:
eyJpc3MiOiAiYXJ0IiwgImZvbyI6ICJiYXIiLCAiZXhwIjogMTUwMzU2MTg0Mn0=

Or the webapp should print out already the full command to sign it:
echo eyJpc3MiOiAiYXJ0IiwgImZvbyI6ICJiYXIiLCAiZXhwIjogMTUwMzU2MTg0Mn0= | orchestrate sign

The OONI operators will generate a signed version of the token via the sign command:

echo $BASE64TOKEN | ./bin/orchestrate sign -f /path/to/your/privkey

The ooniprobe clients need to verify that the token is signed. For PoC purposes a verify command is also implemented. It works like this:

echo $SIGNEDTOKEN | ./bin/orchestrate verify -f /path/to/the/pubkey.pub

If you did all the above steps correctly you should see something like:
TOKEN IS VALID
Check passed: true
Issuer      : art
Foo         : bar
Expiry      : 1.51355745e+09

If the token is not valid you will see something like:
ERR: TOKEN IS INVALID
Token is expired

This is superseeded by: https://github.com/ooni/orchestra/pull/44


Remove Storyshots

Release Type: Dev improvements
Fixes https://github.com/x-team/xp/issues/1900
Description
Remove Storyshots.
Checklist

[x] set yourself as an assignee
[x] set appropriate labels for a PR (In Review or In Progress depending on its status)
[x] move respective JIRA issue to the PEER REVIEW column
[x] make sure your code lints (npm run lint)
[x] Flow typechecks passed (npm run flow)

[ ] Snapshots tests passed (npm run jest) -- special attention to this one (see the note below)

[x] check cleanup tasks (https://github.com/x-team/xp/labels/cleanup) and take a suitable small one (if exists) in a related area of the current changes
[ ] component's documentation (.stories.js file) is changed or added accordingly to reflect any new or updated use cases and/or debug cases

[ ] if any snapshots have been changed, verify that component still works and looks as expected and update the changed snapshot -- special attention to this one as well (see the note below)

[x] once finished with all the changes, you run npm run build command and committed changed files to the branch
[x] manually tested the app by running it in several different browsers (Firefox, Chrome, Opera, Safari, MS IE/Edge, etc.) and checked nothing is broken and operates as expected!

Note: I had to remove the jest test from npm t because we still don't have any test. But I kept the Jest lib and all its configurations because I believe we'll want to have tests soon. When that time comes we just need to append the npm run jest back to the npm test script.
><EMAIL_ADDRESS>jest /Users/bernardo/Sites/x-team/xp-ui
> jest --roots=src

No tests found
In /Users/bernardo/Sites/x-team/xp-ui
  184 files checked.
  testMatch: **/__tests__/**/*.js?(x),**/?(*.)+(spec|test).js?(x) - 0 matches
  testPathIgnorePatterns: /node_modules/ - 184 matches
Pattern:  - 0 matches
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>jest: `jest --roots=src`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>jest script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      /Users/bernardo/.npm/_logs/2019-11-07T11_37_39_461Z-debug.log
npm ERR! Test failed.  See above for more details.

Steps to Test or Reproduce

Run npm t
Observe that there's no Storyshot tests anymore

Impacted Areas in Application
npm t

I believe the conflicting file should be just removed.

@nicksp this branch was rebased 👍

Hey @bernardodiasc Please notice I updated PR template to reflect "disabled" commends for the time being.https://github.com/x-team/xp-ui/pull/472/commits/49309919c4b67d7f642fcd3741229ddf4cd20864


Projects: Organization templates

Summary
Users in organizations will be allowed to create project templates that others in their organization can use when creating new projects.
Intended Outcome
Teams and users often want to be able to share out and learn best practices in how they set up and use their projects to plan and track their work. Projects templates allow teams to create consistency in their projects with standardized working patterns and structures, share best practices among teams and from other users, and reduce manual effort to get started with a new project.
How will it work?
Users will be able to toggle a project to become a template at the organization level from the project settings page, or copy a project into a template.

Once a template is created, a user can open the template to make adjustments, and select Use this template to create a new project using the template.

The template library is also available when creating a new project, so you have a preview of what will be included in the project.

🚢 This has shipped: https://github.blog/changelog/2023-05-25-github-issues-projects-may-25th-update/#🎨-project-templates-for-organizations.
Leaving open to track for GHES release!

This has shipped with GHES 3.10: https://github.blog/2023-08-29-github-enterprise-server-3-10-is-now-generally-available/


Show application reference in the list command

- What I did
Added a REFERENCE column, showing the registry reference, or "local" if the application was installed from a local CNAB bundle.
⚠ On top of #510
- How to verify it
$ docker app install slubecki/example:v1.0.0 --name toto
Creating network toto_default
Creating service toto_hello
Application "toto" installed on context "default"

$ docker app ls
INSTALLATION APPLICATION          LAST ACTION RESULT  CREATED    MODIFIED  REFERENCE
simple       simple (1.1.0-beta1) install     failure 16 hours   16 hours
toto         hello-world (0.1.0)  install     success 11 seconds 8 seconds docker.io/slubecki/example:v1.0.0

- Description for the changelog

Show application reference in the list command

- A picture of a cute animal (not mandatory but encouraged)

+1 for empty string instead of local

Superseded by #517

"local" removed and forced push


Updated the expected messages for post experiments

Updated the expected messages for post experiments

In general I would suggest keeping the test changes and the functionality changes in two different PRs. That will help us track the changes better and also easier to pinpoint issues.

Tested the fix, above mentioned issues are fixed now.


Add SolStar token.

[x] I will not ping the Discord about this pull request.

Hello Solana team!  I hope you're all doing well :) we've created our mainnet token for SolStar. Please see below and the attached PR. Thanks!
Please provide the following information for your token.
Please include change to the src/tokens/solana.tokenlist.json file in the PR
At minimum each entry should have

Token Address:  Done.
Token Name:  Done.
Token Symbol:  Done.
Logo:  Done.
Link to the official homepage of token: Done.
Coingecko ID if available (https://www.coingecko.com/api/documentations/v3#/coins/get_coins__id_):  Not yet applicable.

please store logo in this repo under assets/mainnet/

Hey Bartosz, thanks!  Uploaded our image to the assets folder and changed our image link to point to it.  Let me know if there's anything else we need to do to get this merged.

Thank you so much Bartosz!

Very good 👍


The Background of My VS Code changed to transparency

Type: Bug
Hello.
I was doing some gradle changes in my Flutter Project, and suddenly my VS Code turned to transparency, like I can see the back apps clearly in my VS Code editor, Please Help
VS Code version: Code 1.81.1 (6c3e3dba23e8fadc360aed75ce363ba185c49794, 2023-08-09T22:22:42.175Z)
OS version: Windows_NT x64 10.0.22621
Modes:

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz (8 x 2112)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
7.84GB (0.36GB free)

Process Argv
--crash-reporter-id 23ed1f83-5b5d-4218-8339-7cd80478396a

Screen Reader
no

VM
0%

Extensions (47)

Extension
Author (truncated)
Version

doxdocgen
csc
1.4.0

dart-code
Dar
3.70.0

flutter
Dar
3.70.0

bloc
Fel
6.6.4

vscode-pull-request-github
Git
0.70.0

todo-tree
Gru
0.0.226

better-cpp-syntax
jef
1.17.2

rainbow-csv
mec
3.7.0

python
ms-
2023.14.0

vscode-pylance
ms-
2023.8.20

jupyter
ms-
2023.7.1002162226

jupyter-keymap
ms-
1.1.2

jupyter-renderers
ms-
1.0.17

vscode-jupyter-cell-tags
ms-
0.1.8

vscode-jupyter-slideshow
ms-
0.1.5

remote-containers
ms-
0.304.0

remote-ssh
ms-
0.102.0

remote-ssh-edit
ms-
0.86.0

remote-wsl
ms-
0.81.0

cmake-tools
ms-
1.15.31

cpptools
ms-
1.17.2

cpptools-extension-pack
ms-
1.3.0

remote-explorer
ms-
0.4.1

vsliveshare
ms-
1.0.5877

vsliveshare-audio
ms-
0.1.93

indent-rainbow
ode
8.3.1

java-extension-pack-jdk
Ple
2023.811.0

java
red
1.21.0

vscode-xml
red
0.26.1

LiveServer
rit
5.7.9

glassit
s-n
0.2.6

trailing-spaces
sha
0.4.1

code-spell-checker
str
2.20.5

cmake
twx
0.0.17

errorlens
use
3.13.0

intellicode-api-usage-examples
Vis
0.2.7

vscodeintellicode
Vis
1.2.30

vscode-boot-dev-pack
vmw
0.2.1

vscode-spring-boot
vmw
1.48.0

vscode-gradle
vsc
3.12.7

vscode-java-debug
vsc
0.53.0

vscode-java-dependency
vsc
0.23.1

vscode-java-pack
vsc
0.25.13

vscode-java-test
vsc
0.39.1

vscode-maven
vsc
0.42.0

vscode-spring-boot-dashboard
vsc
0.13.1

vscode-spring-initializr
vsc
0.11.2

(2 theme extensions excluded)

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30410667
py29gd2263:30792226
vscaac:30438847
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
vsccc:30803844
3biah626:30602489
f6dab269:30613381
showlangstatbar:30737416
03d35959:30757346
pythonfmttext:30731395
pythoncmv:30756943
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
gsofa:30804715
pythonnosmt12:30797651
pythonidxptcf:30805731
pythonnoceb:30805159
dsvsc013:30795093
dsvsc014:30804076
diffeditorv1:30812748

/confirmPlease

Please perform the following three tasks to diagnose the root cause of the issue:

[ ] 1.) Disable Extensions

Select View and pick Command Palette...
Run Developer: Reload With Extensions Disabled
👉 See if the issue reproduces

[ ] 2.) Disable Configuration

Select View and pick Command Palette...
Run Profiles: Create a Temporary Profile
👉 See if the issue reproduces

[ ] 3.) Try VS Code Insiders

Download VS Code Insiders
Install and Run it
👉 See if the issue reproduces

Then pick one of the three resolutions depending on which step has helped:

Disabling my Extensions helped
Please run the command Start Extension Bisect and follow the instructions to find the extension that is causing this issue.

Please report the issue to the extension causing this.

Disabling my configuration helped
Please report back more details about your configuration, including settings.

Using VS Code Insiders has helped
✅ This likely means that the issue has been addressed already and will be available in an upcoming release. You can safely use VS Code Insiders until the new stable version is available.

This issue is caused by an extension, please file it with the repository (or contact) the extension has linked in its overview in VS Code or the marketplace for VS Code. See also our issue reporting guidelines. If you don't know which extension is causing the problem, you can run Help: Start extension bisect from the command palette (F1) to help identify the problem extension.
Happy Coding!


Error in Try it example causes focus loss

Bug Report
If you write an invalid code in an example's Try it box, it will cause the focus to be lost (its moved to document body). Looks like it happens because tree is unmounted.

Steps

Go to any example
Press Try it
Type something that leads to build error
Observe focus was lost

Expected Result
Focus is preserved
Actual Result
Focus has moved to document body
Version
0.38.1

It seems that issue exists somewhere in our code:

The unstable_hot prop is causing it.

Where can I find the most recent version of the react-source-render repo? The version 3.0.0-5 that is being used in Stardust.
I tried looking at the repo page: https://github.com/layershifter/react-source-render
The master branch has version 2.0.0-beta.6,
while the wip-wip branch is on version 3.0.0-2

Pushed latest changes to wip-wip, actually we need to adopt this package under docs-components.


chore: hide cookie banner for percy diffs

Reduce noise, easier to review diff / read text that can sometime hide behind
Closes https://github.com/prisma/docs/issues/3227

Whoa, this is fantastic, thank you @Jolg42 !! Just saw it, nice.
Can I go ahead and merge this? @Jolg42 , did you have a reason for wanting to wait til 4.1? Or by applying that milestone, are you saying "Let's for sure do this in 4.1"?

No need to wait, no sure why a milestone was added.
 Sorry)


update fields to enable storage of optional fileds

Resolves #38

Codecov Report
Attention: 20 lines in your changes are missing coverage. Please review.

Comparison is base (54eac00) 61.58% compared to head (697cd8b) 60.53%.
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #40      +/-   ##
==========================================
- Coverage   61.58%   60.53%   -1.06%
==========================================
  Files          10       10
  Lines         453      489      +36
==========================================
+ Hits          279      296      +17
- Misses        174      193      +19

Files
Coverage Δ

django_typesense/utils.py
27.45% <66.66%> (+2.45%)
:arrow_up:

django_typesense/paginator.py
24.32% <0.00%> (-2.95%)
:arrow_down:

django_typesense/fields.py
76.31% <62.16%> (-8.40%)
:arrow_down:

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


Bugs around styled-components 4.0 beta

Bug Report
Some features of styled-components 4.0.0 beta are broken when used inside a Docz document.
I would open a bug to SC directly but the same code works fine in react-styleguidist so I'm not quite sure where I should open the issue.
The bugs seems to be mainly around the styled() syntax of styled-components. Which I assume got changed a bit internally with 4.x.
Considering this file
https://github.com/eramdam/docz-repro-error/blob/master/test/hello.tsx
Here is how it's supposed to look (and how it looks under styled-components 3.x):

Here is how it looks with styled-components 4.x installed:

Feel free to clone https://github.com/eramdam/docz-repro-error and alternate between the master branch (4.x) and sc-v3 (3.x) to try.
I'd be happy to provide more details if needed.

styled-components v4 somehow broke my app's navigation as well as extending on base styles didn't seem to work. No console errors or logs. I don't think it's related to docz though.

For me docz is not reading propTypes from styled components.
Link.js
import { Link as L } from '@reach/router'
import styled from 'styled-components'
import PropTypes from 'prop-types'

const Link = styled(L)`
  font-weight: bold;
  line-height: 1.5;
`

Link.propTypes = {
  to: PropTypes.string.isRequired,
}

export default Link

Link.mdx
---
name: Link
---

import { Playground, PropsTable } from 'docz'
import Link from './Link'

# Link

<PropsTable of={Link} />

## Basic usage

<Playground>
  <Link to="/">This is a link</Link>
</Playground>

dev mode

This problem is related to docgen parser, duplicated from #240 and all that depends of resolve this docgen bug 😕

@pedronauck even the rendering issue with styled-components?

Sorry @eramdam, the rendering issue isn't a bug from react-docgen, I'll keep this openning 🙏

this is a real gotcha issue. i resolve it as follows：
// Link is a styled components
const LinkWrapper = (props)=>(
   <Link {...props}/>
)
// docz reading propTypes from LinkWrapper
LinkWrapper. propTypes = {
   //props
}
export default LinkWrapper

Any follow up on this issue?

I'm closing this issue now in favor of the new one, most of the problems have been solved and are working now, but some others appeared.


Please add "onClose" event(Enchancement)

Please add "onClose" event suggestions

Cool event...

This will be added on v3, that I am currently working on.

That's great!!
thanks

I am going to merge this issue with  #161


Surprising color conversion after luminance adjustment

Describe the bug
A Collective admin is trying to update the custom color for their Collective to #262262 which is a dark blue.

However, when they enter that and click save, it turns grey.

They are able to successfully select any of the preset colors and they've tried other HEX codes that are working, just not their brand color which they need to use.
To Reproduce
I was able to reproduce this using that specific HEX code as well. All the other HEX codes I tried are working normally, just not that specific one.

Duplicate of https://github.com/opencollective/opencollective/issues/3383

Though this example of #262262 turning to grey is a little strange, let's keep it open.

<EMAIL_ADDRESS>and and I have been working on the welcome-orb for the
last few days and I have been working on the welcome-orb for the last few
days and I have been working on the welcome-orb for the last few days and
Valecia G Rodriguez
On Thu, Dec 24, 2020, 09:38 Benjamin Piouffle<EMAIL_ADDRESS>wrote:

Closed #3456
https://github.com/opencollective/opencollective/issues/3456 via
opencollective/opencollective-frontend#5637
https://github.com/opencollective/opencollective-frontend/pull/5637.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/opencollective/opencollective/issues/3456#event-4147583355,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AO5BW257YYKC7KKO3G2JHH3SWNHAHANCNFSM4QWAA2UA
.

Valecia G Rodriguez
On Thu, Dec 24, 2020, 09:47 Valecia Rodriguez<EMAIL_ADDRESS>wrote:

<EMAIL_ADDRESS>and and I have been working on the welcome-orb for the
last few days and I have been working on the welcome-orb for the last few
days and I have been working on the welcome-orb for the last few days and
Valecia G Rodriguez
On Thu, Dec 24, 2020, 09:38 Benjamin Piouffle<EMAIL_ADDRESS>wrote:

Closed #3456
https://github.com/opencollective/opencollective/issues/3456 via
opencollective/opencollective-frontend#5637
https://github.com/opencollective/opencollective-frontend/pull/5637.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<
https://github.com/opencollective/opencollective/issues/3456#event-4147583355
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AO5BW257YYKC7KKO3G2JHH3SWNHAHANCNFSM4QWAA2UA
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/opencollective/opencollective/issues/3456#issuecomment-750901928,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AO5BW2Z2EDL4LDRZYVSEPKDSWNH6VANCNFSM4QWAA2UA
.


feat(derive): Remove Origin Set

Description
Remove the need to set the L1 Origin on the pipeline. Specifically, the set_origin() method on the Pipeline Builder should be removed.
The L1Traversal stage should load the origin if needed (if its block is None).
Addresses https://github.com/ethereum-optimism/kona/pull/243#discussion_r1641219587

See draft: https://github.com/ethereum-optimism/kona/pull/253

This hasn't proved to be an issue, setting the L1 origin is fairly fundamental to the derivation pipeline.


Add option to turn off string trimming.

See #34.

Original issue comment: The decoder automatically trims spaces which I guess works for most people. I have a case where I do not want to trim spaces. Would it be possible to allow this to be configured via an option on the decoder?

I am going to drop this PR in favor of work being done on #28.


[Bug] Will message not to be sent

What did I do
我设置了遗嘱消息。
What happened
建立连接后再手动断开，设置的遗嘱消息没有从服务器发出来。
Expected
服务器应该发出遗嘱消息。
Environment

OS: windows 7 旗舰版
MQTTX version, e.g. v1.7.3

More detail
我使用python编写了脚本，就可以收到服务器发出来的遗嘱消息。

设置截图

Hi, sorry for my later reply. Could you please tell me the details of the reproduction steps? For example how a will message is triggered?
However, manually triggering a disconnection will not trigger a probate message. Here is an article that you may wish to refer to. https://www.emqx.com/en/blog/use-of-mqtt-will-message

Hi, if there is no problem, I will close this issue. Thanks.


rewards halvening

** DO NOT MERGE ***
This updates the iot and mobile verifier to account for the rewards halvening to be applied in August

Would we not like to gate this feature by date comparison since these rewards are usually calculated in the context of a DateTime range “epoch” period and go ahead and merge this well ahead of the event?

I mean we could but it does add additional risk and will make it that bit more difficult to test and verify before going live.  I think merging on the day is likely the best scenario here.
The plan is to implement the reward curve into the code post this halving

Would it make more sense to define some constant that is halving? So instead of having to manually halve all of the constants in the tests, we can just divide them by the constant?


Use HTML5 required attribute for required fields

If accepted, this PR will add the HTML5 boolean required attribute to all <input>, <textarea>, and <select> fields that have the required flag set (e.g., if the InputRequired validator is used).

Is there a discussion somewhere regarding this new behavior? It seemed from issue #130 and this stack overflow answer that the prevailing opinion was to leave it up to the developer to choose whether to render the required attribute or not.

It's now up to the developer to choose not to render it. 😉 required=False will force it not to render, or you can make a widget that doesn't set it. The required attribute prevents a request/response cycle for validation, which is valuable enough to make it the default. You can also prevent the behavior without messing with a lot of code by rendering the novalidate attribute on the form tag (or the formnovalidate attribute on a submit button).
My goal with the 2.2 release was to get it out, and I didn't really focus on documentation. If you'd like to make a PR that adds the reasoning above to the docs, that could be really helpful.

opened a PR basically just copying your response with a bit of editing. The docs built alright on my end. Hopefully this is similar to what you were looking for.

@davidism I would have preferred to make this feature opt-in, not opt-out. While the client-side validation works generally well, it was mentioned to me several times that users of apps that use Flask-Babel to offer several languages find it odd that these client-side validation popups cannot be translated and are in the language of the browser and not the currently selected language for the application.

I agree that this should have been opt-in and not opt-out. Especially since there doesn't seem to be a straight-forward way to opt out. novalidate applies to the whole form and not just the required attribute. Presumably, there are other types of validation that you might still want.

I'd be happy to review a PR that adds an attribute to the Meta class to control the policy for this. But I don't plan to change the default.

I'm also open to brainstorming a more extensible "layout backend" + "render plugin" design for the entire syste. For example, you might have a "Boostrap" layout backend, or "HTML5 Required" and "ARIA" plugins.

There also appears to be an API for modifying a browser's validation messages, although there would need to be some support from WTForms or an extension to make using it easier: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation#Customized_error_messages

Turns out WTForms already has the ability to control how a form's fields are rendered. Override a form's Meta with a different render_field method.
class MyForm(Form):
    class Meta:
        def render_field(self, field, render_kw):
            render_kw.setdefault('required', False)
            super().render_field(field, render_kw)

So I think at this point I'm inclined to leave things as-is.


Add own gmod launcher executable with container detection

This PR adds custom GMod launcher that bypasses the namespace support check for Flatpak, Snap and other container-based GNU/Linux store apps.
The overall functionality should be the same as original launcher.

I think this is completed, Feel free to request any changes/explanations.


[Teams] Provide a sample Teams bot that shows how to use message ext w/ action-based command and bot response

Sample information
Sample type: samples
Sample language:
[ ] dotnetcore
[ ] nodejs
[ ] typescript
Sample name:
MessageExtWithActionCmdResponse

C# v3 example (MS Only repo): https://github.com/OfficeDev/msteams-samples/tree/master/samples/dotnet/messaging_extensions/messaging_extension_action_bot_response

This work is done.


Asynchronous methods error when callback invoked before IAsyncResult added to dictionary

FTP OS: All
FTP Server: All
Computer OS: Windows 10 and Windows Server 2008 R2
When using FtpClient.CreateDirectoryAsync(string path) I observed the following exception and stack trace:
System.InvalidOperationException: The specified IAsyncResult could not be located.
   at FluentFTP.FtpClient.GetAsyncDelegate[T](IAsyncResult ar)
   at FluentFTP.FtpClient.<CreateDirectoryAsync>b__53(IAsyncResult ar)
   at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction,
Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)

We have been using what was System.Net.FtpClient and now is FluentFtp in production heavily for several years now and have never seen this error before.
This led me to delve into the internals of the FtpClient async methods (CreateDirectoryAsync in particular). As the async methods use Task.Factory.FromAsync I took at look at the BeginCreateDirectory and EndCreateDirectory implementations.
It appears that the Begin methods add the IAsyncResult to m_asyncmethods after BeginInvoke returns (see source), this does not work in the case when the asynchronous method completes quickly (i.e. before adding to m_asyncmethods), this results in the AsyncCallback being invoked before the item is added to m_asyncmethods.
This behaviour of BeginInvoke calling the callback before the item is added to m_asyncmethods can be demonstrated with a small sample, this also replicates what is happening in FtpClient:
Func<int, int> callback = x => x * 2;
var m_asyncmethods = new Dictionary<IAsyncResult, object>();

while (true)
{
    await Task<int>.Factory.FromAsync((cb, state) =>
    {
        var asyncResult = callback.BeginInvoke(5, cb, state);
        lock (m_asyncmethods)
            m_asyncmethods.Add(asyncResult, callback);

        return asyncResult;
    }, r =>
    {
        lock (m_asyncmethods)
        {
            if (!m_asyncmethods.ContainsKey(r))
                throw new Exception("The specified IAsyncResult could not be located.");
            m_asyncmethods.Remove(r);
        }

        return callback.EndInvoke(r);
    }, null);
}

This will occasionally throw an Exception in the case when BeginInvoke calls cb before it has had a chance to add to the m_asyncmethods dictionary.

Thank you for fixing this in #296!


Experiment: Polyglot hooks

This PR: Removes the requirement that hooks for the buildkite-agent be written in a shell scripting language a la bash. With the use of this branch, hooks can also either be compiled executable binaries (ie those produced by languages like Golang or Rust), or any interpreted scripting language (ie python, ruby, lua), so long as an appropriate shebang is specified at the top of the file.
note that neither binary hooks nor non-shell script hooks have environment variable changes captured as bash script hooks do; they must use the Job API to modify the environment of the job.

Love this!

note that neither binary hooks nor non-shell script hooks have environment variable changes captured as bash script hooks do; they must use the Job API to modify the environment of the job.

Yeah, this is my only concern. I wonder if this will be an unexpected sharp edge. I guess that folks assume that bash scripts are simply sourced (vs the magic of wrapped hooks) and they won't expect that behaviour for non-shell scripts.
I assume the future is all Job API and no more magical environment capture?

@lox

I assume the future is all Job API and no more magical environment capture?

in an "as the limit tends to infinity" sense, i think so. i doubt that we'd ever fully remove the environment functionality anytime in the forseeable future; it's just too useful and easy to set up.
i suspect that if we merged this, we'd try to make non-bash hooks the golden path, and try to build some nicer tooling around them, and encourage it that way, but keep env capture around as a simple mode? i'm not 100% sure, i may or may or may not have thought that far ahead 😅


apinat-pops-more in apinatomy.org skips neurons that do not have any phenotypes in the spreadsheet

fixed in 5672dea09ead19b75f88bbf2bc45a522571c1657


Refresh Cache broken in Background Jobs

Describe the bug
In staging we see the following error:
Starting Background Jobs.
- starting refreshCache
Unhandled rejection TypeError: Cannot read property 'set' of
  at /app/dist/background-jobs.js:82:46
  at Generator.next (<anonymous>)
  at Generator.tryCatcher (/app/node_modules/bluebird/js/release/
  at PromiseSpawn._promiseFulfilled (/app/node_modules/bluebird/js/
  at Promise._settlePromise (/app/node_modules/bluebird/js/release/
  at Promise._settlePromise0 (/app/node_modules/bluebird/js/release
  at Promise._settlePromises (/app/node_modules/bluebird/js/release
  at Async._drainQueue (/app/node_modules/bluebird/js/release/
  at Async._drainQueues (/app/node_modules/bluebird/js/release/
  at Immediate.Async.drainQueues [as _onImmediate] (/app/
  at runCallback (timers.js:696:18)
  at tryOnImmediate (timers.js:667:5)
  at processImmediate (timers.js:649:5)

It's likely related to:
https://github.com/opencollective/opencollective-api/pull/1517

@HipsterBrown Can you look into that?


[move-lang-functional-tests] Reduce test time by 60%

Added clone to ASTs
Added move-lang endpoint to save ASTs from each pass for dependency/libraries
Saved the compilation of the stdlib/diem framework for functional tests. Reducing test time by 60%

Motivation

Before the change, tests took about 354s on my machine.
After, it's down to about 135s

Test Plan

ran affected tests

/land


Insphpect results

https://insphpect.com/report/5f168d883467d
I just randomly chose a PHP project from my main Github page. Happened to be this one 🤷♂
The tool seems to mope about usage of new Unit() in Islambey\RSMQ\RSMQ. After careful inspection, all the 'utils' could be static functions. There is not state (no $this) in Islambey\RSMQ\Util. Maybe use them like that?
Edit: What do you know. It will also tell you not to use static functions. Example

Yes, the Util class functions can be static. But you are saying this is bad to.
Maybe we can have pure functions or we can inject Util class but this will be BC break. What is your opinion?


Clicking link on blog does not initiate download

When you click a link to download one of the CSV or JSON files nothing happens. If you right click and open link in a new tab the download will begin. The only download link that seems to work properly is the Timeseries > CSV (Tidy Format)
Seeing this in Chrome Version 80.0.3987.122, works in older IE though.

Fixed! Thanks for the report.


Format project using black

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

937 of 1844 (50.81%)  changed or added relevant lines in 87 files are covered.
77 unchanged lines in 25 files lost coverage.
Overall coverage decreased (-0.1%) to 54.941%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

dapper/da_methods/init.py
3
4
75.0%

dapper/da_methods/baseline.py
39
40
97.5%

dapper/mods/Lorenz05/init.py
17
18
94.44%

dapper/mods/Lorenz05/demo.py
0
1
0.0%

dapper/mods/Lorenz63/mandel2016.py
2
3
66.67%

dapper/mods/Lorenz84/init.py
3
4
75.0%

dapper/mods/Lorenz96/bocquet2015loc.py
0
1
0.0%

dapper/mods/Lorenz96/demo.py
0
1
0.0%

dapper/mods/LotkaVolterra/init.py
5
6
83.33%

dapper/tools/seeding.py
2
3
66.67%

Files with Coverage Reduction
New Missed Lines
%

dapper/da_methods/extended.py
1
48.78%

dapper/da_methods/init.py
1
51.14%

dapper/mods/DoublePendulum/demo.py
1
0%

dapper/mods/KS/demo.py
1
0%

dapper/mods/KS/init.py
1
87.67%

dapper/mods/Lorenz84/demo.py
1
0%

dapper/mods/QG/init.py
1
0%

dapper/mods/VL20/demo.py
1
0%

dapper/tools/datafiles.py
1
51.89%

dapper/tools/matrices.py
1
75.65%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
3584

Relevant Lines:
6247

💛  - Coveralls


Drupal starter

I tested @gridsome/source-drupal plugin and it's just beautiful. If you have functional drupal backend with JSON:API module enabled you can build modern static site in a few minutes. By the way JSON:API goes to Drupal core starting from 8.7 version.
Huge thanks goes to @matt-e-king who is the author of the plugin! And he already start to work on starter project.
I suggest to build Drupal starter on top of always available ContentaCMS API: https://back-end.contentacms.io/api
The main advantage is that you have fully functional Gridsome example with flexible and clear content model in just two cli commands. However ContentaCMS has overwritten api keys which is not default for JSON:API module (e.g. articles instead of node--article).
Lets make Gridsome Drupal starter public and add it to plugin documentation page.

Thanks, @Al-Rozhkov! I have no experience or knowledge around ContentaCMS, but I would love some insight on any changes that need to be made to the current Drupal start project to accommodate it.
Regarding this:

However ContentaCMS has overwritten api keys which is not default for JSON:API module (e.g. articles instead of node--article).

My apologies if I'm misunderstanding, but we built the plugin to work with "overwritten api keys" which you can accomplish with JSON:API extras as well. It should theoretically work with anything the jsonapi schema returns.
@tanc might be able to confirm this since he was our guiding light during development of the plugin, but I believe @tanc tested this plugin with ContentaCMS in mind.
Again, my apologies if I'm misunderstanding what you are inferring - are you experiencing that it doesn't currently work with ContentaCMS or if we just need to clarify and show examples in the Drupal starter?
Thanks!

ContentaCMS is just a drupal distribution with some example content. And yes, it uses JSON:API extras to override api keys. Indeed @gridsome/source-drupal handles that perfectly.
I wanted to offer to include ContentaCMS API endpoint to official Gridsome Drupal Starter, like this:
{
  use: '@gridsome/source-drupal',
  options: {
    baseUrl: 'https://back-end.contentacms.io',
    apiBase: 'api',
    routes: {
      'articles': '/article/:slug',
      'recipes': '/recipes/:title'
    }
  }
}

It is a nice way to play around with Gridsome-Drupal integration without need to set up Drupal backend manually. But I thought It can cause some difficulties for unexperienced users since default keys are little different.
Plugin docs decribes API Schema really well. Probably we can add some helpful comments to gridsome.config.js to completely avoid any confusion :smile:

@Al-Rozhkov I will update the @gridesome/source-drupal README to have a new table of contents, and I will include a new ContentaCMS section which will elaborate on how ContentaCMS uses JSON:API Extras to override api keys and apiBase - but otherwise will work "out-of-the-box".
And as you suggested, in the Drupal Starter project we can also clarify in the README on how to convert the gridsome.config.js to work with ContentaCMS.
I'll work on this over the next week, and then send you the pull request to review. How does that sound?

Sound awesome 😃 Thank you!

@Al-Rozhkov https://github.com/gridsome/gridsome/pull/360

I think docs is ready to go. One last thing I can dream of is gridsome create my-website drupal CLI command.

A CLI command is a good idea! I'm not familiar enough with the whole eco system to know how the Drupal Starter needs to be incorporated in order to scaffold out an app with a CLI command. Someone else would need to be the authority on that.
I believe this ticket can be closed.